hi there,
just wanna share an issue we faced importing arrimxf,
maybe someone can give me an input.
we had a footage from arri alexa 35.
LogC4 - Alexa Wide Gamut 4. we are running flame 2023.2, so we were ready for LogC4
Instead of ARRIRAW, we recieved ARRIMXF.
we imported, conformed, worked the vfx, and send back to grading (resolve) in LogC4. so far so good.
now…
opening our final renders in resolve dont match with original plates from camera. color wise.
opening our final renders in flame again and they match perfectly with the plate from camera.
after some back and forth…
we realized… when select ARRIMXF in Format Specific options… there is no access to Image menu.
only Metadata menu.
but if you select MXF for instance… Image menu will show up… and you can activate
Include YUV headroom, witch is recomended when import files from camera.
we understand mxf and arrimxf are not the same, but it looks like flame is not interpreting correctly the arrimxf range file.
anybody else had these issue before?
any workaround?
our workaround… create a lut to compasate the range that flame is importing from the file, and make it match with plates in resolve.
let me know if you have any input.
thank you gang.
If it is definitely the RAW, then we’d also need to know how you are delivering to grade (dpx in native colour space, LogC4 to ACES exrs, or whatever) as well as what colourspace the grade is being done in and are they needing to apply an IDT to get it into the correct colourspace.
hi Adam,
yes I know what you mean.
but in this case it was not Arri Raw,
just MXF container, with Apple ProRes 4444 XQ compresion on it.
witch is tag in flame as ARRIMXF.
In case of RAW format been selected,
you will have access to debayering, image, color, metadata menu…
but once you select those files, they get recornized as ARRIMXF,
an no menu is availble.
once you import the file, and export back, in exr LogC4 for instance… that will not match with orginal plates in ARRIMXF native from camera in Resolve… for example.
Hey @saul
This is not ideal. Are we saying that when importing ARRIMXF we should have the full YUV headroom but Flame is grabbing legal (video)?
I am getting PTSD from a job where the client wanted all Resolve exports to be Full not Legal (video) range because they were convinced this would give them a greater dynamic range. I got my knickers in such a twist going back and fourth, getting it wrong and the grade on the Flame going too bright and all
Anyway. Maybe you could change the Data Levels on your Flame files in Resolve Use clip attributes.
In the past I found using the invert of the legal to full range LUT would get the same result as selecting include YUV headroom. I’m not in front of the box right now so I don’t recall which section that transform is located, sorry. That said, it wasn’t on LogC4 footage but it’s worth a shot.
What is the grading facility working with and in what colourspace? If they are working in ACES or a colour managed system such as Resolve Colour Managed, are they definitely applying the correct LogC4 IDT? In other words, is it them and not you? Are they incorrectly tagging it as LogC3 for example?
Since the ProRes4444XQ has come from the ARRI itself, are you sure it should be in full range? I’ve only ever experienced it as being legal range. Not saying that this is the case in your scenario but I am surprised you need YUV headroom enabled. Is this what the colour facility has suggested?
I also would like to add that exr is not a good format to send log colourspace in unless you are sending 32bit exr files as rounding will cause some data loss. Minimal but still there.
finally solved.
thank you very much for your help on this topic.
after checking as @PlaceYourBetts suggested,
the colorist was not clicking in full range in Data Levels, Clip Attributes.
thank you Richard!
so final approach was.
import ARRIMXF LogC4 in flame (no options about levels)
work on vfx (ACEScg in our pipe)
export to color QT apr 4444xq LogC4 (full range)
import in resolve the QT, clip atributes data leveles Full (instead auto or video)
@AdamArcher the colorist was working on Rec709 color space…
but I think colorspace in resolve and LogC4 IDT was irrelevant at this stage… we were able to spot the difefrence just importing plate and comp and comparing both with no tranformation.
I thought 16bit halffloat exr was container enough for log formats… considering most of Log colorspaces are coming in 12bits. Do I missing something?
I have read the reasoning many times and this is the best I have come across explaining it in layman’s terms:
“I’d avoid using 1half-float (16 bit float) for anything not scene linear. You can think of the float working as an inherent log encoding. Normally with data not scene linear you use the range from zero to one. And for the value range of 0.5 to 1.0 you basically have only 1024 values. This makes the encoding comparable to 11 bit integer coding for this range. So if your data is more than 11 bits you’re better off using something 12 bit or more. Or convert to scene linear and then transfer the data as scene linear into Resolve.”
No longer quoting now, the rest is me.
If you have looked at post production specifications from any major studio or streamer that cover workflows, such as Netflix, Amazon Studios or Disney, they will actually even specify that if you are working in log you must use minimum 12bit dpx files and for linear colour spaces you must use minimum 16bit half float exr files.
One example as per below where if you look at section 5.2.1
“LOG EXRs will not be accepted”
16-bit EXR (.exr) if color pipeline is ACES, or if the pull color pipeline is set to a Camera Linear color space (such as Linear AWG / Alexa Wide Gamut).
Given acesCC and CT are inherently log it does go against itself. I suspect that they are concerned about precision errors on non aces cam colorspaces in half which is why they are asking for 16bit int for those non-aces pipelines.
Wouldn’t be the first spec sheet to make things clear as mud…
This is one of the reasons it is unfortunate that the Cineform RGB 16bit lossless codec is not supported in Flame. It is the best format I have come across if you want to work in log. Another option would be lossless JPEG2000 but that is much more taxing on the system for decompression.
@AdamArcher thank for this info.
very interesting! And it makes totally sence.
so as conclusion.
any Log should go in DPX, 10b or 16b depending the needs.
EXR is only for Linear colorspaces as ACES op0, ACEScg, Linear AlexaWideGamut, etc…
So, in case of a color grading session in ACEScc or ACEScct,
we have to tranfer files in EXR ACESap0,
tranform to ACEScc or cct, grade
and render tranforming back in ACESap0,
with no posibility of intermediate render?
because a intermediate render will require exr 16bit.half (needed for ACES) but being in log as cc or cct may not work well.
Once again, for an ACES colour pipeline that goes to spec, the only acceptable transport format is ACES 2065-1 (which is ACES AP0 gamut with linear gamma, not log) in minimum 16bit half float codec, essentially exr. I have never heard of anyone sending out ACEScc files as exrs and once again this would be not to spec
I don’t have the time or effort to explain further, but even though something is tagged as LOG, what is actually going on under the hood is working on linear media.
Use clip attributes.
