#173 wpic/rpic don't support 16bit png
wpic will write a 16-bit grayscale PNG file
rpic reads back the file as an 8-bit image
with incorrect image values.
The problem can be seen with the following
script in the perldl shell:
perldl> $a = sequence(256,255)->ushort
perldl> $a->wpic('a-ushort.png')
perldl> #identify a-ushort.png
a-ushort.png PNG 256x255 256x255+0+0 PseudoClass 65536c 16-bit 116.227kb
perldl> $b = rpic('a-ushort.png')
perldl> ?vars
PDL variables in package main::
Name Type Dimension Flow State Mem
----------------------------------------------------------------
$a Ushort D [256,255] P 0.12Mb
$b Byte D [256,255] P 0.06Mb
The problem is that the Netpbm tools used here
now transparently support raw 16-bit PGM and PPM
images while the rpic/wpic/pnminraw... code only
reads raw in bytes. The pnminraw function needs
to be updated to support higher bit depth raw
reads and the rpic/wpic need mods to allow that.
This may be the origin of the failure to use
16-bit tiff format as well.
Logged In: YES
user_id=44920
Originator: YES
Bug fixed in CVS.
Thanks for reporting the problem!
Logged In: YES
user_id=44920
Originator: YES
I've submitted a fix to CVS that appears to work with PNM and PNG
file formats. It should be extendable to TIFF and other 16-bit formats.
Logged In: YES
user_id=44920
Originator: YES
Verified again that the 16-bit tests pass for rpic/wpic with PDL-cvs. Set status to Pending.
Logged In: YES
user_id=1312539
Originator: NO
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
Re-opening this ticket because I just discovered
that byte-swap issues can arise in the current
implementation of 16-bit PNG support.
We need to determine if the problem can be resolved
transparently from info in the PNG file and from the
system configuration. If not, at least the use of bswap2
to correct the data should be added to the POD.
PNG uses network byte order so if the pngtopnm conversion
is returning the PNG file byte order rather than the platform
byte order, that would explain the need for a swap. If that is
the case, then a multibyte PNG file would always need a
bswap2 for windows since it is a little-endian platform.
The de facto standard for binary PNM file formats is big-endian
so for little endian platforms reading 16-bit PNG files requires
a bswap2 operation and similarly for higher pixel depths.
Reviewing the PDL::IO::Pnm code, it appears that proper
care is not taken in raw PNM image input and output.
When the samples are multiple bytes long then they
should be in network byte order (big endian). The current
code does not even check this. If this were fixed, then
the issue with 16-bit PNG IO should be resolved as well.
I cannot reproduce the problem so am closing this ticket.
If the issue arises again, be sure to provide a test case to
demonstrate the problem.