Rawtoaces - Calling All “developer-types”

Tags: #<Tag:0x00007f87a73b2000> #<Tag:0x00007f87a73b1dd0>
(Alex Forsythe) #61

@laserpanda yes! Rawtoaces defaults to building an IDT based on spec sens if it’s available but if not it will used metadata from the file or libraw to build an IDT. Your mileage may vary but it’s worth a try.


(Michael Garrett) #62

I’ve created a pull request that reflects the change that I made while testing.
(https://github.com/ampas/rawtoaces/pull/108 )
Hope my comments are enough to figure out the issue is.

Would be nice if someone from ACES take a look at it,
because I’m not really certain as to what is going on inside the code.

Following up on this, I notice the blue tint issue with DNG conversions is still open on Github. I can verify I’ve had what I think is the same issue.

Attached are five raw conversions for a CR2 shot with a 5D Mk II. The last shows the blue cast for DNG conversions.

  1. Rawtoaces mat-method 0 conversion of CR2 using the 5D MkII spectral sensitivities included with the rawtoaces installation. I consider this to be the baseline as I imagine it’s the most accurate.

  2. Rawtoaces mat-method 1 conversion of CR2 using metadata. Still quite similar to the spectral sensitivities conversion but a bit cooler.

  3. Canon DPP CR2 to jpeg conversion, then imported to Nuke ACES working space using utility sRGB. Then some slight luminance-only gamma and exposure adjustment to better match example 1.

  4. DCRaw output as ACES gamut linear tiff, flags are dcraw -4 -o 6 -H 3 -w -T
    Exposure lifted by +4 stops in Nuke to match the exposure of the rawtoaces spectral sensitivities conversion. I tried both CR2 and CR2 converted to DNG with Adobe’s DNG Converter as inputs for DCRaw. I got the same visual result for both CR2 and DNG, hence only attaching one image. Overall it’s similar, and warm.

  5. Rawtoaces mat-methods 1 and 2 for the same DNG I used in example 4 (converted from CR2).

I get the same result for both methods. You can see the image is much more blue which backs up the issue first found by kisakata. I’m showing one example here, but I’ve had consistently the same issue with DNGs with other devices.

I’ve visited the pull request page and the last status update on July 17th was “We’ve confirmed that the XYZ_acesrgb matrix is in fact using a D65 to D60 Bradford matrix. Your code changes are being verified by the admin, to be updated to the source master.”

It would be great to see this fix folded into the version I would install via homebrew. Thanks so much.

(Edited to fix wrong image uploaded and correcting a few things)

1 Like