SourceForge has been redesigned. Learn more.

Zbar SDK on Windows image width limitation found

  • Craig Landrum

    Craig Landrum - 2013-06-28

    We externally scan images, select areas to be recognized, and pass these to ZBar which works wonderfully so long as the image is grayscale (documented) and is also evenly divisible by 4 (not documented that I could find). The only note I found was that the image byte width should match the image pixel width (duh, its 8 bit grayscale). All attempts to recognize QR codes on a proper grayscale image fail unless the image width is evenly divisible by 4. Thought someone might like to know why their images are not being recognized properly :-)

  • Jarek Czekalski

    Jarek Czekalski - 2013-06-29

    Craig, thanks for your hint. We never know when such a suggestion can make our day. But could you precise whether you mean image or camera scanning? If it's about images, could you provide an example? Maybe one of the devs would like to work on it.

  • Ash

    Ash - 2013-07-15

    In Image Processing a common practise is keeping the image WORD(4 Byte) Aligned for faster memory access across rows..
    in case of color image generally image is 4 channel including 1 alpha channel so its always aligned..
    In case of grayscale its 1 byte per pixel so the width has to be multiple of 4...

    Last edit: Ash 2013-07-15
  • Craig Landrum

    Craig Landrum - 2013-07-15

    Jarek - my problem came when doing document scanning into color, grayscale, and black and white images. The issue isn't the scanning - its the undocumented requirement that the image byte width be evenly divisible by 4, and that could potentially happen regardless of the image source, and is especially true if you are creating image clips in your app which then get passed to the library - the byte width of the clip MUST be evenly divisible by 4.

    Ash - there is a wide variety of image processing out there - everything from grabbing quick camera images to document scanning, photoshop, etc. Not one professional app that I've ever used in my 35 years of doing image processing has ever forced me to create images on 4-byte bounds. Also, FYI, most color images I come in contact with are RGB with no alpha channel, and on Windows, this means 3-byte pixels when the image is in memory. I believe it is an erroneous assumption by the ZBar developers that all grayscale images are "naturally" on 4-byte bounds. Certainly Windows has no such restriction when it comes to bitmaps and dibs, and Mac OS X doesn't either.

    ZBar works quite well once you conform to its input limitations (MUST be grayscale and MUST be on 4-byte width boundaries), but ensuring that all images submitted to ZBar meet these specifications is a real pain. Because we do mostly archival document scanning in black and white, we must convert a nice compact B&W image to waste a bunch of memory just so it can be grayscale.

    I haven't the slightest idea why the ZBar developers insist on grayscale - especially since in the barcode world each test point is either black or white. Most of the coding we did surrounding the use of ZBar was simply to meet its input expectations. Want to make it easier for developers to use your library? Accept most common image formats and do whatever conversion you need to do internally; and add a rowBytes variable so submitted images can be on any byte boundary. Those things are not terribly difficult to do and it would save all users of the library from having to do it themselves.


Log in to post a comment.