On 3/19/19, Nick Renieris <velocit...@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@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@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
