You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I found a rare issue that occurred when the decoder was processing lines from the middle upwards in GetLeftIndicators. It would find codewords on all the lines. When it got to the top of the barcode it would continue to check (in case the start/stop indicators for those lines were corrupt/late). It would fail on the next few, as expected. However, it then matched on text pixels just above and to the right of the bar code. This ultimately caused the slope to be large in GetCodeWord. The calculated Y generated an out-of-bounds exception. The exception was caught but ultimately resulted in a valid bar code being rejected.
A solution:
Check to insure that the new LeftX does not exceed the right boundary of the barcode.
This not only helps prevent noise from affecting the barcode, but it also reduces work.
@1257 in Pdf417Decoder.cs' GetCodeWord
WhiteToBlackTransition(ref LeftX, ref LeftY, DeltaX, DeltaY);
becomes
WhiteToBlackTransition(ref LeftX, ref LeftY, DeltaX, DeltaY);
if (LeftX > RightX)
{
// Looking for the WhiteToBlack transition caused us to exceed the data area of the barcode.
// If we continue and happen to match patterns on the unrelated image pixels,
// we will inadvertantly extend the data area.
return -3;
}
The GetCodeWord method would need to add the RightX parameter.
Callers to GetCodeWord will need to provide the new RightX parameter
(typically BarcodeArea.RightCenterX; in GetCodeWord perhaps ImageWidth).
Check to insure Y>=0 and Y<ImageHeight in WhiteToBlackTransition at line 1335 and 1351.
You will need to modify to return an error (or exception) and then have the caller handle that error appropriately.
This may not be required after making the previous suggested change, but it does make the code more robust.
A similar check could be made in GetCodeWord at line 1266, RevGetCodeWord at line 1302.
When the test succeeds you would then return a negative number. These methods have general catches which
return a negative number. Consequently adding a specific test is optional and only helps with debugging.
The text was updated successfully, but these errors were encountered:
I found a rare issue that occurred when the decoder was processing lines from the middle upwards in GetLeftIndicators. It would find codewords on all the lines. When it got to the top of the barcode it would continue to check (in case the start/stop indicators for those lines were corrupt/late). It would fail on the next few, as expected. However, it then matched on text pixels just above and to the right of the bar code. This ultimately caused the slope to be large in GetCodeWord. The calculated Y generated an out-of-bounds exception. The exception was caught but ultimately resulted in a valid bar code being rejected.
A solution:
This not only helps prevent noise from affecting the barcode, but it also reduces work.
@1257 in Pdf417Decoder.cs' GetCodeWord
WhiteToBlackTransition(ref LeftX, ref LeftY, DeltaX, DeltaY);
becomes
WhiteToBlackTransition(ref LeftX, ref LeftY, DeltaX, DeltaY);
if (LeftX > RightX)
{
// Looking for the WhiteToBlack transition caused us to exceed the data area of the barcode.
// If we continue and happen to match patterns on the unrelated image pixels,
// we will inadvertantly extend the data area.
return -3;
}
The GetCodeWord method would need to add the RightX parameter.
Callers to GetCodeWord will need to provide the new RightX parameter
(typically BarcodeArea.RightCenterX; in GetCodeWord perhaps ImageWidth).
Check to insure Y>=0 and Y<ImageHeight in WhiteToBlackTransition at line 1335 and 1351.
You will need to modify to return an error (or exception) and then have the caller handle that error appropriately.
This may not be required after making the previous suggested change, but it does make the code more robust.
A similar check could be made in GetCodeWord at line 1266, RevGetCodeWord at line 1302.
When the test succeeds you would then return a negative number. These methods have general catches which
return a negative number. Consequently adding a specific test is optional and only helps with debugging.
The text was updated successfully, but these errors were encountered: