too small. It detects bars on homogenous grey areas. I prefer to change it to 8.
If you think you could consider changing it I would provide some examples.
Do the debug.svg file show the picture split into black and white bars? I see in it the same picture as the source, but maybe I have no right tool for svgs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1. The area can't really be homogeneous if edges are detected?
2. Random bars shouldn't cause a problem for decoders (compare to existing decoders)
> I prefer to change to 8
These are not tunable knobs. Changing that will break other, low-contrast images.
The scanner adjusts sensitivity dynamically; the only case where increasing this threshold makes a difference is for excessively noisy images where edges are detected within bars/spaces (and it's not really the appropriate way to fix those either…)
> Do the debug.svg file show the picture split into black and white bars?
Yes, if you set the level high enough, the detected edges will be annotated.
> maybe I have no right tool for svgs.
I use Squiggle from the Apache Batik project. It is by far the best (most correct) renderer, although it tends to chew up memory. Inkscape can often render correctly as well, but I prefer the squiggle interface…
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>> It detects bars on homogenous grey areas.
>The area can't really be homogeneous if edges are detected?
For a glance of an eye they are. Correct me if I'm wrong but that's what I saw in the scanner:
When it finds a grey area it tries to detect bars in it. It supposes bars are everywhere. It lacks the feature of recognizing "not bars". Such areas should not be passed to next decoders.
I found the uncertainty and quality features, although what's called quality is not really quality, but repeatedness. That's how decoders deal with noise. It's easy for them, when the specification supplies enough checks that decrease the probability of false symbols. It's worse when the symbols are short and lack the checks. That's the case I dealt with.
And now I recall one case with existing decoder. Ean sometimes reads the wrong symbol. It happens when the camera is out of focus. It can sometimes give 2 readings: a correct one and a false one. If it could judge the picture as "out of focus" or "not bars", then it would avoid the mistake.
How could decoder mark areas as "not bars"? Calling new_scan or setting the width of "not bars" to 0. Zeros cannot not be included in any code (except as a quiet zone) so that would prevent false symbols.
I don't want to say zbar is wrong. I finally managed to tune my decoder so it should not get many false symbols and I'm happy with the results. Even with the threshold setting of 4, it seems to work ok. I'm just pointing an imperfection which you could want to fix sometime. I stumbled upon it when my decoder had very simple conditions and was looking only for quiet zones on both sides.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Spadix, I have now examples of improperly decoded bars. When I have screenshots from camera, they are recognized by zbarimg as containing codes. Then I cut the images to make them fine and small, to act like samples for the test suite. And zbarimg fails to read the codes from the small images.
I guess it's due to the inability of the dynamic scanner to adjust properly to a smaller sample. I analyzed svg with inkscape and now I see that the dummy bars disappear with the increase of the threshold. Only at the threshold of 16 the code gets readed.
I attach a small picture. By the way, svg paths from zbar have sometimes empty "d" which crash inkscape.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry, I must be missing the point here… as I tried to explain above, you are just abusing the minimum threshold setting, it does not do what you seem to think it does.
The problem with your image is poor quality - without outside bounding transitions, the scanner detects the JPEG ringing artifacts as edges. If you search these forums, you'll find that we usually recommend you blur the image to work around the problem.
A real fix would involve adding additional pipeline stages to the scanner, but I have neither the time, nor the motivation to address that right now.
> svg paths from zbar have sometimes empty "d" which crash inkscape.
Then inkscape has a bug, which you should take up with them. The SVG specification explicitly allows for empty d path attributes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Spadix, I found the value initiated in scanner.c
# define ZBAR_SCANNER_THRESH_MIN 4
too small. It detects bars on homogenous grey areas. I prefer to change it to 8.
If you think you could consider changing it I would provide some examples.
Do the debug.svg file show the picture split into black and white bars? I see in it the same picture as the source, but maybe I have no right tool for svgs.
> It detects bars on homogenous grey areas.
1. The area can't really be homogeneous if edges are detected?
2. Random bars shouldn't cause a problem for decoders (compare to existing decoders)
> I prefer to change to 8
These are not tunable knobs. Changing that will break other, low-contrast images.
The scanner adjusts sensitivity dynamically; the only case where increasing this threshold makes a difference is for excessively noisy images where edges are detected within bars/spaces (and it's not really the appropriate way to fix those either…)
> Do the debug.svg file show the picture split into black and white bars?
Yes, if you set the level high enough, the detected edges will be annotated.
> maybe I have no right tool for svgs.
I use Squiggle from the Apache Batik project. It is by far the best (most correct) renderer, although it tends to chew up memory. Inkscape can often render correctly as well, but I prefer the squiggle interface…
>> It detects bars on homogenous grey areas.
>The area can't really be homogeneous if edges are detected?
For a glance of an eye they are. Correct me if I'm wrong but that's what I saw in the scanner:
When it finds a grey area it tries to detect bars in it. It supposes bars are everywhere. It lacks the feature of recognizing "not bars". Such areas should not be passed to next decoders.
I found the uncertainty and quality features, although what's called quality is not really quality, but repeatedness. That's how decoders deal with noise. It's easy for them, when the specification supplies enough checks that decrease the probability of false symbols. It's worse when the symbols are short and lack the checks. That's the case I dealt with.
And now I recall one case with existing decoder. Ean sometimes reads the wrong symbol. It happens when the camera is out of focus. It can sometimes give 2 readings: a correct one and a false one. If it could judge the picture as "out of focus" or "not bars", then it would avoid the mistake.
How could decoder mark areas as "not bars"? Calling new_scan or setting the width of "not bars" to 0. Zeros cannot not be included in any code (except as a quiet zone) so that would prevent false symbols.
I don't want to say zbar is wrong. I finally managed to tune my decoder so it should not get many false symbols and I'm happy with the results. Even with the threshold setting of 4, it seems to work ok. I'm just pointing an imperfection which you could want to fix sometime. I stumbled upon it when my decoder had very simple conditions and was looking only for quiet zones on both sides.
Spadix, I have now examples of improperly decoded bars. When I have screenshots from camera, they are recognized by zbarimg as containing codes. Then I cut the images to make them fine and small, to act like samples for the test suite. And zbarimg fails to read the codes from the small images.
I guess it's due to the inability of the dynamic scanner to adjust properly to a smaller sample. I analyzed svg with inkscape and now I see that the dummy bars disappear with the increase of the threshold. Only at the threshold of 16 the code gets readed.
I attach a small picture. By the way, svg paths from zbar have sometimes empty "d" which crash inkscape.
Sorry, I must be missing the point here… as I tried to explain above, you are just abusing the minimum threshold setting, it does not do what you seem to think it does.
The problem with your image is poor quality - without outside bounding transitions, the scanner detects the JPEG ringing artifacts as edges. If you search these forums, you'll find that we usually recommend you blur the image to work around the problem.
A real fix would involve adding additional pipeline stages to the scanner, but I have neither the time, nor the motivation to address that right now.
> svg paths from zbar have sometimes empty "d" which crash inkscape.
Then inkscape has a bug, which you should take up with them. The SVG specification explicitly allows for empty d path attributes.