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

[Paul B Mahol]

On 3/19/19, Nick Renieris <velocityra at gmail.com> wrote:
> 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.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Here is one file that works just fine with current ffmpeg:
https://0x0.st/z8pf.dng