Jeremy Selan <jeremy...@...>
Malcolm - interesting idea!
I do agree that right now families feel a bit like a second-class
concept, and I would like them to be easier to deal with. I also
agree that it's appealing to present the user as short a list of colorspaces,
as much as possible, and not to burden them with bitdepth options if we
can avoid it.
(I'm not sure this relates to contexts.)
One side note: currently family names *are* used as an
optimization within the library, and it's assumed that all transformed
to/from colorspaces of the same family can be considered a no-op.
I.e., if you define an image as being in the 'lg10' space, and ask to
transform it to 'lgf', it will determine that both spaces are in the
same family and no work will be done. This is actually a nice
optimization for a lot of reasons related to internal performance.
So, Joseph, in the case of of the IIF's adx10 vs adx16, these would
currently need to be separate families anyways. (In the Academy Density
Encoding spec (ADX), the 10 and the 16 bit representation differ in
more than just precision, the 16-bit spec also encodes a greater
I'd like to consider this further, but the next big API extension I'm
looking at is the per-shot look / "Context" stuff. Let's bring it up
again when that is complete.. (i.e., in a few weeks)
On Thu, Dec 16, 2010 at 3:05 PM, Malcolm Humphreys
Hi did you guys have any more thoughts on this? Jeremy do you see this