Date   

Re: Review: AllocationTransform

Jeremy Selan <jeremy...@...>
 

No objections? Rolling it in...


Re: Review: Bugfix for Nuke LogConvert

Jeremy Selan <jeremy...@...>
 

No one objected, so I've merged this in.


Re: Review: Inital pass at searchpath impl

Malcolm Humphreys <malcolmh...@...>
 

How about we shoot for tomorrow, I'm still getting backup to speed with things.

.malcolm

On 07 Dec, 2010,at 09:08 AM, Jeremy Selan <jere...@...> wrote:

What's your schedule like this week? Up for a conference call? I'd
like to primarily discuss the env-vars / 'globals' / per-shot cc look
options.

-- Jeremy


Review: Added 'pure' LogTransform

Jeremy Selan <jeremy...@...>
 

As a pseudo-replacement for the CineonLogTransform, added
LogTransform. This is the pure mathematical Log operator, with a user
configurable base.

Commits:
7f7ad979

-- Jeremy


Re: Review: Inital pass at searchpath impl

Malcolm Humphreys <malcolmh...@...>
 

* I like supporting only strings for now. In the future, I can also
see numbers being supported (such as allowing for CDL blocks that rely
on envvars), but this can be added as needed.
It would also be super nice if the CDLTransform supported the full Color Correction Collection (CCC) in the CDL spec, where you could have something along the lines of '!<CDLTransform> { src: '/path/to/basegrades.ccc', id: '${SEQ}_${SHOT}_balance' }'.
* The FileTransform will probably have to get a bit smarter. Say
you're using a pershot lut, and for some shots you dont want any such
table. This could be solved by either not installing a lut in the
expected location, or by installing an identity lut. Which is
preferable? In the current implementation, if a lut is not found
this is always an error condition. Maybe we should introduce on the
FilmTransform a 'silent error mode', where this would just skip the
application of that specific LUT?
Keep the system simple let it error, it should be up to the user to setup the searchpath so that an identity lut is found if other paths fail to resolve to a lut.

It might be an idea to make this case not an exception, but a error which gets sent through some kind or error handler.

* The "globals" pre-declaration could also define an optional default
(used if the envvar is not set). If the envvar is not set, and no
default is specified, any references to the global variable would
probably be an error.
+1

.malcolm


Re: Review: Inital pass at searchpath impl

Jeremy Selan <jeremy...@...>
 

What's your schedule like this week? Up for a conference call? I'd
like to primarily discuss the env-vars / 'globals' / per-shot cc look
options.

-- Jeremy


Re: Review: Inital pass at searchpath impl

Jeremy Selan <jeremy...@...>
 

Next week will be fantastic. Welcome back.
-- Jeremy

On Fri, Dec 3, 2010 at 8:05 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
Hi Jeremy,
On 04/11/2010, at 3:32 PM, Malcolm Humphreys wrote:

I'm going to be out of town for the remainder of the week, perhaps we
could try an internet call early next week to discuss these specifics
further? (Skype, iChat, etc). Many of these points can probably be
hashed out easier live, and then we can summarize our thoughts back to
the list.


It might have to wait a few weeks, I'm in Hong Kong right now and I'm going
to be MIA in asia for a bit.

But yes a chat would be good when we are both free.

Just letting you know I'm back from Holidays now, I'll try and go back
through
and review what I have missed.
And we should line up a chat maybe next week if you are around.
.malcolm


Re: Review: Inital pass at searchpath impl

Malcolm Humphreys <malcolmh...@...>
 

Hi Jeremy,

On 04/11/2010, at 3:32 PM, Malcolm Humphreys wrote:
I'm going to be out of town for the remainder of the week, perhaps we
could try an internet call early next week to discuss these specifics
further? (Skype, iChat, etc). Many of these points can probably be
hashed out easier live, and then we can summarize our thoughts back to
the list.
 
It might have to wait a few weeks, I'm in Hong Kong right now and I'm going to be MIA in asia for a bit.

But yes a chat would be good when we are both free.

Just letting you know I'm back from Holidays now, I'll try and go back through
and review what I have missed.

And we should line up a chat maybe next week if you are around.

.malcolm



Review: Bugfix for Nuke LogConvert

Jeremy Selan <jeremy...@...>
 

Nuke's OCIOLogConvert node was being applied in the wrong direction.
(What was listed as log->lin was actually the opposite).

Commits:
b5bd0c824

Issue:
http://github.com/imageworks/OpenColorIO/issues#issue/9

-- Jeremy


Review: Removed CineonLogToLin Transform

Jeremy Selan <jeremy...@...>
 

CineonLogToLin was always occupying a sort of transform netherworld.
It's too specific to count as 'general math', but not specific enough
to be useful in many practical cases for linearizing film data. This
transform was a late addition to OCIO (it did not appear in Sony's in
house predecessor), and upon further consideration is not worth
keeping.

For those interested in doing this conversion in the future, we would
recommend using a 1D LUT, or using the log allocation transform. An
example of the 1D lut approach is demonstrated in the spi-vfx profile,
and an example of the Allocation approach is in the iif profile.

