Blackmagic DNGs not supported

[pedrocr]

trafficstars

A user supplied us with a DNG for a blackmagic camera:

http://andreamonzini.com/files/BM_Production_Camera_Test.dng.zip

This isn't supported by rawspeed because the prediction direction is 6 instead of 1. It's probably right to left instead of left to right or something of the sort. Is this just a matter of writing a new decodeScan() function for this case or is there something more to it?

[klauspost]

There seems to be more to it. Here is the initial result:

There is something with the size. Image size (in main DNG) is 4032x2192. It is split into tiles of 1008x2192. This makes 4x1 tiles, which is fine.

However, the actual LJPEG frame within the file is 2016x1096. They do that because otherwise using prediction 6 is very bad. However, the decoder doesn't just blindly wrap the image, which makes it overwrite other parts.

I will see if I can find a good solution.

[klauspost]

Second attempt. Better, but now predictor is getting reset too often.:

[klauspost]

Best one yet. Still a weird vertical line:

[klauspost]

The DNG spec states

For lossless JPEG, the internal width/length/components in the JPEG stream are not required to match the strip or tile's width/length/components. Only the total sample counts need to match.

So I guess it is something that should be handled that way.

[AndreaMonzini]

Hello, thank you for the support. i don't know if it's useful but i just used exiftool for more info about compression of the dng:

ExifTool Version Number : 9.69 [exiftool output deleted]

[klauspost]

@AndreaMonzini - thanks, I know exiftool, and it isn't what we are looking at. I have taken the liberty and deleted the output, since it only takes up space.

I am looking into restructuring the DNG decoder to be able to re-structure the output, without making it slower, which is currently where it is at. This isn't solved by a few minor tweaks.

There are some potential conflicts (encoded tiles being too big for their destination, etc) I also have to consider, since we are obviously using the decoder for a lot of things.

[pedrocr]

If you're looking into the DNG/LJPeg decoder you may want to have a look at two other cases currently not supported:

• Some of the Leaf cameras use a lossless jpeg format currently not supported. See PR #31 for more details
• There are some tools (e.g., hdrmerge) that produce higher bit depth DNG files that are currently not supported. There's a darktable bug report with more details (http://redmine.darktable.org/issues/10177)

[porst17]

Regarding the DNG files produced by other tools: It is not related to bit depth. HDRMerge, for example, can create 16, 24 and 32 bit DNG 1.4 files and none of them seem to be properly supported. The data is stored as floating point data, not integer, since this is more appropriate for HDR. The HDRMerge DNG files are loaded properly by the Adobe DNG Codec 2.0 (Windows) and hence, I assume that they conform to the standard.

[LebedevRI]

Based on previous discussions about HDRMerge DNG's, i believe they are using different compression algorithm - deflate (zip), while rawspeed currently only supports lossless jpeg (probably, most DNG's) and normal jpeg compression.

[porst17]

I'll dig into the HDRMerge code to find out the truth and let you know.

[porst17]

Verified. The relevant lines are in HDRMerge are:

rawIFD.addEntry(COMPRESSION, IFD::SHORT, TIFF_DEFLATE);
rawIFD.addEntry(PREDICTOR, IFD::SHORT, TIFF_FP2XPREDICTOR);
rawIFD.addEntry(SAMPLEFORMAT, IFD::SHORT, TIFF_FPFORMAT);

[AndreaMonzini]

Hello, can i help with testing? Thank you.