Your message dated Sun, 14 Jan 2024 16:51:41 +0100 with message-id <[email protected]> and subject line Re: Bug#343517: netpbm: pnmnorm -keephues: overflow/underflow has caused the Debian Bug report #343517, regarding netpbm: pnmnorm -keephues: overflow/underflow to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 343517: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=343517 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---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
--- End Message ---
--- Begin Message ---Version: 2:11.05.01-1 On 2005-12-15 Don Geddis <[email protected]> wrote: > 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.) I cannot reproduce the erranous behavior on current netpbm. > 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. [...] FYI the docs/behavior have also been updated: This option says to keep each pixel the same hue as it is in the input; just adjust its brightness. You normally want this; the only reason it is not the default behavior is backward compati‐ bility with a design mistake. By default, pnmnorm normalizes contrast in each component inde‐ pendently (except that the meaning of the -wpercent and -bper‐ cent options are based on the overall brightnesses of the col‐ ors, 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. cu Andreas
--- End Message ---
