SUMMARY Old DNG images, shot with Fujifilm S3, then run through Adobe RAW DNG converter show up completely purple. This happens with some other apps, some are fine (Preview, Xee on Mac) The jpeg thumb is fine. STEPS TO REPRODUCE 1. open it with digikam for preview or edit I can prevent the error by running it through Adobe RAW converter again, but activating the custom setting "Linear (demosaiced)". Then the DNG looks fine. OBSERVED RESULT image is purple EXPECTED RESULT regular image SOFTWARE/OS VERSIONS Ubuntu 18.04 Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
Created attachment 126679 [details] screenshot showing the effect due to upload constraints I could not attach the original DNG (13MB), sorry
I am reading on the Adobe Website: "Linear (demosaiced): The image data is stored in an interpolated (“demosaiced”) format. This option is useful if a camera’s particular mosaic pattern is not supported by a DNG reader. The default mosaic format maximizes the extent of data preserved. Mosaic image data can be converted to linear data, but the reverse is not possible." For one, I want to avoid processing hundreds of images and a possible reduction of data does not seem like good option. This is why I didn't do it 2009 (about). The hint comes from that too: the DNG reader has a problem with the Fujicolor S3's data. I saw someone with an S5 having the same issue using Affinity on Mac.
Component Info: digikam version 6.4.0 CPU cores: 4 Eigen: 3.3.3 Exiv2: 0.27.2 Exiv2 can write to Jp2: Yes Exiv2 can write to Jpeg: Yes Exiv2 can write to Pgf: Yes Exiv2 can write to Png: Yes Exiv2 can write to Tiff: Yes Exiv2 supports XMP metadata: Yes HEIF encoding support: Yes ImageMagick codecs: 6.9.10 KF5: 5.61.0 LensFun: 0.3.95-0 LibCImg: 130 LibJPEG: 80 LibJasper: 1.900.23 LibLCMS: 2080 LibLqr support: Yes LibPGF: 7.19.03 LibPNG: 1.6.35 LibRaw: 0.19.5 LibTIFF: 4.0.10 Marble: 0.27.20 Parallelized demosaicing: Yes Qt: 5.13.1 Qt Webkit support: Yes VKontakte support: No AkonadiContact support: No Baloo support: No Calendar support: Yes DBus support: No Database backend: QSQLITE HTML Gallery support: Yes LibAVCodec: 57.89.100 LibAVFormat: 57.71.100 LibAVUtil: 55.58.100 LibGphoto2: 2.5.14 LibOpenCV: 3.4.7 LibQtAV: 1.13.0 Media player support: Yes Panorama support: Yes
Can you upload a sample image to a cloud service? Maik
Here are 3 images. digiKam reports the size wrongly at 3582x3582, Aspect Ratio of 1:1 While I don't get the same errors, there seems to be some relation to bug #257737 Possibly related to sensor type used in the Finepix Series? Another test: opening in Rawtherapee 5.3, the files are ok. Configuring digiKam Image Editor > RAW behavior to use Rawtherapee, leads to a proper image in the digiKam Editor. TIFF exports are good /purple accordingly. https://my.mail.de/dl/b812abb2db670c13d6cd6dad7dc8957b https://my.mail.de/dl/d885848b693cc5180cab85dc5adc84c9 https://my.mail.de/dl/a1553fba58a1adf1e1702baf6531fe37
> While I don't get the same errors, there seems to be some relation to bug > #257737 Possibly related to sensor type used in the Finepix Series? With this I meant that the exported uncompressed TIFFs have the same size difference: DNG=12MB, TIFF from digiKam 16bit import=18MB, TIFF via RAWtherapee import=70MB
Thanks for the sample images. Just a quick test so far. Exiv2 reports that it cannot read the Fujifilm Makernotes. Darktable cannot open the file, reports an unknown format and then cannot read white balance data. Maik
Thanks for that. The files certainly seem wacky. Different apps, different results. Possibly related to the libs they use? BTW I tried digikam 7.0 beta 2, no change. For the sake of it I had a look with exifprobe, that starts to output some maker notes, then segfaults. exiftool runs through fine, but I have to admit I am not sure if the maker notes are output. The man pages of exiftool mention that: "A common problem with some image editors is that offsets in the maker notes are not adjusted properly when the file is modified. " Maybe it depends on the cleverness (?) or resillience of the reader to handle that kind of damage? Martin
In case it helps: I dug out an old RAW image (some left) from my S3Pro and ran it through the current Adobe DNG converter on my Mac (not demosaiced). The RAW works find in digiKam, the DNG is purple. There is a system to the madness. Here are links to the images: https://my.mail.de/dl/8215b30379658a411ea533f1f455478f https://my.mail.de/dl/07672828f01e19a65b5b3f4e24ebb64a
As I said, Darktable cannot open the files either. It could be that Exiv2 cannot read the Makernotes. Maik
By the way, Darktable has the same, older bug report with the purple images. In the meantime, Darktable can no longer read the images. Maik
yes, Maik, I remember to see the some thread in Exiv2 github forum about markernotes update and fix. Probably a better support will be done in next Exiv2 release. For the moment Exiv2 project slow down to advance... It's problematic. Gilles
Where does this leave us? So various apps "have issues" with raw files. Including Darktable that clearly suggests to use DNG files. They do mention the purple cast here: https://www.darktable.org/2012/10/whats-involved-with-adding-support-for-new-cameras/ I am unsure which raw lib they actually use at this time in the above link it reads "darktable doesn’t use dcraw/libraw and more." Rawtherapee has no issues whatsoever with my DNG files (about 2700). They claim to use dcraw as raw reader. They even more suggest going to DNG via Adobe DNG converter (https://rawpedia.rawtherapee.com/How_to_convert_raw_formats_to_DNG) As an aside Ubuntu 18.04 has LibRaw 0.19.5 in the repository. As digikam appimage has all built in, that is irrelevant. Manually upgrading to current exiv2 0.27.2, brings no change in reading the metadata. I had a look with exiftool the output for an original S3Pro raw file and the converted DNG. Looking with diff, they are hugely different. Could it be an issue of the raw handler that is used? What is the big difference between Rawtherapee and digikam in this sense? Thinking into a different direction: could it be that Rawtherapee demosaics the file before displaying it? Unfortunately my coding days are long gone, so I'd be challenged to research into, how the "logic" works here. Maik, you seem to hint that progress with exiv2 is "slowish". What relevance does exiv2 have for interpreting the raw/dng files? I'm trying to figure out where the glitch is most likely to be. Thanks, Martin
MArtin, >Where does this leave us? So various apps "have issues" with raw files. Including Darktable that clearly suggests to use >DNG files. They do mention the purple cast here: > >https://www.darktable.org/2012/10/whats-involved-with-adding-support-for-new-cameras/ > >I am unsure which raw lib they actually use at this time in the above link it reads "darktable doesn’t use dcraw/libraw >and more." yes, darktable has own implementation of Raw demosaicing >Rawtherapee has no issues whatsoever with my DNG files (about 2700). They claim to use dcraw as raw reader. They even >more suggest going to DNG via Adobe DNG converter (https://rawpedia.rawtherapee.com/How_to_convert_raw_formats_to_DNG) In this case we need to use a the closed source RAW to DNG converter. Not he best way... And RawTherapee use also a dedicated Raw engine. >As an aside Ubuntu 18.04 has LibRaw 0.19.5 in the repository. As digikam appimage has all built in, that is irrelevant. >Manually upgrading to current exiv2 0.27.2, brings no change in reading the metadata. No, digiKam appImage 7.0.0-beta3 use the lasted libraw version (beta not yet released). You must test with this version which is the current development stage. https://www.libraw.org/news/libraw-snapshot-201910 >I had a look with exiftool the output for an original S3Pro raw file and the converted DNG. Looking with diff, they are >hugely different. 2 file format different, so 2 ouput differents. It's normal >Could it be an issue of the raw handler that is used? What is the big difference between Rawtherapee and digikam in >this sense? Thinking into a different direction: could it be that Rawtherapee demosaics the file before displaying it? There are 3 possible bugs : 1/ In libraw. After all the Raw mosaic extraction is done with this lib. For the DNG converter, there is no demosaicing stage. The RAw matrix is taken as well as a bytearray and passed to the Adobe SDK for encoding. Note : libraw is also used to extract the color matrix of the RAW data, which is different than all format. I remember that lead libraw author report me that this matrix was deducted by reverse engineering using... Adobe DNG converter (:=))). It's and old talk by mail, and it's difficult to get the right words to explain. So perhaps the colors matrix need to be updated in libraw, simply... 2/ The DNG converter code as well. The way to play with Adobe SDK API is complex and of course code can be bugous. If you is curious code is in gitlab : https://invent.kde.org/kde/digikam/-/blob/master/core/libs/dngwriter/dngwriter_convert.cpp ... and search 'fuji" string to see all specificity to handle colors matrix and rotation of raw data. 3/ The Adobe DNG sdk is too old. Code was not updated since 2012, and Adobe has released 2 new versions since this date. I created few weeks ago a new devel branch in git and updated the DNG sdk to last version, applied fix to compile and tried to use : it crash quickly. So investiguations are required.... Gilles Caulier
Hi Gilles, > > Rawtherapee has no issues whatsoever with my DNG files (about 2700). They claim to use dcraw as raw reader. They even >more suggest going to DNG via Adobe DNG converter (https://rawpedia.rawtherapee.com/How_to_convert_raw_formats_to_DNG) > > In this case we need to use a the closed source RAW to DNG converter. Not he > best way... > And RawTherapee use also a dedicated Raw engine. I agree, closed source is not a good way to go. I have since installed the beta3 via a git clone... and my own build. In parallel I have tried with the appimage of beta3. Both still give me purple images. I had a look into the source code, it gives me some idea, but I have to admit, it is a bit beyond me to hunt for the bug in the the possible places you suggest. My coding ability a too "rusty" Is there any other way that I can support debugging? Trying out whatever, testing this or that? Martin > There are 3 possible bugs : > > 1/ In libraw. After all the Raw mosaic extraction is done with this lib. For > the DNG converter, there is no demosaicing stage. The RAw matrix is taken as > well as a bytearray and passed to the Adobe SDK for encoding. > > Note : libraw is also used to extract the color matrix of the RAW data, which > is different than all format. I remember that lead libraw author report me that > this matrix was deducted by reverse engineering using... Adobe DNG converter > (:=))). It's and old talk by mail, and it's difficult to get the right words to > explain. > > So perhaps the colors matrix need to be updated in libraw, simply... > > 2/ The DNG converter code as well. The way to play with Adobe SDK API is > complex and of course code can be bugous. > > If you is curious code is in gitlab : > > https://invent.kde.org/kde/digikam/-/blob/master/core/libs/dngwriter/dngwriter_convert.cpp > > ... and search 'fuji" string to see all specificity to handle colors matrix and > rotation of raw data. > > 3/ The Adobe DNG sdk is too old. Code was not updated since 2012, and Adobe has > released 2 new versions since this date. > I created few weeks ago a new devel branch in git and updated the DNG sdk to > last version, applied fix to compile and tried to use : it crash quickly. So > investiguations are required.... > > Gilles Caulier >
As i alreay explained, i suspect that color matrix use de decode RAW pixels for this Fuji model is not up-to-date. The color matrix is backported from Adobe Raw Converter if i remember. We use the current implementation of libraw. Can you open the FUJI raw file directly in digiKam Image Editor using RAw import tool ? There is no purple side effects ? Gilles Caulier
Created attachment 126945 [details] image editor.png Unfortunately I have reliably purple images, all of the series. To illustrate my settings and the effect, there are 3 screenshots. Maybe I misunderstood though, you talk about opening _directly_ with digikam image editor. I start digikam, get an image into the preview (purple), then click "image editor" (purple). Is there a separate image editor app? Is there any other app that uses that same libraw, with which I could test? Any app that bypasses the possibly outdated color matrix? I just tested with LightZone, there is no problem to open the files. Showfoto 7.0.0-beta3 fails to open the DNGs completely. thanks, Martin On Sun, 2020-03-22 at 13:51 +0000, bugzilla_noreply@kde.org wrote: > https://bugs.kde.org/show_bug.cgi?id=418645 > > --- Comment #16 from caulier.gilles@gmail.com --- > As i alreay explained, i suspect that color matrix use de decode RAW pixels > for this Fuji model is not up-to-date. > > The color matrix is backported from Adobe Raw Converter if i remember. > > We use the current implementation of libraw. Can you open the FUJI raw file > directly in digiKam Image Editor using RAw import tool ? There is no purple > side effects ? > > Gilles Caulier >
Created attachment 126946 [details] raw behaviour.png
Created attachment 126947 [details] raw default settings.png
I don't talk about to load DNG in showfoto, but the RAF original raw file to see if purple side effects appear. Gilles Caulier
loading in showfoto was only a side test. irrelevant. Sorry, I did misunderstand. Yes, the original RAW file will load normally. Only the DNGs will turn out purple. Martin On Sun, 2020-03-22 at 17:48 +0000, bugzilla_noreply@kde.org wrote: > https://bugs.kde.org/show_bug.cgi?id=418645 > > --- Comment #20 from caulier.gilles@gmail.com --- > I don't talk about to load DNG in showfoto, but the RAF original raw file to > see if purple side effects appear. > > Gilles Caulier >
Hi, I don't want to seem pushy or impolite... I wonder if there is any chance of looking at this again? There are about 2700 images I have as "purple" DNGs, for those there are no raw files any more. Yes, I can work around the problem with Rawtherapee, but I rather work within digiKam. Help would be very much appreciated. Martin To make sure there is a test image, here is one again https://my.mail.de/dl/7aa04ecc63ec5cacec7dfa47f521fd1c
Martin, Re-read my comment #16. I checked again with your sample image and the conclusion still the same : libraw do not support yet this kind of DNG file. It will be better to report this problem in libraw bugzilla from github to have a technical feedback from this team. After all if something can be fixed it's in this library. And perhaps the fix already exists, i don't know. Gilles Caulier
It should be mentioned again that Darktable cannot open the files either. Maik
Gilles, thanks for the pointer once again. I will get in touch with libraw people @Maik: I'll point out that Darktable has the same issues. Martin Althoff On Mon, 2020-04-20 at 11:36 +0000, bugzilla_noreply@kde.org wrote: > https://bugs.kde.org/show_bug.cgi?id=418645 > > --- Comment #23 from caulier.gilles@gmail.com --- > Martin, > > Re-read my comment #16. I checked again with your sample image and the > conclusion still the same : libraw do not support yet this kind of DNG file. > > It will be better to report this problem in libraw bugzilla from github to have > a technical feedback from this team. After all if something can be fixed it's > in this library. And perhaps the fix already exists, i don't know. > > Gilles Caulier >
digiKam 7.0.0 stable release is now published: https://www.digikam.org/news/2020-07-19-7.0.0_release_announcement/ We need a fresh feedback on this file using this version. Thanks in advance Gilles Caulier
Git commit efc5d2e6d84e377e3b5a994f97a10e0ce586e61a by Gilles Caulier. Committed on 30/01/2021 at 08:29. Pushed by cgilles into branch 'master'. Update internal Libraw engine to last 0.21.0 Snapshot 202101 with many improvement about DNG support. For more detail see the official announcement: https://www.libraw.org/news/libraw-202101-snapshot Related: bug 431689 M +19 -1 NEWS M +1 -1 core/libs/rawengine/libraw/COPYRIGHT M +154 -25 core/libs/rawengine/libraw/Changelog.txt M +1 -1 core/libs/rawengine/libraw/README.md M +1 -1 core/libs/rawengine/libraw/internal/dcraw_common.cpp M +9 -5 core/libs/rawengine/libraw/internal/dcraw_defs.h M +1 -1 core/libs/rawengine/libraw/internal/dcraw_fileio.cpp M +1 -1 core/libs/rawengine/libraw/internal/dcraw_fileio_defs.h M +2 -1 core/libs/rawengine/libraw/internal/defines.h M +1 -1 core/libs/rawengine/libraw/internal/dmp_include.h M +9 -3 core/libs/rawengine/libraw/internal/libraw_cameraids.h M +1 -1 core/libs/rawengine/libraw/internal/libraw_cxx_defs.h M +276 -269 core/libs/rawengine/libraw/internal/libraw_internal_funcs.h M +150 -149 core/libs/rawengine/libraw/internal/var_defines.h M +1 -1 core/libs/rawengine/libraw/internal/x3f_tools.h M +46 -8 core/libs/rawengine/libraw/libraw/libraw.h M +1 -1 core/libs/rawengine/libraw/libraw/libraw_alloc.h M +111 -51 core/libs/rawengine/libraw/libraw/libraw_const.h M +99 -2 core/libs/rawengine/libraw/libraw/libraw_datastream.h M +4 -4 core/libs/rawengine/libraw/libraw/libraw_internal.h M +185 -92 core/libs/rawengine/libraw/libraw/libraw_types.h M +5 -5 core/libs/rawengine/libraw/libraw/libraw_version.h M +1 -1 core/libs/rawengine/libraw/samples/4channels.cpp M +15 -18 core/libs/rawengine/libraw/samples/dcraw_emu.cpp M +1 -1 core/libs/rawengine/libraw/samples/dcraw_half.c M +1 -1 core/libs/rawengine/libraw/samples/half_mt.c M +1 -1 core/libs/rawengine/libraw/samples/half_mt_win32.c M +1 -1 core/libs/rawengine/libraw/samples/mem_image_sample.cpp M +1 -1 core/libs/rawengine/libraw/samples/multirender_test.cpp M +1 -1 core/libs/rawengine/libraw/samples/openbayer_sample.cpp M +2 -2 core/libs/rawengine/libraw/samples/postprocessing_benchmark.cpp M +528 -1481 core/libs/rawengine/libraw/samples/raw-identify.cpp M +1 -1 core/libs/rawengine/libraw/samples/rawtextdump.cpp M +2 -2 core/libs/rawengine/libraw/samples/simple_dcraw.cpp M +1 -1 core/libs/rawengine/libraw/samples/unprocessed_raw.cpp M +1 -1 core/libs/rawengine/libraw/src/decoders/canon_600.cpp M +674 -377 core/libs/rawengine/libraw/src/decoders/crx.cpp M +25 -41 core/libs/rawengine/libraw/src/decoders/decoders_dcraw.cpp M +8 -9 core/libs/rawengine/libraw/src/decoders/decoders_libraw.cpp M +8 -12 core/libs/rawengine/libraw/src/decoders/decoders_libraw_dcrdefs.cpp M +1 -1 core/libs/rawengine/libraw/src/decoders/dng.cpp M +234 -98 core/libs/rawengine/libraw/src/decoders/fp_dng.cpp M +375 -296 core/libs/rawengine/libraw/src/decoders/fuji_compressed.cpp M +6 -17 core/libs/rawengine/libraw/src/decoders/generic.cpp M +31 -58 core/libs/rawengine/libraw/src/decoders/kodak_decoders.cpp M +1 -1 core/libs/rawengine/libraw/src/decoders/load_mfbacks.cpp M +1 -1 core/libs/rawengine/libraw/src/decoders/smal.cpp M +18 -14 core/libs/rawengine/libraw/src/decoders/unpack.cpp M +21 -16 core/libs/rawengine/libraw/src/decoders/unpack_thumb.cpp M +0 -6 core/libs/rawengine/libraw/src/demosaic/aahd_demosaic.cpp M +1 -1 core/libs/rawengine/libraw/src/demosaic/ahd_demosaic.cpp M +1 -1 core/libs/rawengine/libraw/src/demosaic/misc_demosaic.cpp M +1 -1 core/libs/rawengine/libraw/src/demosaic/xtrans_demosaic.cpp M +21 -16 core/libs/rawengine/libraw/src/integration/dngsdk_glue.cpp M +1 -1 core/libs/rawengine/libraw/src/integration/rawspeed_glue.cpp M +7 -2 core/libs/rawengine/libraw/src/libraw_c_api.cpp M +1 -1 core/libs/rawengine/libraw/src/libraw_cxx.cpp M +342 -4 core/libs/rawengine/libraw/src/libraw_datastream.cpp M +1 -1 core/libs/rawengine/libraw/src/metadata/adobepano.cpp M +155 -125 core/libs/rawengine/libraw/src/metadata/canon.cpp M +5 -6 core/libs/rawengine/libraw/src/metadata/ciff.cpp M +45 -2 core/libs/rawengine/libraw/src/metadata/cr3_parser.cpp M +1 -1 core/libs/rawengine/libraw/src/metadata/epson.cpp M +1 -1 core/libs/rawengine/libraw/src/metadata/exif_gps.cpp M +434 -381 core/libs/rawengine/libraw/src/metadata/fuji.cpp M +82 -35 core/libs/rawengine/libraw/src/metadata/hasselblad_model.cpp M +250 -180 core/libs/rawengine/libraw/src/metadata/identify.cpp M +1 -1 core/libs/rawengine/libraw/src/metadata/identify_tools.cpp M +1 -1 core/libs/rawengine/libraw/src/metadata/kodak.cpp M +69 -52 core/libs/rawengine/libraw/src/metadata/leica.cpp M +71 -186 core/libs/rawengine/libraw/src/metadata/makernotes.cpp M +15 -7 core/libs/rawengine/libraw/src/metadata/mediumformat.cpp M +31 -33 core/libs/rawengine/libraw/src/metadata/minolta.cpp M +5 -3 core/libs/rawengine/libraw/src/metadata/misc_parsers.cpp M +55 -22 core/libs/rawengine/libraw/src/metadata/nikon.cpp M +67 -19 core/libs/rawengine/libraw/src/metadata/normalize_model.cpp M +180 -20 core/libs/rawengine/libraw/src/metadata/olympus.cpp M +32 -30 core/libs/rawengine/libraw/src/metadata/p1.cpp M +139 -14 core/libs/rawengine/libraw/src/metadata/pentax.cpp M +1 -1 core/libs/rawengine/libraw/src/metadata/samsung.cpp M +746 -538 core/libs/rawengine/libraw/src/metadata/sony.cpp M +113 -60 core/libs/rawengine/libraw/src/metadata/tiff.cpp M +1 -1 core/libs/rawengine/libraw/src/postprocessing/aspect_ratio.cpp M +7 -2 core/libs/rawengine/libraw/src/postprocessing/dcraw_process.cpp M +5 -2 core/libs/rawengine/libraw/src/postprocessing/mem_image.cpp M +1 -1 core/libs/rawengine/libraw/src/postprocessing/postprocessing_aux.cpp M +1 -1 core/libs/rawengine/libraw/src/postprocessing/postprocessing_ph.cpp M +1 -1 core/libs/rawengine/libraw/src/postprocessing/postprocessing_utils.cpp M +2 -2 core/libs/rawengine/libraw/src/postprocessing/postprocessing_utils_dcrdefs.cpp M +3 -6 core/libs/rawengine/libraw/src/preprocessing/ext_preprocess.cpp M +1 -1 core/libs/rawengine/libraw/src/preprocessing/preprocessing_ph.cpp M +7 -3 core/libs/rawengine/libraw/src/preprocessing/raw2image.cpp M +2 -2 core/libs/rawengine/libraw/src/preprocessing/subtract_black.cpp M +64 -17 core/libs/rawengine/libraw/src/tables/cameralist.cpp M +1 -1 core/libs/rawengine/libraw/src/tables/colorconst.cpp M +112 -71 core/libs/rawengine/libraw/src/tables/colordata.cpp M +11 -4 core/libs/rawengine/libraw/src/tables/wblists.cpp M +1 -1 core/libs/rawengine/libraw/src/utils/curves.cpp M +10 -5 core/libs/rawengine/libraw/src/utils/decoder_info.cpp M +97 -48 core/libs/rawengine/libraw/src/utils/init_close_utils.cpp M +114 -43 core/libs/rawengine/libraw/src/utils/open.cpp M +2 -2 core/libs/rawengine/libraw/src/utils/phaseone_processing.cpp M +41 -13 core/libs/rawengine/libraw/src/utils/read_utils.cpp M +10 -10 core/libs/rawengine/libraw/src/utils/thumb_utils.cpp M +3 -10 core/libs/rawengine/libraw/src/utils/utils_dcraw.cpp M +7 -1 core/libs/rawengine/libraw/src/utils/utils_libraw.cpp M +1 -1 core/libs/rawengine/libraw/src/write/apply_profile.cpp M +155 -108 core/libs/rawengine/libraw/src/write/file_write.cpp M +9 -2 core/libs/rawengine/libraw/src/write/tiff_writer.cpp M +1 -1 core/libs/rawengine/libraw/src/write/write_ph.cpp M +5 -23 core/libs/rawengine/libraw/src/x3f/x3f_parse_process.cpp M +1 -5 core/libs/rawengine/libraw/src/x3f/x3f_utils_patched.cpp https://invent.kde.org/graphics/digikam/commit/efc5d2e6d84e377e3b5a994f97a10e0ce586e61a
MAik, Another file relevant of DNGSDK 1.5 supports in libraw to process properly modern DNG container. Gilles
Martin, Your shared DNG sample files are not available anymore. Please reshare files with another web service. Gilles Caulier
Git commit 2e4f528a1b5c0fbba8916f3a471b081f912cbf4e by Gilles Caulier. Committed on 11/05/2021 at 03:54. Pushed by cgilles into branch 'master'. Internal DNG SDK 1.15 have been updated to digiKam 7.3.0. Link internal libraw with this DNG SDK to improve DNG decoding images. Related: bug 435085, bug 330920, bug 431689 M +2 -2 core/libs/rawengine/CMakeLists.txt M +3 -1 core/tests/rawengine/CMakeLists.txt https://invent.kde.org/graphics/digikam/commit/2e4f528a1b5c0fbba8916f3a471b081f912cbf4e
I converted this Fuji S3 RAF sample : http://www.rawsamples.ch/raws/fuji/s3pro/RAW_FUJI_S3PRO.RAF ... With Adobe DNG Converter 2021 for MacOS. After upgrating DNS SDK 1.5 and libraw snapshot 20210504, DNG file demosaicing can be processed properly un digiKAm RAW Import tool with purple color side effect : https://i.imgur.com/faCOJHi.png Just take a care to process image with RGB as 4 colors option. Note Preview and thumbnail are shown without purple color. I close this file now. GilleS Caulier