Re: openexr support

On Wed, 8 Aug 2007, Miles Bader wrote:

> Hi,
>
> Excuse me if this is a silly question, but is there any particular
> reason why graphicsmagick doesn't support the openexr format yet?
> It seems like one of the most (or the most) popular HDR formats, and
> apparently it's been on the graphicsmagick wishlist for at least a
> couple of years.

The particular reason is that we have lacked a volunteer (such as 
yourself) to implement the support.  I know that it is not difficult 
to implement.  Your contribution would be very much appreciated.

> Given that graphicsmagick supports logluv tiff (etc), I assume that it
> is internally capable of representing an HDR image, and in my
> experience, using the opennexr libraries is dead simple -- I implemented
> openexr I/O for a personal project, and the meat of the code is only
> about 25 lines (doing simple row-by-row I/O)!

GraphicsMagick is not internally capable of representing an HDR image 
even though it can support as much as 32 bits per sample (depending on 
build options).  Either the range needs to be clipped (to produced a 
normally viewable sRGB image), or the HDR needs to be scaled into a 
range which is wrong for viewing.

Given the current situation, OpenEXR support in GraphicsMagick is 
primarily useful as an export/import mechanism for other image 
formats.

> It'd be very handy to have a general-purpose graphics toolkit with
> decent hdr support...

ImageMagick has been recently adding some HDR support.  I played with 
it a bit and it did seem to eliminate clipping and performance was 
reasonable for RGB images.  It is difficult to determine how "decent" 
the support is based on just a few algorithms.  ImageMagick built with 
HDR support is terribly inefficient for bilevel images since a single 
bit worth of information is expanded to 32-bit floats.  A single 
bilevel pixel (requiring one bit of file storage) would consume 18 
bytes!  The HDR values are scaled similar to typical integer ranges 
(e.g. 0.0-255.0) rather than typical floating point ranges (e.g. 
0.0-1.0) in order to avoid huge problems when dealing with traditional 
image formats.  The vast legacy and flexibility of 
ImageMagick/GraphicsMagick tends to resist change.

Bob
======================================
Bob Friesenhahn
[email protected], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/