Rawtoaces - Calling All “developer-types”

Discussions - Using ACES Tech/Engineering
,
41

Thanks Miaoqi!

It works :sunglasses:

gflags is required but not yet in the installation documentation i.e. if a user is on OSX they need to brew install gflags before installing.

1 Like
42

I’ve been testing out the rawtoaces dng branch for a while and it’s been working really well.

I’ve seen a recurring behaviour with some higher resolution raw files where rawtoaces crashes before writing the exr file. Processing with -h to output half resolution seems to fix the problem.

Here are steps to (hopefully) reproduce.

Download this cr2 file from the Canon 5dmk4 (I’ve seen the same behaviour with some NEF files as well).

I’ve tested this with the dng feature branch of rawtoaces and the with the normal branch, and the behaviour seems to be the same.

rawtoaces -v -v --wb-method 0 --mat-method 2 Y-WB-786A1230.CR2 

Starting rawtoaces ...
Processing Y-WB-786A1230.CR2 ...
The camera has been identified as a Canon EOS 5D Mark IV ...
White Balance method is 0 - Using white balance factors from file metadata ...
IDT matrix calculation method is 2 - Calculating IDT matrix using adobe coeffs included in libraw ...
The Approximate IDT matrix is ...
   0.622841, -0.048300, -0.104717
   -0.445778, 1.231981, 0.309404
   -0.068663, 0.262731, 0.773828
The final white balance coefficients are ...
   1.889648   1.000000   1.672852
