Am 22.05.05, 15:25 +1000 schrieb Graeme Gill:
> Bob Friesenhahn wrote:
> > Kai-Uwe's experiments are with image data which is log encoded to
> > represent a density range of up to (typically) 2.048. This is a common
> > representation for motion picture film images.
> >
> > Up until now, it seems that the film industry has been soundly ignoring
> > ICC CMS and has instead implemented many proprietary methods for
> > performing color adjustments on film images. This is in spite of the
> > fact that color adjustments (a.k.a "grading") are done for every film and
> > it plays a significant role in the production of each movie. The
> > necessary color adjustments may be different for a different reel of
> > film, different scene., etc.
> >
> > Accurately preserving/presenting "above white" information is quite
> > important to the film people since film itself is able to support it and
> > people can see the difference.
>
> My impression is that the ICC profile format has been optimized for
> rendered (e.g. output reference) spaces. I suspect that trying to create
> a general profile (e.g. using a Lut based representation) of a high
> dynamic range space, with sufficient detail to be useful,
> would be very challenging. On the other hand, a strictly additive HDR
> space should be reasonably well be handled by a matrix and a set of curves.
The problem with curves is the limited range of values. For instance the
above Cineon format represents up to 1024 levels. For 0 -> 255 (usual
8-bit convention) a custom curve is ok. Anyway the curve fails to describe
the remainder from 256->1023 . Te curve is dumb clipped now. The matrix
profile I wrote can include primaries, the white point but a one number
gamma is not sufficient. Not shure if parametric curves are allowed (I
read sometime ago about?) and if it is sufficient for cineon's log
encoding.
CLUTs are my next try.
> I also get the impression that HDR mapping (or rendering, which would
> obviously include artistic and practical input such as white point
> matching ("color grading") etc.) hasn't been as much studied in the context
I think some propriarity tools have overcome the output depending white
point paradigm.
The anchor for colour temperature is agreeable the blackpoint.
But why put the grip allways at the end of the staff?
> of device independent color spaces, as it has from a device dependent
> (ie. RGB) spaces. This isn't much of a surprise since the main impetus
> seems to be from the computer graphics side, rather than the color science
> side.
>
> So a practical HDR profile may well fit within the current ICC profile format,
> while a standardized HDR mapping mechanism (or framework) to work with it,
> doesn't seem to be readily available at the moment.
Tiger with its GPU/OpenGL based rendering is not using floats?
> An enhanced "rendered" PCS would be interesting (e.g. a PCS allowing
> a compressed highlight representation), as would matching device
> colorspaces, both allowing higher fidelity image transition for
> purposes such as theatre projection, or perhaps a 2 stage HDR rendering
> scheme.
> (the first stage being the major, artistic driven one, the second,
> minor one being for highlights to be rendered to a particular output
> medium.)
Do you mean an LDR/HDR distinguishing?
> An alternative (which may be cleaner, in separating the profile from the
> image representation), would be a device independent space annotation scheme.
> If raw HDR image data is stored in a device independent colorspace,
> then annotation including white and black points, gamut extent, rendering
> curve (+ possibly other effects) would allow a downstream rendering
> into a specific device space to be guided as to what artistic result
> to aim for.
That would be a fine goal. Tonemapping comes in the game anyway and is
currently not yet considered with the ICC spec.
As CS2 is not the only app handling HDR, there is no one man game
possible.
regards
Kai-Uwe Behrmann
+ development for color management
+ imaging / panoramas
+ email: [EMAIL PROTECTED]
+ http://www.behrmann.name
-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user
