Bug 63727 - ImageMagick fails to handle RGBA files
Summary: ImageMagick fails to handle RGBA files
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: ImageMagick   
(Show other bugs)
Version: 7.2
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jonathan Blandford
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-04-17 22:26 UTC by Andy Ross
Modified: 2013-04-02 04:16 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-05-12 12:20:48 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Andy Ross 2002-04-17 22:26:55 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:0.9.9) Gecko/20020326

Description of problem:
Make a trivially simple .pgm file (one black pixel):

  % cat test.pgm
  P2
  1 1
  255
  0

Convert it to a raw RGBA quadruple and verify that the results are
correct (3 zero bytes followed by an alpha of 255):

  % convert test.pgm test.rgba

  % hexdump test.rgba
  0000000 0000 ff00                              
  0000004

Try to display it:

  % display -size 1x1 test.rgba
  
The display program enters an infinte loop in ImageMagick 5.3.8, but
worked fine in older versions.  I just compiled 5.2.6 from source, and
that version handles this just fine.  Other clients fail as well when
reading the .rgba file -- it appears to be the handling of RGBA format
that is the problem.

Andy

Comment 1 Andy Ross 2003-03-03 19:36:32 UTC
Cool.  Someone's working on this. :)

This problem is fixed in more recent versions of ImageMagick.  The one shipped
with RH8.0 (don't know the version off the top of my head) displays the file
correctly if(!) -depth 8 is specified on the command line.  ImageMagick (sigh)
changed the command line interface incompatibly at some point; the default depth
for "raw" image formats is now 16 bits instead of 8.  The infinite loop bug was,
I suspect, a symptom of this -- it got a shorter file than it expected, and choked.


Note You need to log in before you can comment on or make changes to this bug.