ACES...

[Brendan Bolles]

However, what most call the "Cineon" format today is actually DPX 2.0. And there is simply no reference between a specific code value inside and an output color. All you do is you build a pipeline around the format and make your own definition which code value means which color in your environment. That doesn't mean it will look like that on someone else pipeline. One of the reasons why so may play with LUTs that bend the code values to some more specific output device color spaces - which in the end is not far away from a "handmade ACES workflow" - guess you got the point.

Actually, DPX does allow for that information. It lets you specify the "transfer characteristic", which is Log, Linear, SMPTE, etc. It also lets you specify black and white code values and what their floating point output values should be.

Only problem is that no program I know of embeds or reads this information.

 

[Axel Mertes]

Gunleik, I agree, but its not that easy when you look deeper into it - isn't it?

To me there are three goals that are interesting:

1. Try to calibrate transforms for any input device, so that a real world color can be derived and stored in a color space with a gamut large enough to keep at least all visible colors.

If that works, you can match different sources easier and once you have created a "look" you can apply the look to any of these source (after they are transformed into real world colors) and the results should look similar. However, dynamic range is the big thing you will fight with, but that a) getting better and better and b) a real world problem that can not be solved other than improving devices (see a)).

2. A standardised color space and frame buffer format (not necessarily file format) to work in.

The big question here is how the bits are actually being used. Will you store the original captured bit data and just have a transform function that converts those code values "on the fly" into the target real world color space?
If yes, the next question is how does that real world color space work? Is it linear? Is it log? If log, which log? Or should there be both?
I would think that linear is a good approach, because any other log function can be compiled into a function that produces the linear result, so you will essentially concatenate the two functions to get into your workflows working color space then.
Obviously you need to store either the inverse transform to remain with saved results after processing that match the input code values, or you may decide to store in a different color space (e.g. the real world color space) by applying a different conversion function again. However, how are the bits saved in that color space? Linear? Log? If log, which log? Again, you need to accompany your saved data with a required transform to get it into e.g. a linear float16 space.

3. As the output gamut of different devices is different, the question remains if we find output transforms that may get standardised to get something matching.

This is where the discussion will start if that is an artistic thing or if there is really a "solution" most poeple will agree on. The idea is to have e.g. the P3 gamut in the cinema match "feeling wise" a different output transform that tries to resemble the visual experience in the smaller REC709 gamut of an HD screen. You definetly can't convert real world matching colors on those devices, because you may/will experience the gamut clipping in the side by side comparison. Where you see fine gradation in P3, you might clip into pure black in REC709. So to resemble the visual experience you need to change your transform to REC709 to have kind of s-style slope curves to create a visually close inpression, but measured color will be different, guaranteed. If we could aggree on output transform doing this, creating masters for different gamuts would become much easier. There are scientists working on this - the questions is namely "will the colorists, DoPs and directors aggree with the results?" and how much of it is a matter of taste...


The biggest problem IMHO is that poeple do not agree on if the bits stored are linear or log, or if the working color space is lin or log. Some say so, some say so. Given the amount of a float color space and the real world reproduceable color spaces, the question remains if it makes a difference at all.

Clearly, if data is linear internally and you want to apply a log style grading, you need to preconvert to log space before processing and back again. Thats two more steps for every function performed. So I see why people want to bypass this by getting into something true log.

Its also a question if actually captured data should be transformed directly into this target real world color space code values (so the input transform for that data is a 1:1 function in later processing) or if you want to store the devices native bits. For closed systems like RED this is not really thinkable to work.

 

[Axel Mertes]

:boxing_smiley::boxing_smiley::boxing_smiley:

Actually, DPX does allow for that information. It lets you specify the "transfer characteristic", which is Log, Linear, SMPTE, etc. It also lets you specify black and white code values and what their floating point output values should be.

Only problem is that no program I know of embeds or reads this information.

Yep, thats the problem.

