Re: [png-mng-implement] Writing 16-bit grayscale PNG, get 8-bit per channel?

[Glenn Randers-P. <gl...@gm...>]

On Fri, May 1, 2015 at 9:12 PM, Greg Roelofs <ne...@po...> wrote:

> Liviu Nicoara <nik...@ha...> wrote:
>
> > Library is 1.6.17, installed via Mac Ports.
>
> > I am trying to write out a 16-bit grayscale PNG (no alpha). All
> > pixels have one of 16 distinct values. The image I get is then
> > identified by ImageMagick as:
>
> > Image: wide.png
> >   Format: PNG (Portable Network Graphics)
> >   Mime type: image/png
> >   Class: DirectClass
> >   Geometry: 800x600+0+0
> >   Units: Undefined
> >   Type: Grayscale
> >   Base type: Grayscale
> >   Endianess: Undefined
> >   Colorspace: Gray
> >   Depth: 16/8-bit
> >   Channel depth:
> >     gray: 8-bit ...
>
> > The 8-bit per channel puzzles me to no end. However, if I set
> > pixels to take values in a larger range of shades of gray I get
> > a “good” image:
>
> > Image: wide.png
> >   Format: PNG (Portable Network Graphics)
> >   Mime type: image/png
> >   Class: DirectClass
> >   Geometry: 800x600+0+0
> >   Units: Undefined
> >   Type: Grayscale
> >   Base type: Grayscale
> >   Endianess: Undefined
> >   Colorspace: Gray
> >   Depth: 16-bit
> >   Channel depth:
> >     gray: 16-bit ...
>
> > The gray channel now is being reported as 16-bit. I am pretty
> > sure this is not an artifact of ImageMagick reporting. Anybody
> > has any idea?
>
> Some tools (e.g., pnmtopng) will intentionally optimize the bit depth to
> the smallest possible that can losslessly encode the values in order to
> save space (i.e., higher compression).  In this case, if you have only
> 16 gray levels, it's entirely possible that they're all evenly divisible
> by 256 and therefore perfectly representable by 8-bit samples.
>
> That said, I don't recall libpng doing that, at least not without some sort
> of configurable override.  But maybe it does now?  The other possibility is
> that this is indeed part of ImageMagick's display path and that it's doing
> its own conversion; "DirectClass" is reminiscent of X11 display
> terminology.
> You could use pngcheck (or even Unix file(1)) as independent verification.
> I'll vouch for it--it does nothing but report what's there, all the way
> down to the per-pixel level if you request it.
>

ImageMagick reports the precision depth, not the actual stored depth
of the image.  So if all pixels in a 16-bit image contain samples that
have highbyte == lowbyte, it will report "8", since the image can be
represented precisely even when the samples are all chopped down to
8 bits.

Use "pngcheck -v" to find out the actual bit depth of the PNG file.

Or with recent versions of ImageMagick, read further down and
look at the -verbose output for

      png:IHDR.bit-depth-orig: 16