#173 wpic/rpic don't support 16bit png

closed-works-for-me
None
5
2011-07-23
2007-12-14
No

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.

Discussion

  • Chris Marshall

    Chris Marshall - 2007-12-15

    Logged In: YES
    user_id=44920
    Originator: YES

    Bug fixed in CVS.
    Thanks for reporting the problem!

     
  • Chris Marshall

    Chris Marshall - 2007-12-15
    • assigned_to: nobody --> marshallch
    • status: open --> open-fixed
     
  • Chris Marshall

    Chris Marshall - 2007-12-15

    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.

     
  • Chris Marshall

    Chris Marshall - 2008-07-19

    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.

     
  • Chris Marshall

    Chris Marshall - 2008-07-19
    • status: open-fixed --> pending-fixed
     
  • SourceForge Robot

    • status: pending-fixed --> closed-fixed
     
  • SourceForge Robot

    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).

     
  • Chris Marshall

    Chris Marshall - 2011-07-11

    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.

     
  • Chris Marshall

    Chris Marshall - 2011-07-11
    • status: closed-fixed --> open-accepted
     
  • Chris Marshall

    Chris Marshall - 2011-07-12
    • priority: 7 --> 5
     
  • Chris Marshall

    Chris Marshall - 2011-07-12

    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.

     
  • Chris Marshall

    Chris Marshall - 2011-07-15

    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.

     
  • Chris Marshall

    Chris Marshall - 2011-07-16

    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.

     
  • Chris Marshall

    Chris Marshall - 2011-07-23

    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.

     
  • Chris Marshall

    Chris Marshall - 2011-07-23
    • status: open-accepted --> closed-works-for-me
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks