When this option is used, the threshold is adapted to the cropped
image, i.e., after the "crop" command, but not directly before.
This allows to avoid adjusting the threshold to the full image,
and thus potentially reduce the time needed for recognition.
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.
Commit 67abe0fba8 improved the
speed for determining both minimum and maximum luminance (gray)
values for the image. This speeds up some debugging output,
and also using the gray_stretch command together with option -g.
(I did not notice that initially.)
Commands with optional argument had two code paths leading
to the respective function application, one of those with
hard-coded argument "1". Instead, ensure the variable for
the optional argument is always set, and have just one
function call, always using this variable, per command.
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).
Instead of reading one byte at a time, read data in chunks
of BUFSIZ bytes.
For one example, this improves recognition time for image
data read via standard input from 281ms to 53ms. YMMV.
* 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.
When the widest digit found in the image is a one, it is likely
that a decimal separator is nearly as wide as this digit. Thus
it cannot be recognized, because the decimal separator needs to
be at most half as wide as the widest digit (before this commit).
Thus add an additional pass over the digits for this special case.
This pass comes after the existing recognition passes for the
digit one, decimal separator, and minus sign. In the new pass,
the width of the digit is ignored.
This addresses GitHub issue #26.
Neither lower case c nor lower case n can happen with correct
image segmentation. Lower case c was already used in the code,
but lower case n was only found as a comment.
I am not sure if I want to keep this or rather remove both lower
case variants. I do want to have this consistent, though.
The command name stems from the time when ssocr always considered
"white" as background and "black" as foreground. The intention
has always been to ensure some background border around the seven
segment displays, and the implementation always followed this. The
output of --help correctly uses "background" for the "white_border"
description. Now, the man page description is correct, too.
The latest release date is extracted from the NEWS file,
i.e., it depends only on the sources, not the build date.
This is intended to help in creating reproducible builds
by avoiding timestamps. It is also closer to the date of
the contents of the man page than using just the latest
copyright year.
I do not have a perfect solution that works for both a git
clone and a downloaded tar ball. This solution works well
for released tar balls of the ssocr sources.
Erik Auerswald