Looks like the new iPhone will have the option to shoot in log. This would be very helpful for post-production! They mention supporting ACES so I guess they’ll provide the data for an IDT around the release.
It’s interesting to see the first phone (right?) to have true log encoding. Curious what the actual dynamic range is. Go Pro also has true log now with their latest Hero camera but haven’t seen a paper of that yet. Still great that these consumer devices are becoming more usable for post workflows.
Latest Resolve 18.6 update from today has “Apple Log” available in the CST and ACES transform OFX. I haven’t seen any PDFs, IDTs, or documentation published in public of the math yet, so I assume they were in talks behind the scenes to drop feature support this early. It appears to just be the OETF in the list, no mention of colorspace, presumably they’ll use Rec. 2020 primaries?
Perhaps. If it is available in the CST it should also list the primaries no? Unless they will say just use Rec.2020. But F-Gamut from fuji is also pretty much Rec.2020 and it’s still added as FGamut to the list.
It Looks like it is rec2020, in the Davinci CST it doesn’t have the option for the Apple color space ,just the LOG curve. But funny enough I think that the CST and ACES transform have a different Log Curve math, It’s a kind of weird curve tbh, regardless of which is the right one.
I had tonemapping disabled , I tested by creating a linear ramp .
CST linear to apple log
Aces transform apple log to acescg
This didn’t give me a no op even if it should, but technically I could have done it the other way around just in case , can’t check until later tomorrow.
I even tried with the fusion cineon log node that now also has apple log, and doesn’t have tonemapping option.
I never enable the OOTF but I can agree that some times RCM and the CST makes errors with the OOTF so it could be related like you said.
I haven’t had a chance re check but the test I did should be a no -op for a linear ramp regardless of the gamut , but I tried with a cube and there was a difference aswell, no ootf on , no gamut mapping.
I set the CST from acescct AP1 to rec2020 Apple log, then an ACES transform from Apple log to ACEScct and it wasn’t a no op, it was close in some places but in others it wasn’t.
No tone mapping, gamut mapping, no ootf .
It could be that Apple Log will have a log encoding plus an extra tone mapping and the CST only inverts the log part , while the ACES transform inverts both ? Idk , just speculating
I just tried it and I get a perfect match between CST and Acestransform with applelog in regards to eotf also it works going back and forth as you did as a no-op.
the gamut however seems to be different between the acestransform and CST suggesting that appleLog is not exactly rec2020? but its just very slightly different, like VERY slightly.
Great! Glad to be wrong that they are different, but curious about the rec2020 part, I saw it too but I wasn’t sure if it was due to the curve or if for some reason it was really slightly different (almost not noticable tho).
Thanks for checking.
If you could try linear ramp with 1st a CST from linear Ap1 to Apple Log Rec2020, and right after an Aces Transform from Apple log to AcesCG.
Hopefully I did something wrong when I first check that.
They shouldn’t be different as long as you don’t use the gamut mapper and tone mapper , just the gamut transform between camera spaces. To display that for sure will have different results as it’s tone mapping.
If they are different then it’s an error as they are matrices applied in linear
Here’s the untested Apple Log to Linear decoding function as GLSL. I’m posting this from my phone, will provide a complete and tested IDT as soon as I have access to a laptop.
Here’s the Apple Log Profile ACES IDT based on the Apple White Paper in GLSL. The matrix values are derived from BT2020 with CIECAT02 adaptation. Maybe someone can convert it to a DCTL and compare to the reference implementation (?) in Resolve.
// Apple Log Gamma to Linear Decoding Function
float appleLogToLinear(float x) {
const float R_0 = -0.05641088;
const float R_t = 0.01;
const float c = 47.28711236;
const float beta = 0.00964052;
const float gamma = 0.08550479;
const float delta = 0.69336945;
const float P_t = c * pow(R_t - R_0, 2.0);
if (x >= P_t) {
return pow(2.0, (x - delta) / gamma) - beta;
} else if (x >= 0.0 && x < P_t) {
return sqrt(x / c) + R_0;
} else {
return R_0;
}
}
Their LUT package provide a 709 conversion and a linearization lut. (need Apple ID to view page)
They put the 1D lut in a 3D .cube file. Slightly odd. So I moved it into a .spi1d file and added a .spimtx if anyone finds the need to implement it into an OCIO config or or use it standalone.
Resolve 18.6 provides support for Apple Log in RCM and ACES so you don’t need any extra implmenetation.