Issue:
http://github.com/imageworks/OpenColorIO/issues#issue/12

Commits:
11c19f7bf26298dd95bf63a9ba59dc63ebf7a093

-- Jeremy


Review: AllocationTransform

Jeremy Selan <jeremy...@...>
 

These add a new transform type, AllocationTransform, which is useful
in mapping HDR color ranges into LDR code spaces. Two options are
supported: a uniform allocation, and a log-2 allocation, and the
specific math corresponds to the gpu allocation options already used
internally. This transform is useful for applying LUTs to HDR
imagery (for example in the upcoming IIF profile).

Commits:
105dba932d32970d4cbb6d4fee77be99a18334a5
4b50d7b222538f637abd11fb03616e60ee2c73ab

Issue:
https://github.com/imageworks/OpenColorIO/issues#issue/11

-- Jeremy


Re: Review: removed TODO

Jeremy Selan <jeremy...@...>
 

Merging this into trunk, no objections.
-- Jeremy


Coming soon: Initial IIF support

Jeremy Selan <jeremy...@...>
 

For those not familiar with the IIF project, the Academy is
sponsoring a project to standardize a single floating-point linear
workflow across the motion picture industry:

http://www.oscars.org/science-technology/council/projects/iif.html

One of the core developer, Alex Forsythe, was kind enough to sit down
with me and spec out what an OCIO implementation of the IIF workflow
would look like. It was a great learning experience (trying to port
a non-sony workflow to OpenColorIO), and we learned a lot about making
OCIO easier to use. Expect to see a bunch of improvements in the next
few weeks related to LUT generation, allocation, baking, import,
export, etc.

Also, hopefully in the next week or two we'll also put out a first
'prototype' IIF / ACES OpenColorIO configuration. This will allow
anyone with an existing OCIO setup to test the IIF workflow. (which is
the whole promise of this project)!

(Note that in the near term, the OCIO profile will not execute the CTL
(Color transformation language) directly, but instead will rely on a
manual port of the existing transformation logic.)

-- Jeremy


Review: removed TODO

Jeremy Selan <jeremy...@...>
 

I've removed the TODO file internal to the codebase, in favor of the
github issue tracking. (Which is really nice!)

Please feel free to add any issues (bugs or features) to this list as
you encounter them. Thanks!

https://github.com/imageworks/OpenColorIO/issues

commit:
8cf3d4a18

-- Jeremy


Re: Review: API Change to ColorSpace.GPUAllocation

Jeremy Selan <jeremy...@...>
 

No one has objected, so I'll roll this into the master branch.

-- Jeremy

On Nov 16, 11:43 am, Jeremy Selan <jeremy...@...> wrote:
This updates the API for setting the ColorSpace GPU allocation hint.
(The allocation is used to determine how a particular lattice is best
sampled using a fixed domain lut on the GPU).  Previously all
allocations were configured with 2 fixed arguments (min, max):

Prior:
Uniform:    x mapped from  [min, max] to [0,1]
Log2         log2(x) mapped from [min, max] to [0,1]

Now, allocations can be configured with a variable number of
arguments. (The definition of which is allocation specific).  This is
useful as it allows for (optionally) more sophisticated allocations on
the GPU.   The first allocation to take advantage of this is "LG2",
which adds a linear offset value as the 3rd variable:

Log2         log2(x+offset) mapped from [min, max] to [0,1]

Using a small, positive offset allows a log allocation to represent
the value 0.0 precisely, which is useful in some configurations.

This update also names GpuAllocation -> Allocation, as what it
represents is not GPU specific. (GPU is the use case, rather than the
description of what the data is).

Commits:
3f12fca8bf0aff910a4989b855d711ab609b61f9
e780e5d21333aca75de25403dd56852da17a7517
d17a6530982b86b5ef51601aae97a76e1c2da59d

-- Jeremy


Review: API Change to ColorSpace.GPUAllocation

Jeremy Selan <jeremy...@...>
 

This updates the API for setting the ColorSpace GPU allocation hint.
(The allocation is used to determine how a particular lattice is best
sampled using a fixed domain lut on the GPU). Previously all
allocations were configured with 2 fixed arguments (min, max):

Prior:
Uniform: x mapped from [min, max] to [0,1]
Log2 log2(x) mapped from [min, max] to [0,1]

Now, allocations can be configured with a variable number of
arguments. (The definition of which is allocation specific). This is
useful as it allows for (optionally) more sophisticated allocations on
the GPU. The first allocation to take advantage of this is "LG2",
which adds a linear offset value as the 3rd variable:

Log2 log2(x+offset) mapped from [min, max] to [0,1]

Using a small, positive offset allows a log allocation to represent
the value 0.0 precisely, which is useful in some configurations.

This update also names GpuAllocation -> Allocation, as what it
represents is not GPU specific. (GPU is the use case, rather than the
description of what the data is).

Commits:
3f12fca8bf0aff910a4989b855d711ab609b61f9
e780e5d21333aca75de25403dd56852da17a7517
d17a6530982b86b5ef51601aae97a76e1c2da59d

