Re: openexr support

On Tue, 14 Aug 2007, Miles Bader wrote:
>
> Hmmm, while I can certainly write code to read/write openexr format
> (using the libraries :-), from your subsequent description, it sounds
> like the main issue is deciding exactly how to handle the necessary
> translation to the internal formats (e.g., how to parameterize it, as I
> guess you'd certainly want that).

You hit the nail on the head there.  Since GM can not support the 
full HDR range, it is necessary for the user to decide what parameters 
are best to preserve the image the way they want to see it.  I 
understant that OpenEXR provides some default parameters to produce 
the ideal image for viewing.

>> ImageMagick has been recently adding some HDR support.
>
> Do you have ideas about your future directions?  Are you going to try
> and follow what imagemagick is doing?

While I would (of course) like to support HDR in GraphicsMagick, I 
don't have the bandwidth to support it myself at the moment.  With 
additional volunteers it could become possible.

> I looked around on the imagemagick website, and AFAICT, the internal
> representation is fixed at compile-time for all operations, which seems
> pretty sub-optimal....  I don't really mind the bloat in most cases from
> using floats, as I generally use the info anyway, but I can see that
> people processing enormous fax images might be a bit peeved... :-)

Yes, and in fact this is the important issue to solve.  There is 
already a big problem with enormous fax images.  If there is an 
ability to dynamically support multiple image models, then far more 
becomes possible.  I think that the solution here is to decouple image 
storage from presentation.  Image storage is where the pixels go while 
they are not being actively used.  Presentation is what the algorithms 
see while they are using the pixels.  An algorithm which would 
naturally want to use floating point pixels should be given floating 
point pixels to work with.

> [What exactly is the connection between graphicsmagick and imagemagick
> anyway?  Do you generally track imagemagick changes, or are the
> codebases more or less permanently diverged?]

The codebases are permanently diverged.  ImageMagick changed its 
license to one which impedes importing code into GraphicsMagick, even 
though it still uses an open source license.  Even before that time, 
imports of code into GraphicsMagick were quite limited, and in fact 
far more code has been imported into ImageMagick from GraphicsMagick 
(Windows build, Unix build improvements, patterns, test suite).

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/