Re: [Openexr-devel] Introduction and CTL/ICC question

[Joseph Goldstone]

On Mar 10, 2005, at 11:35 AM, Kai-Uwe Behrmann wrote:

> Am 10.03.05, 09:32 -0800 schrieb Florian Kainz:
>
> > Kai-Uwe Behrmann wrote:
> > > > In addition, CTL programs can be parameterized; a single
> > > > CTL program can represent a whole family of transforms.
> > > > This is useful for image sequences where the value of a
> > > > parameter may vary over time.  Parameterized transforms
> > > > may also be useful for programs like image viewers where
> > > > the user has control over settings like exposure or the
> > > > amount of dynamic range compression.
> > >
> > >
> > > Can this parameterized form be the base for ICC data exchange?
> >
> > I am not sure what this means.
>
> Following Drew Hess mentioning:
> > (except to say that there is a lot of work going on right now to
> > figure out how to make ICC profiles work in a "digital cinema" world)
> .. I asked if parameterized transforms will be the way within OpenEXR 
> for
> exchanging device characteristics.
>
> Parameterized form makes me thinking about stuctures, logical
> fillable by ICC profile structures and vice versa, Such as describing
> colour primaries, matrices , gamma values, or using parametric curves 
> as
> described by section 6.5.14 of the ICC spec ...

The parametric curves in the ICC spec (cf. §10.15 of the 4.2 spec - 
there was a bunch of section renumbering that happened as part of the 
changes to make the spec conform to ISO norms) were almost all put 
there to express curves required by particular standards: CIE 122-1966, 
IEC 61966-3, IEC 61966-2.1 [a.k.a. sRGB].

There was a fair bit of discussion during the Digital Motion Picture 
Working Group session at the last ICC meeting in Orlando on this topic. 
 Here's what I remember, and any if other ICC members who were there 
want to correct or flesh this out, that would be great:

(a) The parametric curve semantics are indicated by a 16-bit field, 
allowing 65536 different meanings of the subsequent parameters; but 
anything that requires ISO approval for a new set of parameters is 
unworkable for innovation in interchange.

(b) If the reason people wanted a parametric curve was because they 
needed to express a set of values which 'fell between the cracks' of a 
fixed-point encoding, we (that is, the ICC) should try adding a 'half' 
data type and seeing if that fulfilled the needs of the community.

To aid in exploring (b), the author of the SampleICC package said he 
would try and add such a thing to the reference implementation.  I know 
he's in the process of doing so.  If you want to experiment with what 
he's got -- it's now a completely conformant ICC v4.2 implementation -- 
send me mail off this list, and I'll put you in touch with him.

Were you serious about wanting a parameterized form for color 
primaries, matrices and gamma values, or was that rhetorical, with the 
real weight of your request concerning tone reproduction curves and the 
shaper LUTs expressed as a component of the lut16Type, lut8Type, 
lutAtoBType and lutBtoAType encodings?

[I will try and catch up with the rest of this thread but this is a 
very overloaded week for me.]

--joseph goldstone
Lilliputian Pictures
vice-chair, ICC Digital Motion Picture WG


> regards
> Kai-Uwe Behrmann
>                                 + development for color management
>                                 + imaging / panoramas
>                                 + email: address@hidden
>                                 + http://www.behrmann.name
>
>
>
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/openexr-devel