Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Possible ShortReads with ITF-Codes

Open
  • Is something wrong?
#467 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
25/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Stale
Tech stack
csharp
Domain
computer-vision

Research direction

The bug is in the one-dimensional decoding path, where the ITF reader is driven by OneDReader and its quiet-zone check; start by reproducing the short read with the attached example.zip, which should decode to 0002216887 but returns 000221. The issue proposes validating a candidate against neighbouring rows, but the maintainer has not chosen an approach, so agree on a design in the thread before editing. Done means the example decodes fully and existing ITF tests still pass.

Written by the indexing model from the issue text.

Description

In some circumstances, a short read with ITF codes may occur.
As ITF codes may contain bars similar to end markers in the middle of the code [1], a quiet zone check needs to be performed.
This check is already being performed. This check works for most of the time.

However, we observed some interesting cases when dealing with scanned documents.
For reference, the problem below already happened 4 or 5 times in the wild.

The problem

As the decoding algorithm for 1D-Codes is operating only on rows without any reference to rows above/below, a short read can occur when the code is ever so slightly tilted in such a way that the number "6" is the last black pixel block in the row.
As 6 is extremely similar to the end marker, the library will short read.
The quiet zone check is also passing because the black pixels which should continue the code are not in those rows.

After testing some time, I managed to build an example image [2] that demonstrates this issue.
The picture is taken directly from a scanned document.
As the decoding algorithm will start in the middle row, the interesting row is exactly centered in this example.
The code should read 0002216887, but the library returns 000221.

Solution proposal

Maybe the OneDReader should also check n rows above and/or below, too.
When a valid barcode is found on e.g. row j=10, a sanity check shall be performed.
The scan shall run on rows (n=5) 5, 6, 7, 8, 9, 11, 12, 13, 14, 15 ([j-n; j+n] \ {j}) to see whether the same barcode can be found there.
If more than 50% or 30% of the other rows are also valid and decoded to the same value, the barcode shall be returned.
If this check fails, we may be short-reading and we shouldn't return a code.
The row handling code will then check some rows above which can then find the code in question.

Reproducing stuff

Tested with latest master branch.
Issue first occured on NuGet 0.16.8.
We are using the .NET Framework 4.8 version.

The scanner options:

var scanner = new BarcodeReader
{
    AutoRotate = true,
    Options =
    {
        TryHarder = true,
        TryInverted = true,
        PureBarcode = false,
        PossibleFormats = new List<BarcodeFormat>
        {
            BarcodeFormat.ITF
        }
    }
};

References

[1] https://en.wikipedia.org/wiki/Interleaved_2_of_5
[2] example.zip

Dominant language
C#
Stars
3.1k
Forks
704
Avg merge
13d 17h
Merged PRs (30d)
2

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from micjahn/ZXing.Net

All issues in micjahn/ZXing.Net

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.