Fails to recognise number 7

[anfractuosity]

First of all, thanks for the awesome program!

Just wondering if you have any idea why the following fails:

https://www.anfractuosity.com/files/lcd_fail.jpg

But the following works:

https://www.anfractuosity.com/files/lcd_works.jpg

Thanks a lot!

[auerswal]

Hi,

answer via email, just to find out if this actually works. ;-)

On Sun, May 21, 2017 at 06:17:41PM -0700, Chris wrote:

First of all, thanks for the awesome program!

:-)

Just wondering if you have any idea why the following fails:

https://www.anfractuosity.com/files/lcd_fail.jpg

But the following works:

https://www.anfractuosity.com/files/lcd_works.jpg

Yes, I do. the digits are tilted which results in the lower right segment of the 7 to be seen as part of the bottom segment. See the attached picture "problem.png" (created using the -D option to ssocr).

A solution to this is using the "shear" command of ssocr:

$ ssocr -d-1 shear 65 lcd_fail.jpg
19.7

As a side effect, the decimal point is detected correclty as well. It was seen as part of the 2nd digit before. This works for the working picture as well:

$ ssocr -d-1 shear 65 lcd_works.jpg -D
20.0

One problem with the pictures and the "shear" command is that pixels are moved out of the image. You could avoid that by using a larger width (W) value for the "crop" command. If there are pixels at the border, you can use the "white_border" command to change border pixels to the background color.

I'll take a look at the GitHub issue tracker later.

Thanks, Erik -- Do things that have never been done before. -- Russell Kirsch

[anfractuosity]

That works great for those images! Thanks.

I'm still having issues with 2017-05-22-2020.jpg, which I've linked to below.

While 2017-05-24-1140.jpg works ok. You can see I try different thresholds to essentially find one which works, but this fails for the latter image. (You'll note i'm actually doing this with 7 seg LEDs).

#!/bin/bash
for f in 2017-05-24-1140.jpg 2017-05-22-2020.jpg; do
    X=0
    for I in 50 30 40 60 70; do
        Z=$(./ssocr -t $I -d 3 shear 65 make_mono invert crop 624 580 1220 760 $f -o dump.jpg)
        if [ $? -eq 0 ]; then
            X=1
            break
        fi 
    done

    if [ $X -eq 0 ]; then
        echo "Failed to detect $f"
    else
        echo "Detected $Z"
    fi
done

https://anfractuosity.com/files/2017-05-24-1140.jpg https://anfractuosity.com/files/2017-05-22-2020.jpg

It should produce output like:

found too many digits (4)
Detected 202
found too many digits (4)
found too many digits (4)
found too many digits (4)
found too many digits (4)
found too many digits (4)
Failed to detect 2017-05-22-2020.jpg

Showing it can detect the first image, but not the second.

[auerswal]

Hi Chris,

On Wed, May 24, 2017 at 03:57:10AM -0700, Chris wrote:

First of all, thanks a lot for the reply, that works great for those images.

:-)

I'm still having issues with 2017-05-22-2020.jpg, which I've linked to below.

I'll take a look at it soon. The image looks like reliable recognition should be possible.

While 2017-05-24-1140.jpg works ok. You can see I try different thresholds to essentially find one which works, but this fails for the latter image. (You'll note i'm actually doing this with 7 seg LEDs).

That you are using LED based seven segment displays should help a lot for recognition. Since the LEDs in the images are more or less red, you could try "r_threshold" instead of "make_mono." You can try the option -T To find a suitable threshold automatically.

Thanks, Erik -- Always use the right tool for the job. -- Rob Pike

[anfractuosity]

I've had a little play with using r_threshold and some of the different filters such as erosion and dilation to no avail unfortunately with 2017-05-22-2020.jpg.

cheers Chris

[auerswal]

Hi Chris,

On 05/25/2017 11:47 AM, Chris wrote:

I've had a little play with using r_threshold and some of the different filters such as erosion and dilation to no avail unfortunately with 2017-05-22-2020.jpg.

That is an interesting problem...

Using r_threshold, the decimal point is likely to join the 2nd and 3rd digits. Using normal thresholding, the segments are separated too much for segmentation to work correctly.

What works for the two images 2017-05-24-1140.jpg and 2017-05-22-2020.jpg is cropping away the decimal point together with r_threshold:

$ ssocr -d3 rotate 358 crop 624 580 1210 630 shear 65 r_threshold -a \ -t90 -f white 2017-05-22-2020.jpg 203 $ ssocr -d3 rotate 358 crop 624 580 1210 630 shear 65 r_threshold -a \ -t90 -f white 2017-05-24-1140.jpg 202

Rotation reverses the camera's rotation (more or less), crop removes the decimal point and degree sign, shear straightens the digits, r_threshold uses the LED color, -a -t90 uses a very high (unadjusted) threshold value to distinguish between back- and foreground, and -f white tells ssocr that the digits are lighter than the background.

Thanks, Erik

[anfractuosity]

Thanks a lot for all the help! That fixed the issues! I also found out about '-i' which also helped fix some other issues with my images.

https://www.anfractuosity.com/projects/fermentation-temperature-control-with-inkbird-308/

Is what it was for in case you're interested. Thanks again.

[auerswal]

Great that this worked for you! :-)

I have added a link to your project on the ssocr homepage (https://www.unix-ag.uni-kl.de/~auerswal/ssocr/) and will close this issue.

Thanks, Erik