Package: netpbm
Version: 2:10.0-10
Severity: normal
When running "pnmnorm -keephues" on some very dark images, a scattering of
the dark pixels turn bright white. I believe this to be an error, probably
as a result of some over/underflow in the mathematics.
I've attached three sample images below: an original dark photo, a version
normalized with just "pnmnorm", and a second with "pnmnorm -keephues". (All
have been additional compressed with gzip.)
The original image has intensities in the range 0..14 (which get mapped to
0..255). The second image, with just pnmnorm, shows a reasonable
contrast-enhanced version of the original. You'll notice that the sky and
ground/sea is mostly white in the third image, even though the brightest
pixels in the original image are in a horizon line, and a central ball.
One question might be, what is "-keephues" supposed to try to achieve? My
expectation as a layperson is that pnmnorm by default should just enhance
contrast as much as possible, perhaps making a false-color image in the
meantime. Whereas the "-keephues" option ought to be better as a default
option for most photographs, as it would try to improve the contrast, but
without color-shifting any pixels.
The man page says this:
The -keephues option says to keep each pixel the same hue as it is in
the input; just adjust its intensity. By default, pnmnorm normalizes
contrast in each component independently (except that the meaning of
the -wpercent and -bpercent options are based on the overall intensi-
ties of the colors, not each component taken separately). So if you
have a color which is intensely red but dimly green, pnmnorm would make
the red more intense and the green less intense, so you end up with a
different hue than you started with.
If you specify -keephues, pnmnorm would likely leave this pixel alone,
since its overall intensity is medium.
-keephues can cause clipping, because a certain color may be below a
target intensity while one of its components is saturated. Where
that's the case, pnmnorm uses the maximum representable intensity for
the saturated component and the pixel ends up with less overall inten-
sity, and a different hue, than it is supposed to have.
Note the discussion of clipping. That suggests that such a saturated pixel
would end up darker than without "-keephues", in order to maintain the
original color.
But nothing I read in that documentation would lead me to expect the horrible
result in the third image, where bright sky and ground seem to appear out of
nowhere. That result sure looks like a bug to me. It seems wrong that the
"-keephues" option results in a less photo-realistic scene than without it.
-- Don
Original image:
<#part type="application/octet-stream" filename="~/samba/DropOff/d180.pnm.gz"
disposition=attachment description="original">
<#/part>
pnmnorm:
<#part type="application/octet-stream"
filename="~/samba/DropOff/d180-norm.pnm.gz" disposition=attachment
description="with pnmnorm">
<#/part>
pnmnorm -keephues:
<#part type="application/octet-stream"
filename="~/samba/DropOff/d180-hues.pnm.gz" disposition=attachment
description="with pnmnorm -keephues">
<#/part>
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-1-686-smp
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ANSI_X3.4-1968) (ignored: LC_ALL
set to C)
Versions of packages netpbm depends on:
ii libc6 2.3.5-8 GNU C Library: Shared libraries an
ii libjpeg62 6b-10 The Independent JPEG Group's JPEG
ii libnetpbm10 2:10.0-10 Shared libraries for netpbm
ii libpng12-0 1.2.8rel-5 PNG library - runtime
ii libtiff4 3.7.4-1 Tag Image File Format (TIFF) libra
ii zlib1g 1:1.2.3-8 compression library - runtime
Versions of packages netpbm recommends:
ii gs-afpl [gs-aladdin] 8.14-3 The AFPL Ghostscript PostScript in
ii gs-esp [gs] 8.15.1.dfsg.1-1 The Ghostscript PostScript interpr
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
