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 <one...@gmail.com> έγραψε: > > 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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
