Dual ISO + in-camera DNG creation

Started by Shiranai, April 30, 2017, 07:30:27 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Shiranai

I dunno if that has been requested before, but I read that somebody added a feature that makes it possible to write DNG files instead of RAW.
So I thought maybe one could combine this with dual ISO.

I think it would be a cool feature if, instead of using RAW2DNG, there would be a feature that could encode the dual-ISO files to DNG in-camera.
This feature could be selectable via
a) the menu then select the dual ISO file
or
b) an option to do its encoding after each photo
or
c) maybe even work in the background

If I requested nonsense or this has been posted already, please feel free to delete it.

dmilligan

There was a poorly written article on a popular blog that totally missunderstood and missed the point of a recent reverse engineering discovery. The fact is that it has been possible for us to write DNGs even before ML was called ML (there is DNG writing code from CHDK, the precursor to ML). There is however no plan or even good reason to replace regular CR2 stills with DNG, rather we use DNGs for whenever ML needs to save some custom image data it has manually captured, such a silent pictures.

The discovery itself simply made it possible to write losslesly compressed DNGs using Canon's own hardware compression (read: DNGs from ML will save faster and take up less space). This worked because Canon happened to use the same algorithm for CR2 compression as the one specified by the DNG specification ("lossless JPEG" it the name of it, though it has nothing to with the normal JPEG algorithm, it's named that simply because the spec comes from the same standards body).

I also believe you have confused cr2hdr with raw2dng (raw2dng is only for converting raw video from an old, no longer used format to DNG files). The cr2hdr algorithm is rather complex and even on fast, modern desktop CPUs make take 30 seconds or more to convert a single image. Running this algorithm on the camera's CPU (which BTW, don't even have hardware floating point), I imagine would take an amount of time potentially measured in hours for a single image. Regardless, there's no justification for the development effort it would take to port it. ML is not a replacement for post processing tools, and in general we never waste development effort on things that are easily accomplished in post.