ACES for Magic Lantern Raw Video

[dmilligan]

That makes no sense. If the Adobe DNG converter adds some metadata to a DNG file (the camera matrices), you are saying that a DNG reader is not allowed to extract and use that information? I thought the whole point of putting metadata in a DNG file was so that a third party could extract and use said metadata.

Also, if I run an image through Adobe DNG converter, then suddenly part of that file becomes the IP of Adobe? That also make no sense.

[Andy600]

...and puts DC Raw and a host of other apps/libraries in breach of copyright  These matrices simply describe the transform from camera RGB values to CIE XYZ. So what you are effectively saying is that you can only convert to a DNG with no matrices and can only use the Adobe DNG Converter now  , and that any camera that Adobe labs have defined a set of matrices for can't be used, written, or read with anything other than Adobe apps? Really?  Ok, we'll rebuild them using Dx0 labs published data - it would be funny if the matrices compute to the same values.

[DeafEyeJedi]

Hmmm... Point taken guys!

Could you please help clarify what,re referring to earlier @DFM?

Otherwise it just doesn't make any sense...

[reddeercity]

Sounds like back to the "embedded" Camera matrices from ML.
Personal I always choose the embed matrices when working with raw . I feel the embedded matrices produces a better Image.
With less noise etc.... I don't think embedding all this extra info is really worth the effort , There is no Short cut in producing a IDT for A.C.E.S

[Andy600]

@reddeercity - according to DFM that too would breach copyright because the original matrices that  ML used for DNGs were based on DCRaw matrices which also came from Adobe.

