TWAIN Working Group

Newsletter Signup
Donate
Help keep TWAIN free
  • About TWAIN
    • What’s New?
    • News
    • Events
    • Membership
    • Consider a Donation
    • Contact Us
  • Why TWAIN?
  • Developers
    • Driver Developer
    • Application Developer
    • TWAIN Features
    • Specification & Tools
    • Self Certification Process
  • Support Forums
  • Scanner End-User
  • Find Certified Drivers
    • Facebook
    • LinkedIn
    • Vimeo

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

Forums › TWAIN Classic › Scanned Image came out "side ways" (see attached image)

  • This topic has 8 replies, 3 voices, and was last updated 7 years, 2 months ago by yuyan.
Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • October 29, 2013 at 7:59 pm #22897 Reply
    yuyan
    Participant
    • Topics - 1
    • Replies - 4
    • Total Posts - 5

    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!!!

    October 31, 2013 at 9:17 am #26022 Reply
    Kaij
    Participant
    • Topics - 9
    • Replies - 132
    • Total Posts - 141

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

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

    October 31, 2013 at 12:48 pm #26023 Reply
    yuyan
    Participant
    • Topics - 1
    • Replies - 4
    • Total Posts - 5

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

    November 6, 2013 at 2:53 pm #26024 Reply
    yuyan
    Participant
    • Topics - 1
    • Replies - 4
    • Total Posts - 5

    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!

    November 12, 2013 at 5:49 pm #26025 Reply
    spike
    Participant
    • Topics - 10
    • Replies - 139
    • Total Posts - 149

    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.

    November 12, 2013 at 6:06 pm #26026 Reply
    spike
    Participant
    • Topics - 10
    • Replies - 139
    • Total Posts - 149

    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.

    November 15, 2013 at 8:54 pm #26027 Reply
    yuyan
    Participant
    • Topics - 1
    • Replies - 4
    • Total Posts - 5

    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!!

    November 15, 2013 at 9:08 pm #26028 Reply
    spike
    Participant
    • Topics - 10
    • Replies - 139
    • Total Posts - 149

    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?

    November 19, 2013 at 8:09 pm #26029 Reply
    yuyan
    Participant
    • Topics - 1
    • Replies - 4
    • Total Posts - 5

    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
Viewing 9 posts - 1 through 9 (of 9 total)
Reply To: Scanned Image came out "side ways" (see attached image)
Your information:




Quick Links

Service Providers
TWAIN Support Forums
Membership
Contact Us
Privacy Policy

Newsletter Signup

TWAIN Working Group Family

TWAIN Working Group
TWAIN Direct®
TWAIN Resources
TWAIN Certified Drivers
PDF/raster

  • Facebook
  • GitHub
  • LinkedIn
  • Vimeo

Recent Topics

  • EPSON V600 TWAIN and WIA on Windows 10
  • When and how to use WaitForEvents command ?
  • Problem enumerating list of installed scanners in windows server 2012
  • Failed to create TWAIN progress! Error code is 1260.
  • To get the list of scanners from javascript client side (browser)
  • Quarterly Newsletter
  • TWAIN Working Group Membership
  • Logo Usage
  • TWAIN License
  • Contact Us
Privacy Policy • Privacy Tools • Copyright © 2021 TWAIN Working Group • by iHwy, LLC • Log in

Insert/edit link

Enter the destination URL

Or link to existing content

    No search term specified. Showing recent items. Search or use up and down arrow keys to select an item.