[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Openexr-devel] Color Management Proposal / Siggraph meeting
From: |
Florian Kainz |
Subject: |
Re: [Openexr-devel] Color Management Proposal / Siggraph meeting |
Date: |
Fri, 13 Aug 2004 18:13:14 -0700 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030314 |
I guess I should have been more careful about the wording of the
section on painting:
In the proposal, we suggest that all OpenEXR images live in the color
space that we call scene-referred. Several people had asked how one
would paint a scene-referred image. One possibility is to make the
paint software aware of the proposed color management scheme. In this
case all image manipulations happen in scene-referred space; in order
to display the image, the paint program continuously applies the SROM,
OMRD and RDPD.
The example where a primitive paint program saves images in a file
format where pixel values correspond more or less directly to screen
frame buffer values was meant to illustrate that this case can handled
in our scheme: Even if all you have is an image that lives in the
display's color space, you can derive a scene-referred image from it.
The example is not meant as an attack on Photoshop or on any other
software with built-in ICC profile support.
Our color management proposal is meant to work in a film and video
production environment, where ICC profiles have, for whatever reason,
not been successful. I don't really care whether the concepts described
in the proposal describes are a subset or a superset of ICC profiles
(I think they are neither). The proposal attempts to address problems
specific to film production.
Florian
Chris Cox wrote:
A few notes:
A paint program does not necessarily paint directly into the display
framebuffer - it paints into an offscreen buffer and transforms the
color data to the display framebuffer. Thus the painting may exist in a
colorspace totally unrelated to the display device(s) used.
So paintings should have an image colorspace, with no reference to the
display or framebuffer.
The inverse display transform should not be involved unless you are
dealing with a primitive paint system that does draw directly to the
framebuffer (at which point you simply use the display profile for the
image colorspace).
There is already a well known and well used framework for describing
color transformations: ICC profiles. They do have limitations with
regard to HDR data - but that could be fixed. Defining yet another
color transformation syntax seems a bit silly.
Yes, the concept you describe is sound: because it is a subset of the
well proven concepts already in use within the ICC color management
framework available in many professional applications and implemented in
common desktop OSes.
Chris
Re: [Openexr-devel] Color Management Proposal / Siggraph meeting, Thad Beier, 2004/08/13