I just sent you a fresh link. Thanks!
Hi,
I took a look at the still. Can I double check what it the WB set up on the Canon camera and what is the one on the Alexa?
Thanks
We shot with mixed lighting by purpose. But set both cameras to 5600k. If the frames are problematic I could also send you some 3200k frames without mixed lighting.
Ok. Looked it again.
If possible, I would like to have a shot with WB neutralized on a 18% gray. Before take the shot, for both cameras, you should make sure that the 18% gray has equal RGB values, you can use the auto WB on both cameras if you want. Make sure that you do it in the exact same light conditions, with the same light reflection on the 18% card and possibly from the same camera position and angle.
Once the WB is done, please note it and then take the shot with both Alexa and Canon camera, again possibly from the same camera position.
They WB on the shots you provided wasn’t neutral, even if you have used the same K temperature, lenses have flare and color aberration that makes them look different. If you want to create a LUT that works, white balance should always be neutralized.
Thanks.
Unfortunately I don’t have access to an Alexa for further tests.
I was hoping for a rather generally valid Canon 5D IDT. Isn’t that the way it should be?
Did you plan to generate a LUT based on the cr2 and Alexa files?
I will send you some frames from another test setup. The WB won’t be perfect, but should match roughly.
Thanks!
A few things worth noting are:
CR2 is a stills format, and therefore is specifically encoded for a display referred pipeline. In Resolve it is treated in a similar way to Adobe Camera Raw, and you’ll notice if you enable Highlight Recovery that the white point shifts down to accomomodate extra highlight detail so that the signal never goes above 1.0. There are other limitations too, such as non-access to Resolve Colour Management. Therefore you should convert your CR2 files to CinemaDNG before proceeding further.
Now, although the previously inherent display referred limitations are lifted (RCM works and and highlight recovery allows values over 1.0), there still is the paradox of CinemaDNG to contend with. CinemaDNG is still based on Adobe’s display referred intended stills format, in that it maps the full signal into the 0.0 to 1.0 range i.e. sensor saturation is mapped to 1.0 as opposed to the scene referred approach where reference white (90% scene reflectance) is mapped to 1.0. Now, unless 5D raw reaches sensor saturation around 2.2 stops above middle grey (18%) it would appear that some signal scaling is occuring, so perhaps it’s worth looking into reversing that scaling in order to attain the actual scene referred values, and from there (with the signal in linear light) it should be a simple matter of a 3x3 matrix to convert to ACES primaries.
I would disagree with this specific statement.
CR2, like pretty much all RAW formats, is scene referred linear under the hood.
It only becomes display referred when some sort of picture rendering is applied. Normally this just happens without the user being aware by whatever RAW developer they’re using, but the values stored in the file are all generally scene linear.
Simplest way to get a handle on this is by using dcraw to debayer to a linear 16bit tiff.
Try something like:
dcraw -o 1 -4 foo.cr2 (For a linear sRGB/Rec709 prim image)
If you want to treat dcraw as a sort of generalized faux IDT system you can use -o 5 to spit out scene linear XYZ, which is easy to flip to ACES.
Keep in mind that those the values will all be within the 0-1 range. This is just because the sensor is saturating/clipping at 1. Scaling those values up so your grey card is at .18 will push lots of them into the “above 1” superwhite range.
4 Likes
Thanks Alex for your help. I spent some time with dcraw and I got good results with some easy cr2s.
I took a picture of a colorchecker with 0EV and used with dcraw like that:
dcraw -v -o 5 -4 -T -H 2
Then I imported the resulting TIFF in a Nuke setup set to ACES and put the read node to “Utility - XYZ -D60” and multiplied the 50% grey patch to a value of 0.18. Result (rendered with a Rec709 ODT)
All good so far. But it is getting really weird if I try the same thing with a picture which is overexposed.
In ACR I can easily recover all highlights with a neutral color and even the colorful tape is not getting desaturated in the bright parts. The best result I can get from dcraw is that:
-H 2 makes the bright patches already a bit more neutral, but still far away from really good.
Antoher example where dcraw does not a good job with my current settings is a test setup with a big dynamic range and mixed lighting. Especially the reds are getting dull and magenta:
I tried different parameters, but still the is the best result I can get. The white balance in dcraw seems to a have a big influence on the final colors. Resetting the multipliers with -r 1 1 1 1 is not too bad, but produces very saturated images.
Do you have any other ideas to improve the process? I can send you the RAW files if you like.
You need to specify if you want a 16bit uncompressed Linear TIFF in DCRaw (-4 -T) else you will, by default, get an 8Bit Rec709 (2.2 gamma) TIFF - although the 16bit Linear TIFF will probably look too dark in Nuke (I thought ACES was scene-referred linear!?).
DCraw can also write ACES primaries (-o 6) but regardless of this you may still get some clipping because of the TIFF integer format - hence why the ACES container is half float EXR.
See here for DCRaw useage.
HA! I had no idea dcraw now supported ACES directly now, that’s awesome!
As for the clipping, 16bit TIFF being an integer format is only an issue if you’re actually trying to store values above 1, which isn’t an issue at this point. It’s only when you scale up the “too dark” data.
More or less all RAW formats are 12 or 14bit integer black and white images. There isn’t anything “above 1”. Highlight recovery is either scaling down values that the default display transform deemed over exposed (but are still under 1 in the original RAW data), or values being interpolated from other unclipped channels.
If you want to get a really clear look at whats actually in your RAW files, use dcraw’s “document mode”
-d Document mode (no color, no interpolation)
-D Document mode without scaling (totally raw)
This basically dumps the raw un-debayered sensor data into a tif. From there you can really poke around and see what’s going on, even build you’re own debayer system from basic nuke nodes. (I’d recommend this as an interesting technical excercise, not a practical solution to debayering images).
As for ACR producing better highlights on the tape, I’d simply put that down to Adobe having more sophisticated highlight recovery. Whilst it’s not always the easiest tool to integrate, Lightroom is very impressive on that front.
That is exactly what I did. As I wrote in my post above I used “dcraw -v -o 5 -4 -T -H 2”
Did the -o 6 come with the update to DCraw 9.27? I am currently on 9.26 and it seems it is not working here. But thanks for the info!
Alex, do you have any information about how to integrate Lightroom in an ACES Workflow? Would be awesome if one could adjust a Rawphoto in Lightroom and export it into ACES colorspace after that.
Hi,
Adobe Camera Raw (ACR) and Lightroom colour processing apply various non-linear adjustments to your images which will get in your way if your are trying to work with scene referred values:
- Adobe Tone Curve which is applied to perform tone rendering so that you have a pleasing output: https://docs.google.com/spreadsheets/d/1JV2BzrfnpXgKsqEsw6cS2bGc8I2u8isKabt3nGLckWs/
- Hue Twists which is a look up table embedded in the .dcp profile of your camera and usually attempts to bring the camera processed colours closer to those of a perfect colour rendition chart, it is also used for creative intent. Most of the time they are bad: http://dcptool.sourceforge.net/Hue%20Twists.html
So the first thing in order to get back into relative scene referred luminance values is to get rid of those two adjustments, it can be done by tweaking the .dcp profile of your camera. Lee Perry Smith has recently made a step by step tutorial on how to remove the Adobe Tone Curve here: http://www.triplegangers.com/index.php/blog/cat/technology/post/linear-pipeline/ and you can get rid of the Hue Twists by using dcpTool.
Once you have done that you could export to a regular sRGB or ProPhoto 16-bit integer tiff file and convert your values to ACES using your preferred method.
The caveat doing so is that you will have lost the extra dynamic range of your image (anything above 1.0 will be lost), there is unfortunately to my knowledge no elegant solution at the moment to keep it if you want to still work with Adobe tools.
Cheers,
Thomas
Hi folks - I just joined this community and this is my first post here, so if I am posting redundant information, I apologize. If you are interested in using an ACES color workflow during raw conversion, including Canon CR2 files, you may want to take a look at the (Mac-only) raw converter called “Iridient Developer” - http://www.iridientdigital.com.
With the release of v3, the converter utilizes ACES with an sRGB tone curve as its internal working space and provides the capability to export your RGB processed image in that working space as well as whichever ACES ICC profile you may have installed on your machine. The quality of the converter itself is widely lauded in the photographic community, although it does not have the market presence of adobe.
Download the trial and take the time to work with some of your test images to see if this fits into your workflow.
Hope this helps,
Kirk Thibault
Bwewyn, PA
Hi,
very soon Filmlight will deploy its OnSet Look Development Tool “Prelight”.
There will be a free version too, to create Looks which can later be use in Postproductions.
Prelight as Baselight now debayers Still Raw Frames into scene referred Linear XYZ, from there Truelight Colour Space converts the data into any user specific working colour space like ACEScct.
This should allow you to create a Look based on a Still Camera and apply the Look to any other cinema camera’s output.
hope this helps
best
Daniele
1 Like
Just a little bit of a tease … we are working on a tool here that will be able to convert most digital still RAW formats to ACES. It’ll probably be a command line tool at first but it’ll provide multiple mechanisms to get from RAW to ACES depending on how much information you (or your raw file) has about your camera.
4 Likes
That is neat! I assume it will be based of dcraw / libraw? What about whitebalancing?
Cheers,
Thomas
We are leveraging libraw and aces_container. There will also be custom code in it to create good IDTs from spectral sensitivity data if you have it. White balance in that case is also calculated from spec sense for a given light source but always user overrideable.
2 Likes
Ohhh! I like the sound of this!
1 Like
Right now we are using Affinity Photo.
It is working really good with 32bit, converts your RAW photos directly to ACES (or ACEScg) and has OCIO support. Especially the OCIO viewer process is very helpful.
The only thing that is missing is a batch convert function…
1 Like
Could you provide some more details about your workflow with Affinity Photo? I’ve done some testing after reading your post, and by
- Using the Develop Assistant to change Raw Output Format to “RGB (32bit HDR)” and Tone Curve to “Take No Action”
- Pushing the Exposure slider 2 stops up on an already bright image, then switching from Develop Persona to Photo Persona
- In the program preferences, setting the “32bit RGB Color Profile” to “ACES CG Linear”
- Exporting as “OpenEXR 32-bit linear”
I was able to import the resulting .exr file into After Effects and recover all of the highlights from this intentionally overexposed image. Hard for me to know whether the file really is in ACEScg color space, but it is cool to get around Adobe Camera Raw’s display referred process. I couldn’t find an option for ACES AP0, though, just ACEScg AP1.
There is also (at least as of v1.5.2) a “New Batch Job” option that let me convert a folder of cr2’s into exrs, but it is completely unclear as to what options are being applied to the process - the resulting exr has a different exposure and a loss of detail from the single exrs I made using 16-bit or 32-bit, tone curve or no curve. I wouldn’t trust it without knowing more about what it’s doing.
1 Like