Handling of ITF quiet zones

[Christoph Schulz]

Hi all,

I've been using ZXing (C++ version) for quite a while. With the recent sync. against the Java version a small regression (from my point of view) got introduced: ITFs can't be read without a super clean quiet zone (ITFReader.validateQuietZone() throws an exception). There is no way to bypass this unless the sources are modified. I know its risky to read ITF like that, but we're cropping barcodes very precise from our documents and sometimes there is dirt in the quiet zone (pen colored finger prints and stuff). I'll see several options for solving this:

• Incorporate the quiet zone in some kind of confidence
• Restrict ITFReader to a fixed length (so that its safe to ignore the quiet zone) - our hand readers handle it that way
• Make the image even more bite-sized for ZXing (I hate this solution, as we're already injecting the barcode up to four times into ZXing^^)
  

Regards,
Christoph

[Sean Owen]

What does the patch look like? it sounds like a change that should be applied to a lot of 1D formats. If it's smart, that could be a good thing all around.

What about just requiring less quiet zone? It increases possibility of false positives, but maybe so little that it doesn't matter.

[Christoph Schulz]

Am Freitag, 12. April 2013 17:42:08 UTC+2 schrieb Sean Owen:

What does the patch look like? it sounds like a change that should be applied to a lot of 1D formats. If it's smart, that could be a good thing all around. 

There is no patch, yet. I was thinking about this over the weekend: a good solution would be to add int quietZoneConfidence (0..100%) to Result.java, instead of throwing an exception during reading along with adding DecodeHintType.REQUIRED_QUIET_ZONE_CONFIDENCE (very long symbol name :/), which defaults to 100 (making it a non-breaking change). The confidence would be computed like max(actualSize * 100 / exceptedSize, 100).

This shouldn't affect 2D barcodes, right?

Regards,
Christoph

[Sean Owen]

I don't mind slightly breaking changes and don't mind expressing the units in simple pixels. Making it configurable is a bonus. It need not affect 2D barcodes, yes. But is there a change here that definitely improves most 1D barcodes?