As per my original comment, data loss is minimal but still there.
I have actually seen the data loss when receiving a log file as an exr on a shot that looked overexposed. When pulling down the highlights in grade on the source compared to the comp, there was a noticeable difference in detail that could be “recovered” (not sure why colourists use this terminology as the data is there, you just can’t see it on a 10 or 12bit monitor). Once the same shot was resupplied as linear exr all the details was there again.
I would suggest 12bit log would be the minimum for most modern cameras.
If you grade in ACEScc or ACEScct you would either render out with an output transform into the required colourspace which would usually be a display referred colourspace such as Rec2020/St2084, P3D65/St2084 for HDR, P3-DCI/Gamma2.6 for theatrical, or Rec709 SDR (these are not the only options).
However, if you wanted to render your ACES grade out in ACES, you would render it out as an AP0/Linear file (aka ACES 2065-1) as 16bit half float exr files. This will contain the AP1 log working space of ACEScc & ACEScct. As I mentioned earlier, even when working in ACEScc, what is happening under the hood is actually on linearised media. One telling thing though is that when you output an ACES grade in Resolve when selecting “No output transform” what exports is ACES 2065-1.
I’m sure someone on here will say that they use ACEScg as a transport colourspace. This isn’t ideal either to be honest and I have seen issues with NAN (Not A Number) values doing this. Also, for those that use Alexa source, Alexa Wide Gamut is slightly larger than ACES AP1 so be aware that you could be creating NAN values.
→ Importing MXF prores from alexa35 gets imported as full range in flame with no option to change it?
or whats the conclusion of what happens here?
otherwise I can only +1 on the precision of log EXRs, biggest thing is float vs integer here, float is pretty crazy internally.
Try to so a simulation in houdini thats very very far from origin, it will collapse because the internal float (64bit?) is not precise enough when very fae from the center, as for floating point - the precision gets lower the higher the values are getting.
Just FYI because its related - most high end cameras have a 16bit linear integer analog->digital converter, arri has bumped this to 18bit now with the alexa35.
They said in the logC whitepaper that 12bit logC can represent all values of a 16bit linear capture.
Sony says they save 16bit linear directly without telling anyone why that would be better than 12b log.
I will disagree on the “AP0/2065-1” part because it “contains” ap1, I dont believe there is any technical reason to use 2065-1 - ever.
You can describe out of gamut colors just fine in any abritary container in floating point, 1/0/0 in acesCG is full acesCG red, what is 2/0/-1.5 then…
And if you have negative values in your original camera gamut for whatever reason you will also have them in 2065-1
Please call me out if thats BS I understand its a “standard”
The main reason to use AP0 over AP1 is for its translation to XY space and that it encompasses everything, all possible values. AP1 is more akin to Rec2020 which is still probably more than fine but AP0 is future proof.
I totally get your point and whilst technically you are correct, if there are standards for ACES then I think it is important to adhere to them in an ACES workflow. A big reason for me on a personal level is proven on the above thread where lots of people have been using exrs for log. You and I understand the issues but many don’t. I’m trying to avoid something similar in transporting things in ACEScg instead of ACES2065-1. I’m thinking that someone much smarter than me has a good reason why you shouldn’t transport ACES files in ACEScg. There are cameras with wider gamut than AP1 and I have heard of issues with software creating white & black pixels so I’d prefer to not experience them if possible (even though I have had black and white pixels due to other issues in ACES). Not saying this is the reason for ACES 2065-1 but they definitely define ACEScg as a working colour space and ACES 2065-1 as a transport & archival colour space and I’m guessing they hve good reasons for that.
So essentially, Im playing it safe by following what the ACES Central team recommends.
ARRI MXF ProRes are imported as Legal Range and there is no option to change that to Full Range, which is the right way to work with this content.
If after VFX back and forth with Grading you are provided ProRes QuickTime, then you have the option to import the content as Legal Range (default option) OR Full Range, based on what you have been provided since many 3rd party applications are capable of generating Full Range ProRes.
For me all my alexa35 and alexaLF MXF prores stuff imports as video range in every app I throw that in, resolve, flame, nuke… the prores from alexa was always video range for as long as I remember, full range prores is very sketchy as its a YUV codec.
Well, you would have a greater range of numbers for Full range material if you did choose to do it, but there are much better codecs to do that with so I wouldn’t recommend it.
I don’t think Dolby recommend it either. They just want you to monitor HDR in full range instead of legal range to give you more detail. There are certain distributors who have chosen full range QuickTime as a delivery format. It is valid in that choosing full range will retain more information (as there are more numbers to contain the same data) which would help when tone mapping HDR to SDR and since the colour space is display referred, there shouldn’t be any data sitting outside of this. There are much better formats to do this with though, such as the RGB 16bit JPEG2000 IMFs that Netflix use as an example.
I believe Amazon require ProRes4444 delivery for HDR, but I can’t remember if they request full range or legal.
BBC IMFs for HDR are ProRes based also, but once again, I am unsure whether they are legal or full range.
No idea what they mean with “Using full range source material”…
Dolby Laboratories has established the following guidelines for facilities entrusted with creating and delivering Dolby Vision content for distribution.
Dolby recommends:
Using full range source material
Working in full range throughout the content creation process
Delivering Dolby Vision content in full range
When the studio or client requests for legal/video range deliverables, it is recommended to create and master the content in full range and then derive the required legal range deliverables from these full range masters.
And that makes total sense to me. More data in full range vs legal range will create a better result for tone mapping to SDR.
If people down the line choose QuickTime for their delivery format, there is nothing technically wrong with that either, it’s just that there are better mediums for delivery of Full Range material. QuickTime should definitely be thought of though as a valid codec to do this with, as long as it is a 12bit 4444 or 4444XQ.
I understand its a “standard”
totally agree keeping standards is good.
