Re: openexr support

On Tuesday 14 August 2007, Bob Friesenhahn wrote:

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

We had to solve the same problem a few years ago for Krita, which was 
originally based internally on ImageMagick code, so had a compile switch to 
go from 8 to 16 bits/channel.

While I don't claim our solution is optimal -- there's a performance penalty 
to pay -- we've managed to create an architecture that can support pretty 
much anything, from single 8-bit channel grayscale to hdr, to LMS (whatever 
that may be...) to kubelka-munk.

We did it by having a pixel store that only knows how many bytes there are in 
a single pixel and a color model library that knows how pixels are created, 
can convert between color models and has a big set of methods to mess with 
pixels. The color model library (provisionally called pigment, but we have to 
change that because of a name clash with blender) just gets bytes and has to 
interpret those.

All in all, it works pretty well. Code at 
http://websvn.kde.org/trunk/koffice/libs/pigment and 
https://www.websvn.kde.org/trunk/koffice/krita/image/tiles.


-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi

-------------------------------------------------------------------------
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/

_______________________________________________
Graphicsmagick-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/graphicsmagick-core

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBGwUmTdaCcgCmN5d8RAitEAJ42D0ZxeW+Hm/YVzRm0WOO0i27lyQCfUmAR
4MXnn32jUV+kUraTLOsMuWQ=
=/gHg
-----END PGP SIGNATURE-----