Scanned Image came out "side ways" (see attached image)

[yuyan]

We have an application that use Twain driver to interact with scanner directly and scan documents. The scanner is FUJITSU fi-5220C. The driver version is the latest one from Fujitsu global website. The application works fine in XP. However, after we migrated it to Windows 7, we discovered that the scanned image would came out “side ways”. (Please see the attached image). Strangely, this problem only happens to flatbed; scanning from ADF is fine.

I have spent a lot of time looking at the settings in FJTW2600.INI under USERS profile folder. But couldn’t figure out what could cause the problem.

Have anyone seen this type of problem? I am running out of clues at this moment and looking for help!

Thanks!!!

[Kaij]

Is that happening in buffered memory transfer mode, native transfer mode or both?

Best regards,
Kaij
http://www.jse.de

[yuyan]

Thanks for the reply. Memory transfer mode is used in the c++ code.

[yuyan]

The problem seems related to the floattofix32() function, where it convert a float number to the fix32 datatype. When scanning the legal size, the width is 8.5. In the function, the WHOLE is set to 8, however the FRACTION is set to 32768. If I force the fraction to 5 (in debugging mode), then the image comes out OK.

Very strange. The following is the code from twain spec.
TW_FIX32 FloatToFix32 (float floater)
{
TW_FIX32 Fix32_value;
TW_INT32 value = (TW_INT32) (floater * 65536.0 + 0.5);
Fix32_value.Whole = value >> 16;
Fix32_value.Frac = value & 0x0000ffffL;
return (Fix32_value);
}

Thanks!

[spike]

Hi yuyan – that definitely looks like the width of the image, in either pixels or bytes, is not being determined correctly.

1. I hope you aren’t using floats or FIX32 values to compute the width of the image data – that is unlikely to work well.
The width, in pixels, of the image is available either:
a) by doing a DG_IMAGE/DAT_IMAGEINFO/MSG_GET after the DAT_SETUPMEMXFER/MSG_GET
and looking at info.ImageWidth … or …
b) by looking at the ‘Columns’ value in the first TW_IMAGEMEMXFER structure you get from doing DG_IMAGE/DAT_IMAGEMEMXFER/MSG_GET

2. That FloatToFix32 function is the one the TWAIN driver should be using, it isn’t very useful in your application code. And it correctly converts the value 8.5 to the integer 557056, which is 0x88000 – so, 8 in the Whole part, and 0x8000 (32768) in the Frac part. So it seems to me the TWAIN driver is encoding 8.5 correctly, so I wonder if your function to convert back Fix32ToFloat, is not correct? In a FIX32, the ‘Frac’ part is not the decimal fraction of the number: to represent 8.5, Frac is not 5, it’s the 16-bit binary fractional part: 32768.

Hope this helps, happy to answer questions.

[spike]

I forgot something: You need to pay attention to the BytesPerRow member of the TW_IMAGEMEMXFER structure.
You can’t assume that each row of pixels is just the minimum number of bytes – it might be padded, for example, the way ‘DIB’ rows are padded to 4-byte boundaries.

[yuyan]

Thanks for the reply. The ByesPerRow is always set to 3435973836, even when it scans fine with ADF.

It is quite interesting that the resolution seems to related to this distorted image problem. Scanned image came out distorted when resolution is set to 100. If I set the resolution to 80, 120, 160, 200, 240 or 280, then the image came out fine. (multiple of 40)

Confused!!

[spike]

The ByesPerRow is always set to 3435973836

So that’s 0xCCCCCCCC – which is the value Visual C/C++ puts in uninitialized variables in a debug build.
I’m guessing the TWAIN driver isn’t a debug build 😉 so probably your application is a debug build? That would explain how that structure member gets set to that value, and apparently the TWAIN driver never updates it, and that would be kind of a bug…

Except this is an up-to-date Fujitsu driver, so I’m skeptical that it’s a driver bug.
Do all the other values in the TW_IMAGEMEMXFER look reasonable after the call to DG_IMAGE/DAT_IMAGEMEMXFER/MSG_GET?

I wouldn’t worry much about the resolution, until you are calculating the bytes-per-row correctly. It’s easy for row-alignment to be accidentally right at some resolutions and wrong on others. How *are* you calculating bytes per row, if the BytesPerRow from the driver seems to be garbage?

[yuyan]

To be honest, I don’t know too much about Twain driver programming as I am assigned to work on migrating this 10 years old application to Windows 7.

I searched BytesPerRow in the source code. It is not calculated anywhere in the code. Should it be calculated before calling DG_IMAGE/DAT_IMAGEINFO/MSG_GET? And, what would be the formula?

Thanks!!

[Author]

Posts