As I've repeatedly said, these matrices are simply telling the DNG reader how to translate sensor RGB tristimulus values to scaled CIE XYZ which is the basic connecting colorspace for most (if not all) raw readers. Canon do it with ICC and Adobe do it with DNG tags. It's basic color science and is a requisite for the DNG format to work. The original embedded matrices are for a single illuminant (based on half of the the 5D Mark III's set). To make DNG's color and white balance offsets behave well in any app other than Adobe Camera Raw requires you to either nail WB every time when shooting or embed dual illuminant matrices which can give a hint to the DNG reader so that it can interpolate properly between light sources and enable use of rudimentary preset white balance settings. basically it's a fundamental requirement of the format and the only reason you won't notice this in Adobe Camera Raw is because any embedded camera matrices are overridden by the camera profile you choose and all of them use these matrices.

Re: IDT's if these matrices are embedded the basic CinemaDNG IDT will work fine - as i mentioned earlier in the thread, the aim of ACES is to define a universal, camera agnostic look and even the big boys are having trouble doing this because they all want their cameras to look good! ARRI seem to be the only ones taking it seriously. Making IDT's for something like Cinestyle is another matter - that is a world of pain!

[reddeercity]

@ Andy600 , I do see your Point to all this.
Just a thought have you look at the IDT for the Cinema EOS Cameras ? http://www.usa.canon.com/cusa/professional/products/professional_cameras/cinema_eos_cameras/eos_c500#DriversAndSoftware
I see they now have IDT for C100, C300, C500. with Test EXR & DPX images, would this be helpful ?

[a1ex]

Incorrect matrices can manifest in colorcasts, weird green tints etc  - sound familiar? 

Here, those "weird green tints" are usually caused by wrong black level, not wrong matrices.

[chmee]

@DFM
please leave us an "official" statement about using these colormatrices. they are taken from the dng's, so i see also no point of breaching copyright or similar.

[DFM]

There's a difference between editing a DNG file that already has matrix information embedded within it, and copying the Adobe Standard matrix supplied with the Camera Raw/DNG Converter software so you can use it to create other DNG files (or for that matter, mentioning the term "Adobe ###" in any third party product).

The EULA for the DNG SDK is different to that for Adobe's desktop software, it permits any use of the SDK's source code provided copyright notices are maintained - and that's why there are no matrices, lens profiles, etc. in the package. The EULAs for Camera Raw and DNG Converter are the standard versions which forbid any extraction, decompiling or reuse (clause 4.5b and 5.2).

I can't give you an exemption from any of this; you would need to negotiate terms with Adobe's legal department. In the first instance I would advise posting a detailed request on the DNG Community Forum (including explanations of the license terms for ML, where and how the matrices would be used, what you intend to call them, etc.) and I'll make sure it gets read by the right people.

[Andy600]

@DFM - there is no exemption required here because there is no decompiling, reuse, porting, modification, reverse engineering or any other process here relating to Adobe software that violates the terms of Adobe's EULA. The software is not touched. There are many apps that make extensive use of the DCRaw libraries and that library features older versions of Adobe Standard matrices. The matrices are simply telling the raw reader how to transform a specific camera's sensor RGB values (under 2 illuminants) to CIE XYZ colorspace with Bradford chromatic adaptation. If we remeasure/recalculate we will come up with the same numbers.

Also, (I may be totally wrong on this but) I think the recorded DNG files are produced in-camera. Then wrapped in an MLV container for convenience with some of the header/footer info stripped for speed reasons.

If you run your raw files through the DNG Converter it will embed these matrices in the DNG according to the camera model it identifies. Regarding copyright of Adobe trademarks, that's another matter and why some of us do follow the guidelines and not use Adobe logos plus add the registered trademark symbol when referring to Adobe products and post a full disclaimer.

@a1ex - Yes, in most cases it's mainly to do with incorrect black level but I have seen DNGs where the matrix and completely wrong white balance (when shooting) has caused a similar issue that may cause the user to start messing with the DNG black level. My point is that colorcast issues caused by white point offset will be less likely and point to DNG black level calibration being the problem. In something like DaVinci Resolve where there is no automatic method of white balance for raw images most users will find it easier to be able to use the white balance color temp presets as a neutral starting point.

@reddeercity - Thanks! I know about the Canon IDTs. I have them and quite a few others plus build routines, scripts and a ton of other documents/images etc for developing and testing ACES IDTs.

[dmilligan]

There's a difference between editing a DNG file that already has matrix information embedded within it, and copying the Adobe Standard matrix supplied with the Camera Raw/DNG Converter software so you can use it to create other DNG files

This is idiotic. By this logic I can't even use my operating system to make a copy of a DNG that has been through DNG converter, because I would be using it "to create other DNG files" with said matrix information embedded in it.

[DFM]

If we remeasure/recalculate we will come up with the same numbers.

And if you did create an independent set of values via your own measurements and called it "ML Standard", we wouldn't be having this conversation.

This is idiotic. By this logic I can't even use my operating system to make a copy of a DNG that has been through DNG converter, because I would be using it "to create other DNG files" with said matrix information embedded in it.

No, you're misunderstanding what I said. Adobe makes no ownership claim against any files you create with their products, but the algorithms used by Adobe software to create those files are copyrighted and/or patented, as are certain file formats (e.g. the structure of a PSD file is proprietary even though Adobe publishes the full specs). If you used Photoshop to create a panorama, you still own the rights to the stitched image - but you certainly cannot take the class library that does the stitching and compile it into your own program.

[Andy600]

@DFM - Ok, we will remeasure and recalculate to produce the same numbers and call it ML Standard (a pointless exercise). The matrices don't need the Adobe name attached to them. We're not trying to coat-tail on the Adobe name, if anything, ML has increased Adobe's user base. I only wrote Adobe Standard so that the devs would know the matrices are gleaned from the DNG converter.

[Andy600]

Somebody should inform X-rite that their colorchecker software violates Adobe EULA

[chmee]

please @all. discuss in a gentle, right manner.

@DFM i dont see any reverse-engineering and not breaking rules.
4.5b - its about the software, not about the calculated files (vulgo dng and tags)
5.1 misusing and kind of Rules of Conduct - we re not serving adobe services (nor parts) in any illegal kind.

[DeafEyeJedi]

We're not trying to coat-tail on the Adobe name, if anything, ML has increased Adobe's user base. I only wrote Adobe Standard so that the devs would know the matrices are gleaned from the DNG converter.

This one puts the nail on the wall. So true & Well said @Andy600!

Only because I slowly lost interest in Adobe softwares back in the hey days until @a1ex's ML forum became a huge hit (& still is) in which obviously brought me back!

[Andy600]

@Chmee - Yes, just to clarify the tone of my own comments in this thread because I know written text can easily be taken out of context. Everything I have written is not intended to be confrontational or derogatory to anyone concerned. My comment about X-rite was a little tongue-in-cheek. I totally respect the opinions of others even if I disagree them.