Closed GoogleCodeExporter closed 9 years ago
The previous code didn't really do barcode detection. I've added a new
DetectBarcode
class to the barcode library and used it in ReadBarJ. I believe you will find
performance is much better. ReadBarJ will show the area of the image it
detected the
barcode and also outline the approximate barcode edges with green lines. I
updated
the source tree and also uploaded a new JAR file for ReadBarJ.
Original comment by jonaw...@gmail.com
on 27 Jun 2008 at 8:15
I created a larger monochrome version of barcodeEAN.png (see attached
barcode_clean.png image). All pixels
are 0x000000 or 0xFFFFFF. Each bar is exactly 3, 6, 9, or 12 pixels wide. The
total width of the barcode is
285 pixels, centered within a 640 x 480 image with 0xFFFFFF background.
The output from the latest J2SE build is "The barcode could not be read". The
debug images look correct (see
attachments); and the cYLeft, cYRight, wSlopeLeft, and wSlopeRight values
passed to
BarcodeReaderEan13.Decode() look good. szCode is estimated as 8269992866737,
4084483768866,
5003443366630, and 1906153945336. Estimated offsets seem good, so it appears
there may be a bug in
estimating the left and right codes? Or maybe my image is just too perfect
whereas the correlations expect
more randomness?
Original comment by hanso...@gmail.com
on 1 Jul 2008 at 9:42
Attachments:
Reattaching the image I created, which didn't upload correctly the first time.
Original comment by hanso...@gmail.com
on 1 Jul 2008 at 9:45
Attachments:
-BarcodeReaderEan13.java line 800-803:
// estimate position of the middle of the barcode
// this will be the position of the second 0 in the
// string "0101010"
int dMidOffset =
It seems from the code that the string should be "1010101" where dMidOffset
estimates the position of the second 1 (the first black bar in the "01010"
center guard pattern)? At
least this is what the code estimates (x=187 in my attached cropped.png). Or
is the intention to estimate the left edge of the center guard pattern?
-BarcodeReaderEan13.java line 813-816:
// estimate position of the right of the barcode.
// this will be the position of the second 0 in the
// string "1010000"
int dRightOffset =
It appears the code actually estimates the position of the first 0 (x=328 in my
attached cropped.png). Is this intentional, or should it be matching the
second 0 as suggested in the
comment?
Original comment by hanso...@gmail.com
on 1 Jul 2008 at 11:04
Narrowed the problem down to the following code from BarcodeReaderEan13.java
(lines 1386-1393):
private byte[] Stretch(byte[] bInput, int dLeft, int dRight, int dTargetWidth) {
int dWidth = dRight - dLeft;
byte[] bResult;
if (dWidth % dTargetWidth == 0) {
bResult = new byte[dTargetWidth];
System.arraycopy(bInput, dLeft, bResult, 0, dTargetWidth);
return bResult;
}
in the case that (dWidth % dTargetWidth == 0), we should be creating a byte
Array of width dWidth rather
than dTarget width. The current code truncates the array at the target width
when the original data may have
been a multiple of the target width.
Original comment by hanso...@gmail.com
on 1 Jul 2008 at 11:47
For the sake of completeness, the fix is (BarcodeReaderEan13.java lines
1390-1391):
bResult = new byte[dWidth];
System.arraycopy(bInput, dLeft, bResult, 0, dWidth);
Original comment by hanso...@gmail.com
on 1 Jul 2008 at 11:53
Thanks, hansomli. I've made the change you suggested to the code and have given
you
credit. The code now reads the 'original.png' image correctly. Please verify if
you
have time.
Original comment by jonaw...@gmail.com
on 18 Jul 2008 at 1:47
Original issue reported on code.google.com by
hanso...@gmail.com
on 21 Jun 2008 at 6:27