Writing ACES file to Y-WB-786A1230_aces.exr ...
rawtoaces: /mnt/cave/dev/compile/aces_container/aces_Writer.cpp:212: err aces_Writer::configure(const MetaWriteClip&): Assertion `outputBufferSize < 150e6' failed.
Aborted (core dumped)

With -h for half resolution it appears to output correctly.

I hope this is helpful. Please let me know if I can provide any more information. Thanks!

1 Like
43

You are unfortunately right, this is a long-standing issue in the aces_container project (and @mzhu’s fork) that is used by rawtoaces to write the .exr files.

Taking a look now, though, I see that there is a pull request on rawtoaces from @mzhu to switch from his fork to the official ampas/aces_container project, and that he made a commit there last month which significantly increases the buffer size which is causing this issue.

Once the pull request is approved I imagine that recompiling rawtoaces will fix the problem for everyone.

44

Thanks, Andrew! I think when installing “ceres-solver”, “gflags” is one of the dependencies.

Thanks for your suggestions! :slight_smile:

45

Hi all,

“rawtoaces” is available from “homebrew” now. So if you are on Mac, just type in “brew install rawtoaces”.

If you have installed “rawtoaces” before, you may need to uninstall/unlink it first.

Thanks,

Mio

2 Likes
46

Hi Jed,

You can do “brew install aces_container” and then “brew install rawtoaces” now. It should solve the problem. :slight_smile:

You probably need to uninstall the previous “aces_container” or brew upgrade it first.

Thanks a lot,

Mio

47

First, thank you for the fix to the aces_container outputBufferSize issue, it’s working well.

I have a feature request:
Can we add support for DNG 1.4 with floating point data?
hdrmerge offers the ability to merge a bracketed set of images into a floating point DNG file, which has significantly reduced noise, good detail, and good preservation of the linear light intensities from the scene.

Useful References

  • There is a fork of hdrmerge which outputs an exr. Unfortunately it is an exr in native, sRGB or XYZ colorspace, and the demoisaicing options leaves something to be desired.
  • RawTherapee also received support for floating point DNG files in a patch, discussed here, but getting linear image data out of it this program is difficult if it’s even possible.
  • Darktable also supports floating point hdr dngs in the 2.4.0 release, but getting aces colorspace data out of it is not possible, or at least not easy using only this software.

It would be awesome to be able to convert the hdr dng file to wide gamut aces colorspace and linear to light exr intensity values. This would open up some elegant workflows for wide gamut hdri merging on linux.

I’ve uploaded an example exposure bracketed set of raw images, as well as a 32 bit floating point dng file from hdrmerge, to use as reference images. They can be downloaded from this gist:


git clone https://gist.github.com/jedypod/47b48bdb3a536f248edb33bc7243ffb9

Thanks for your consideration!

48

Hi Jed,

Thanks for the suggestion!

I cloned the branch where the RAW files exist. There seems to be an error when opening “_MG_1538-1544.dng”. Photoshop reports an error of “Could not complete your request because the file-format module cannot parse the file”.

Can you re-upload?

Thanks,

Mio

49

Hey Miaoqi, sorry about that, it looks like the file didn’t upload correctly. I’ve pushed a fix to the same gist and I’ve verified that the dng downloads correctly. Here is the direct link: https://gist.github.com/jedypod/47b48bdb3a536f248edb33bc7243ffb9/raw/9bc3c1228d557a5f171a810754811049a6fbf263/_MG_1538-1544.dng

Thanks!

50

Hi Jed,

Instead of converting different RAW files of different exposures to integer-based DNG files and merging them into a single floating-point DNG, can you convert each DNG to ACES first and merge them together into a final ACES file?

Please let us know,

Thanks,

Miaoqi

51

@cinelogdcp, yes it appears that data must be 5nm. I think all internal calculations in rawtoaces are done at 5nm increments. The error message is not as descriptive as it could be, and better documentation would help make it clearer the current constraints around imported data.

I have opened an issue on Github on your behalf related to this https://github.com/ampas/rawtoaces/issues/100

52

Hi Fancois,

We will consider the two features in the next version. As you may have known, ACES file should not be compressed according to the specification. In the meanwhile, we can provide you a “ctlrender” command for you to produce compressed OpenEXR files in “ACEScg”.

You can use Photoshop to achieve it too. Please take a look at this page suggested by @kirkthibault

Please let us know if you have questions!

Thanks,

Miaoqi

53

Hi Miaoqi, thanks for the suggestion. This is an option, however there is an advantage to doing the exposure merging before debayering, because the noise can be significantly reduced. This is the advantage of the HDRMerge software, where the exposure merging happens before debayering. See the Zero Noise Virtual Raw article, which is a technique HDRMerge employs.

I understand if this is difficult to implement though, I don’t have complete knowledge of the complexities involved in supporting 32bpc float dng files.

Thanks for considering it!

54

Thanks Scott. I did work that out previously but came to the conclusion that, for accuracy reasons, extrapolating incomplete QE data sets may not be such a good idea.

Fortunately published QE data for newer, non DSLR sensors typically exceed the 380nm to 780nm bandwidth required by RawToAces so it’s just a matter of plotting waveform diagrams to JSON. I charted a few of the sensors used in DJI drone cameras and Blackmagic cameras but it’s tedious work.

55

Hi all,

As of 03/23/2018, the latest update of “Ceres-solver” expects the option of “max_lbfs_rank” to be set explicitly and correctly.

I have set its default value to be “50”. It may slow down the regression process a little, but it works now.

You can re-build “rawtoaces” from:

This fix, along with a few others, will be merged into AMPAS master branch soon.

Thanks and have a great weekend!

Miaoqi

1 Like
56

Hi there,
thanks for building great tool!

I’ve been testing the software, and I’ve noticed two thing.

1: -W option has no effect because no_auto_bright option is always 1 in the source code.

2: XYZ to ACES matrix is little different from specification.

In the official specification, CIE XYZ to ACES transform is defined as

1.04981101 75 0.00000000 00 - 0.0000974845
-0.49590302 31 1.37331304 58 0.09824003 61
0.00000000 00 0.00000000 00 0.99125201

In lib/define.h,
it is defined as

static const double XYZ_acesrgb_3[3][3] = {
{ 1.0634731317028, 0.00639793641966071, -0.0157891874506841 },
{ -0.492082784686793, 1.36823709310019, 0.0913444629573544 },
{ -0.0028137154424595, 0.00463991165243123, 0.91649468506889 }
};

and it is being applied to the result of raw image converted to XYZ D60 colorspace when we are converting non-DNG raw file,

From the name, I am assuming that XYZ_acesrgb is a matrix that converts image from XYZ to ACES colorspace, but is there some transform applied to the conversion matrix that I am not aware of?

Thanks!

57

Hello,
I started investigating this because I noticed developed ACES images seems to be all shifted toward blue,
and here’s some update on what I found.

It seems like we are using a matrix is a XYZ to ACES transform with Bradford Matrix from D65 to D60 applied.

So there are two chromatic adaptation applied when rendering Non-DNG files.
(CAT02 matrix from D50 to D60, and Bradford Matrix from D65 to D60),
and it doesn’t really make sense to have two chromatic adaptation to D60 applied twice.

Since the code is using libraw to convert to XYZ colorspace,
it seems that converted XYZ is in D65, and not D50,
so the first CAT02 adaptation from D50 to D60 is not needed in this case.

When I applied inverse of CAT02 to the developed ACES images,
the result I got was closer to what I expected.
(Since matrix multiplication is not commutative,
I know it’s not a correct result, but the result seems more closer)

Can anyone from ACES team take a look into it?

58

@kisakata Thanks so much for digging into this! Can you add issues to github so we can keep them on the list of things to fix?

Thanks so much

59

@Alexander_Forsythe Thanks for the quick reply.

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.

Thanks!

60

Hi

If my camera (Fuji X-T20) doesnt have any spectral sensitivity info, is there then any point in using rawtoaces over libraw?

Libraw (0.19.0) is able to pick up the white balance multipliers from the raw files, but rawtoaces doesnt?

thanks