-- Jeremy


OCIO 0.7.1 released

Jeremy Selan <jeremy...@...>
 

Version 0.7.1 (Nov 15 2010):
* Additional 3d lut formats: Truelight .cub + Iridas .cube
* FileTransform supports envvars and search paths
* Added Nuke plugins: LogConvert + FileTransform
* Improved OCIO profile formatting
* GCC visibility used (when available) to hide private symbols
* A few bug fixes


-- Jeremy


Re: Review: FileTransform will try all lut formats (if the initial read fails)

Jeremy Selan <jeremy...@...>
 

In the absence of any objections, I will check this into master.

-- Jeremy


Review: FileTransform will try all lut formats (if the initial read fails)

Jeremy Selan <jeremy...@...>
 

FileTransform will attempt to load the specified lut formats, if the
initial read fails. I also had to make some of the 3D lut loaders use
stricter parsing as they now get called (in error conditions) and
giving false positives. (I.e., an invalid .cube lut was errantly
being loaded by the .spi3d / .3dl loaders).

commits:
b6aef8748d6cd017e2dcf8e8d2baf8e9334eaa6e
91515b537187a8aa04cd389ea5036af65e0feb72
18bbb2734a67e442bb67b64f5f2b902ce578484b

-- Jeremy


Re: Review: Lut1D optimization

Jeremy Selan <jeremy...@...>
 

That's fair to add it as an option. I'll add it as an official TODO,
and will implement it once we have a few more examples of this type.

I'm not sure if this will be a transform specific option, or a
configuration level setting. (I could forsee if this comes up often
to have an optimization-level hint globally, which other blocks would
obey as well). I think if we're going to allow for customized
optimization levels, having one big switch that controlled all similar
settings would be much simpler to understand.

-- Jeremy

On Thu, Nov 11, 2010 at 3:25 PM, Rod Bogart <bog...@...> wrote:
I guess my preference would be to allow someone to ask for
optimization or not.  In the glorious future when OCIO is involved in
the creation of every pixel in every movie, the animated CTL example
may be rather common, and an option to avoid clever internal
heuristics might be a good debugging and processing tool.

RGB

On Wed, Nov 10, 2010 at 4:15 PM, Jeremy Selan <jeremy...@...> wrote:
Man, I can't get anything past you guys!   :)

The clamp was omitted on purpose, but I could probably be convinced
either way on this issue.*

If this code were inside a compiler, there would be no discussion -
clamp would be the only correct answer.

But ... in the context of writing a color processing library I would
propose that we have a bit of leeway here.  I tend to have a strong
distaste for proactively clamping outputs. Why destroy data if you
don't need to?  Who is to say that the extra data (previously
scheduled to be clamped) couldn't prove useful further down the
pipeline in certain circumstances?   Clamping is easy to add
downstream if/when needed.  I.e., if a subsequent image processing
operation depends on a clamped input in order to produce sensible
results, it can can always do it at that time.  And if it's not
needed, even better!

Our implementation of ASC CDL SOP already does this.

// out = clamp( (in * slope) + offset ) ^ power
// Note: the clamping portion of the CDL is only applied if
// a non-identity power is specified.

The same rationale applies.   The CDL transformation math strictly
requires a clamp between [0,1], making it useless on HDR data.
However, in practice many portions of the math (gain, sat) work great
on HDR data so it seems unnecessary to always clamp the output.  We
thus only clamp if the exponent potion is specified, which was the
intent as specified in the CDL docs).


The downside of this approach (in both the lut1d case, and the cdl
case) is that if someone ends up relying on either of these behaviors,
they are in a semi-precarious position.  I.e., their configuration is
sitting with magic numbers at certain values that happen to not
introduce this clamping, and this behavior will probably be
discontinuous (unintuitive?) over the parameter space.   Picture an
animating CDL exponent, where it goes from [0.95, 1.05].  For some
portion of the range there will be clamping, then no clamping, then
clamping again.

I agree this is not ideal, and that a sensible individual may prefer
the alternative, but this downside is a price I'm inclined to pay for
the benefit of preserving data in the commoner cases.

-- Jeremy


*(Technically the clamped range is not 0,1 but instead
[lut1d.from_min, lut1d.from_max] but this is inconsequential to the
overall point).


On Wed, Nov 10, 2010 at 3:14 PM, Rod Bogart <bog...@...> wrote:
Is this semantically correct if the presence of the 1D lut also
triggers clipping to 0-1?  Is there now a missing clamp?

RGB

On Wed, Nov 10, 2010 at 1:56 PM, Jeremy Selan <jeremy...@...> wrote:
On Lut loading, 1D luts are checked to determine if the underlying
transform represents 'identity'.  If so, they are skipped during op
generation.  This is particularly useful when working with 3D luts
that have shaper luts, which are often left as identity.

This check is added to the lut1d-finalize call, which takes a
'tolerance' as an arg as the underlying file quantization is file
dependent.

Commits:
177bf402f6ff95ba70224aa4466e7773c5a89f96

-- Jeremy

1941 - 1960 of 2226