Thats one of the reasons we have not yet implemented DPX format for our FinalDCP software, because WE have to maintain functions to allow poeple how to deal with the input DPX data to get the right results. I get often asked "Why don't you support DPX, its the only standart color space?" and in fact that is exactly NOT true. To me DPX is just a container. And as you correctly pointed out, if the definition of what is store in the DPX is missing as apps don't support it or users don't care and try compensating the problem by applying LUTs and LUTs and LUTs, the information inside the DPX is basically "unknown color space".

So back to FinalDCP in that context means we would need to convert from an unknown color space to a known color space. The transfer function is missing. Coming from a well defined REC709 or P3 source is far easier to maintain.

However, DPX is on our roadmap, but it require us to provide some options to adjust the transfer funtion to work for everyone. I always get the request for LUTs, which are ONLY necessary because of that missing color space defintiions... Its kind of everyone knows it better thingy...:boxing_smiley:

 

[Nick Shaw]

Only problem is that no program I know of embeds or reads this information.

Nuke reads and writes the transfer function meta-data in DPX files.

It does not however seem to read or write black/white point meta-data, which is crucial. Knowing whether, for example, Rec709 image data is "full range" (0-1023) or "SMPTE range" (64-940) is vital to correct interpretation, and all applications I know of rely on the user to specify this.

 

[Brendan Bolles]

Nuke reads and writes the transfer function meta-data in DPX files.

Just did a test, and you're right!

If you set the color space to Cineon in the write node, it's flagged as "Printing density." Rec.709 or sRGB are flagged as "Linear." And Nuke's Linear is flagged as "User defined." When you read the file back in, "Default" color space uses the flag. I guess I never had a program that set those flags, so I never saw Nuke use them.

After Effects appears to always output as "User defined." It does have log conversion controls on input and output, but I think people would freak out if those started getting set for them.

 

[Gavin Greenwalt]

Just did a test, and you're right!

If you set the color space to Cineon in the write node, it's flagged as "Printing density." Rec.709 or sRGB are flagged as "Linear." And Nuke's Linear is flagged as "User defined." When you read the file back in, "Default" color space uses the flag. I guess I never had a program that set those flags, so I never saw Nuke use them.

After Effects appears to always output as "User defined." It does have log conversion controls on input and output, but I think people would freak out if those started getting set for them.

Problem is that Nuke expects different tags in the meta data than every other telecine or editor (who all seem to choose their own standard) the result is that I've never actually had a DPX that wasn't just read in as "Cineon (default)"

 

[Nick Shaw]

Problem is that Nuke expects different tags in the meta data than every other telecine or editor (who all seem to choose their own standard) the result is that I've never actually had a DPX that wasn't just read in as "Cineon (default)"

Absolutely. I was only commenting that Nuke reads and writes those tags, not claiming that "all is well with the world" because it did. Tags that are inconsistently used, or frequently not used at all are really worse than no tags at all. That same issue is at the heart of QuickTime gamma and colour space issues. At least pretty much all applications which read DPX allow the user to manually set the interpretation of the file. The same can't be said for QuickTime.

 

[Gavin Greenwalt]

Yeah, EXR gets gamma right but ILM's insistence that the container format be as generic as possible has created similar problems with naming conventions for standard layer names like "z-depth" vs "depth" vs "zdepth" vs... ugh. Sometimes flexibility isn't a good thing. Or at least good defaults should be standardized. I don't understand why the industry has such a hard time with such simple problems.

 

[Blair S. Paulsen]

Let's all agree that until ACES is considered "settled", most creators of post tools are unlikely to put ACES and OpenEXR tool development high on the priority list.

So, ACES/IIF needs to get pinned down first. Then the usual suspects can integrate ACES compliant toolsets.

A nominal, neutral RRT as a base set of values seems like a key piece - even if the RRT becomes the playground for further refinement/special sauce/etc.

BTW, in theory at least, the ODT math should allow for predictable color space transforms after the reference values have been chosen in the ACES benchmark. Just as being able to match various source material in a consistent way is part of the promise of ACES/IIF so it the concept that one need to create only one master that will be displayed as close to intent as the device can manage.

Cheers - #19