[FFmpeg-devel] [PATCH] avcodec/tiff: Add support for recognizing DNG files

[Nick Renieris]

Yes, obviously this is not complete. As was said, the DNG spec is huge
and I did bring up this concern in a personal email to Paul a few days
ago.
I was told that:
> 3 months should be enough to finish most of specification, note you work on real world DNG files, so if some feature from spec is not present in any file you have less work to do
which I absolutely agree with.
The context of my contribution in this case is GSoC, so let's talk
about that: Wouldn't it be better if by the end of GSoC, FFmpeg could
open all or most of the DNG files that actually exist out there,
instead of having only specific parts of the spec implemented
thoroughly?

>A design that can only extract one image of many or one stream or one channel. Cannot preserve all information so it fails that simple use case.

> Shouldn't, ideally, these image files be demuxed as two image streams? Perhaps with the "main" image as the first stream.

Ideally, yes of course.
Realistically, I think the images with NewSubFileType != 0 and
NewSubFileType != 4 are of secondary interest to decode, as they are
commonly simply reduced resolution images of their counterparts.
In any case, it will probably not be hard to add once the important
parts are implemented.

> Still wrong, There are DNG images without thumbnails.

I suspected so but didn't have any examples to test with.
I just found one. The following happens if -subimage 1 is used:

[tiff @ 0x7fffe4099180] DNG images are not supported
[tiff @ 0x7fffe4099180] Decoding embedded TIFF thumbnail in DNG image
[tiff @ 0x7fffe4099180] This format is not supported (bpp=14, bppcount=1)

Is this a problem? If so:
I'm still not done reading the spec(s), but as far as I understand it,
there is no way that a DNG image with NewSubFileType != 1 would be in
a standard TIFF format that we can decode right now. Therefore, I
propose a check for this in decode_frame (would also check if dng_mode
is enabled) to prevent the above non-user friendly error from
happening.

I suspect NewSubFileType is not the right way to go though since the
actual image format is not specified with it. I looked at the tags
from some DNGs and I can't narrow it down to any other better field
for this.

Any better ideas? Should I perhaps just let it succeed or fail based
on the existing decoding code, as it does above? The error checking in
that code is the absolute truth of what is actually implemented after
all.

> I've used their libdng for a project. It's a big LGPL library implementing pretty much everything, but no distro really ships it, so it'd have to be embedded or built manually by the user.

Definitely something to consider. Given the posted GSoC project idea,
I assumed it was not possible/preferable for it to be embedded.