#265 Threshold value is being divided by 100.0 twice

[Carl Ellis]

Threshold value on gm convert utility is being divided by 100.0 twice.

gm convert -threshold 8 in.png out.png

acts the same as

gm convert -threshold 0.08 in.png out.png

Was correct behaviour at version 1.3.18, unable to determine in diff where it is broken.

[Bob Friesenhahn]

There was no change to GraphicsMagick source code since 1.3.18 which might influence this. Values without a trailing percent (%) symbol are used as absolute values. Values with a trailing percent symbol (50%) are scaled to that percentage of the range.

Please tell us more so I can try to reproduce the problem (works for me). What operating system is GraphicsMagick running on and what compiler was used? What is the first line of 'gm -version' output? What is the PNG library version used?

[Carl Ellis]

Running Archlinux 3.12.9-2-ARCH #1 SMP PREEMPT Fri Jan 31 10:22:54 CET 2014 x86_64 GNU/Linux

Using libpng 1.6.8-1

Output of gm version

~~~~~
GraphicsMagick 1.3.19 2013-12-31 Q16 http://www.GraphicsMagick.org/
Copyright (C) 2002-2013 GraphicsMagick Group.
Additional copyrights and licenses apply to this software.
See http://www.GraphicsMagick.org/www/Copyright.html for details.

Feature Support:
Thread Safe yes
Large Files (> 32 bit) yes
Large Memory (> 32 bit) yes
BZIP yes
DPS no
FlashPix no
FreeType yes
Ghostscript (Library) no
JBIG no
JPEG-2000 yes
JPEG yes
Little CMS yes
Loadable Modules yes
OpenMP yes (201107)
PNG yes
TIFF yes
TRIO no
UMEM no
WMF yes
X11 yes
XML yes
ZLIB yes

Host type: x86_64-unknown-linux-gnu

Configured using the command:
./configure '--prefix=/usr' '--enable-shared' '--with-modules' '--with-perl' '--with-gs-font-dir=/usr/share/fonts/Type1' '--with-quantum-depth=16' '--with-threads' 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4' 'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro' 'CPPFLAGS=-D_FORTIFY_SOURCE=2' 'CXXFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4'

Final Build Parameters:
CC = gcc -std=gnu99
CFLAGS = -fopenmp -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -Wall -pthread
CPPFLAGS = -D_FORTIFY_SOURCE=2 -I/usr/include/freetype2 -I/usr/include/libxml2
CXX = g++
CXXFLAGS = -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -pthread
LDFLAGS = -Wl,-O1,--sort-common,--as-needed,-z,relro -L/usr/lib -L/usr/lib
LIBS = -llcms2 -lfreetype -lXext -lSM -lICE -lX11 -llzma -lbz2 -lz -lltdl -lm -lgomp -lpthread

Works as expected when using '%' in the string.

Attached test file and outputs on my machine:

gm convert -threshold 100 in.png 100.png
gm convert -threshold 5500 in.png 5500.png
gm convert -threshold 1% in.png 1p.png
gm convert -threshold 50% in.png 50p.png
~~~~

Also added some manual gimp thresholds at absolute values 1 and 55 as 1gimp.png and 55gimp.png for reference.

[Bob Friesenhahn]

One last question for you is if you are using any special locale
settings (internationalization settings) on your system that might
cause character sets or numbers to be interpreted differently. For
example, this is what is on the Linux system I am using at this
instant:

LANG=en_US.UTF-8

[Carl Ellis]

$ locale

LANG=C
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=

[Bob Friesenhahn]

If you built GraphicsMagick from source code yourself, does 'make
check' succeed for most/all tests or are there many failures?

[Glenn Randers-Pehrson]

Was your 1.3.18 a Q8 build? -threshold 8 on a Q8 build is the same as
-threshold 2056 on a Q16 build, but -threshold x% is the same on both.

[Bob Friesenhahn]

GIMP only supports values between 0 and 255. The default thresholding level in GIMP is 127, which is 50% of its range. The equivalent in Q16 GraphicsMagick (supporting values between 0 and 65535) is 32767.

The reason why the raw values 8 and 0.08 produce similar results is due to this:

(8/65535)*100
.01220700
(0.08/65535)*100
.00012200
(1/255)*100
.39215600

From the above, you can see that both are less than one count when the range is only 0 to 255. Both result in thresholding most pixels to white.

I am not seeing any issue with the results you posted. Unless you add a percent symbol, GraphicsMagick uses a raw value (as GIMP seems to do) but a Q16 GraphicsMagick supports vastly more levels than GIMP does.

I do recall discussing the introduction of more depth with the Arch Linux GraphicsMagick maintainer (because GNU Octave wants more depth).

[Carl Ellis]

Ahh I see, in which case I am getting correct behaviour.

I will correct my code, thank you for your time in responding.