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

[Nick Renieris]

Hello,

>Similarly if we support demuxing "auxilary / secondary or what they are called images" and muxing then we should be able to connect these and not just be able to extract one image.
>Thats the ideal. The question how to implement this, or if this is the way to go or if this is too complex to do is up to the mentor for a GSoC project.
>It could be done by spliting into streams at the demuxer level, by using side data or decoding the images in sequence in the decoder or other ways. Each of these seem to have disadvanatges ...

Ok, but what does this have to do with my patch though? Isn't
something like this possible with TIFF images too? As far as I know,
that's not supported at the moment either, I only know of -subimage
which I don't think does exactly what you mean.

Not to mention, this patch is for preliminary support, I don't suppose
you require a massive patchset that implements everything altogether?
Besides, GSoC requirements state that I need to get a minor patch in,
before I can even apply. This is what this patch is for.

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

Not sure why this was mentioned? It works with my patch too.
I thought we came to an agreement, that by default it should show a
message, instructing the user to show that they can decode the
thumbnail with -subimage.
This is what my patch does.

Nick R.

Στις Τρί, 19 Μαρ 2019 στις 12:58 μ.μ., ο/η Paul B Mahol
<onemda at gmail.com> έγραψε:
>
> 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
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel