Instead of adapting the threshold to the image before executing
commands, adapt the threshold just before it is needed.
This allows to avoid theshold adaptation when -p, --process-only
is used with only the "grayscale" and/or "mirror" commands.
This also prepares the code to allow introduction of a new option
to avoid adapting the threshold to the original image before the
"crop" command is applied.
Both functions are always called with the same arguments.
Only the get_threshold() function is also called with
different x, y, w, h arguments (when used during dynamic
thresholding).
* The draw_pixel() function was called with an "image" parameter
of type "Imlib_Image" instead of "Imlib_Image *". This type
error did not result in a compilation error, and thus stayed
undetected in the code.
* Introduce a new function draw_color_pixel() similar to draw_pixel(),
and use it instead of repeatedly open-coding this operation.
The removed code was intended to clear the image to allow
only drawing foreground pixels in the following loop. But
it only drew the outline of a rectangle and thus did not
clear the image as intended.
Since the image is not cleared, the following loop already
draws every pixel, overwriting any previously drawn rectangle
anyway.
Some image manipulation functions use trigonometric functions.
This includes using the number Pi. Pi is often available as
M_PI via including <math.h>. This constant is part of the Unix98
standard, not the C standard itself. According to the GCC
documentation[1], M_PI is only defined when the feature selection
macro _XOPEN_SOURCE=500 is used. This seems to be default in
many versions of GNU/Linux, since ssocr could always use M_PI
without explicitly setting _XOPEN_SOURCE=500.
An MPlayer bug report[2] reported a build failure because M_PI
was not defined. This lead to a patch[3] to work around this
problem.
I want to avoid running into this specific problem in the future,
without introducing significant changes to ssocr. Thus I check
if M_PI is defined after inlcuding <math.h>, and define it myself
if it is missing. I use the value found in /usr/include/math.h
from GNU Libc on my current system (Ubuntu GNU/Linux 20.04.6 LTS).
[1] https://www.gnu.org/software/libc/manual/html_node/Mathematical-Constants.html
[2] https://trac.mplayerhq.hu/ticket/2423
[3] https://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2024-December/074244.html
Also add '+' to the version number to indicate changes after the
latest release.
This introduces a function to scan part of the image for foreground
pixels.
This scanline() function may be of use for distuingishing between
the digit '1' and the symbol ":".
It may also help in segment detection reliability if the "len" parameter
is used to skip scanning image areas between segment positions.
and bumped version number to 2.13.4.
As a result my regression tests using the _broken_ dynamic_threshold fail:
testing images in first2...FAILED
testing images in neu...FAILED
testing images in pics-2005-11-12...FAILED
testing images in schlechte_bilder...FAILED
testing images in new_token_2008-11-07...FAILED
testing images in calc_dyn_thresh...FAILED
But at least I do understand now why dynamic_threshold did not work as I had
expected...I just did not see the error until today.
This relies on the definition of enum _imlib_load_error in Imlib2.h
and might break on different versions of Imlib2, but should be better
than the total lack of error reporting before.
Developed with Imlib2 version 1.4.5 from Debian/Sid:
$ dpkg -l libimlib2-dev
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-============-============-=================================
ii libimlib2-dev 1.4.5-1 i386 Imlib2 development files
All calls to this function have been replaced by calls to make_mono()
with the appropriate luminance type (minimum, red, green, or blue).
This way --foreground / --background work with the commands
{r,g,b,rgb}_threshold as expected.
Problem was "shear" setting background pixels using the specified
--background color, but rgb_threshold() always using the default colors
(foreground black, background white), ognoring the options.
Added a formerly failing test case to the regression tests:
Lauro-LEDs-digits-fore_back
- no functional changes
- this is another step towards refactoring the recognition algorithm
- this is another step towards factoring out the image access routines to
ultimately replace Imlib2 by something else (e.g. gd)
Erik Auerswald