Lossy Gamut conversions

Hello hello smart people,

So when I am doing conversion between gamuts, like AlexaWideGamut to AcesCG, I am loosing information and ending up with negative values(not that bad… but they are there) even when I write out the files as AP0. (more in 16 , less in 32b).

I find that usually inside a certain program like nuke this is lossless but when I write it out (to lets say precomp e.t.c) I am introducing a slight error which I dont think I want.

So one Idea here would be to, instead of saving files as AP0, save them in the Camera Gamut instead, this seems to work much better, as AWG is larger than AP0.

So my question, why whould I ever not render out my files with the largest source Gamut and instead use AP0?

AWG is not larger than AP0. There are a few “colours” which are all positive values in AWG, but have a negative component in AP0, because they are outside the spectral locus. But these are not “lost” in AP0, as EXRs preserve negative values.

Yes but I am getting a conversion error when I go from AWG to AP0, that I am not getting when I write out the file as AWG, or at least not as large of a error.

Whats the benefit of storing files as AP0 instead of AWG?

But yes you are of course right, AWG isnt larger. I was thinking of redwidegamut when I said it was ‘larger’ .

Storing as AP0 is not “better”. It’s just that it is the standard ACES approach, and what ACES is fundamentally about is defining standards, so everybody know where they are. But if you are in control of your own pipeline, and communicate clearly with all involved, there is nothing to stop you writing linear AWG to EXR files. Many facilities write ACEScg to EXRs internally, even though it is technically non-standard.

The conversion from AWG to AP0 is a simple 3x3 matrix, which is completely invertible. But half-float EXRs lose some granularity compared to the internal 32 or 64 bit processing in an app, so it’s possible you could see rounding errors in a round-trip to disk. But they should be very small. Are you seeing errors which actually produce visible artefacts?

Thx Nick, thats what I thought. I am not seeign any visible artifacts, I am testing the ‘limits’ of ACES so I am specifically looking for those small/tiny errors so that in case something goes ‘crazy’ in a future project I know where the error originated if that makes any sense.

I think that the standard of writing out as ap0 is a bit flawed anyhow because if I render cg in acesCG, I am supposed to have a post processing that turns everything to AP0 before its written to disk, or what? I am more of a fan of clearly labeling colorspace in the filename. Also if I share the Linear/AWG with external people and they dont run ACES, for them its just a regular ‘linear alexa’ file, like they are used to.

Anyhow, thank you Nick for your awesome and quick answeres, my question got answered and I think saving files as AWG does in fact makes sense for some projects , like those that have a custom LUT based on LogC/AWG, so I am saving a gamut conversion step for some programs, as I just have to do a gamma change from Linear to LogC and not have to do AP0 to AWG also.

Furthermore, having to switch the project mid project from aces to ‘legacy’ ,which ive seen happen before because… clients… would mean I have to re render all my plates, I dont have to do that when the plates are Linear/AWG allready .

(note I am using AWG as a placeholder for camera native gamut, I very rarely have to deal with different cameras in the same show.)