I made a powershell script to convert all raw files with dcraw-emu and use exiftool to set original capture date and assign camera icc profile to the tiff.
1) Yes, there is no code that adjusts timestamps
2) dcraw's -p camera-profile is not 'assign camera profile', but covert from camera profile to output profile. This option is supported by dcraw_emu if compiled with LCMS support
I found the problem. I forgot to update the libraw header files for my project and it was using the old data structures, causing heap overflow and all sorts of weird problems.
It is all good now.
By the way, I only see 202502 snapshot on Github. Where is 202503? Is the master branch 202503? I downloaded the one from the master branch.
Thank you for your feedback.
1) Downloaded latest master (commit ID: ad067c510bacea51755711c1b624da78b1812fba) and commit just before 202503 snapshot (commit ID: 29d9785c2d5f71db7c6ae2834003cd211bd6a421)
2) Compiled both as make CC=clang CXX=clang -f Makefile.dist on my home FreeBSD router (14.2)
3) Checked with Fuji GFX100 test files from rawdb.dnglab.org: four compressed files and two uncompressed via
0.21 branch (0.21.0....0.21.4) is based on 0.21.0 (released in 2022) and contains bugfixes and stability improvements (like move all allocations from non-initialized malloc to zero-filled calloc).
No new cameras, no new RAW formats, stability-only changes.
Snapshots contains new cameras/new raw formats support, but may be not as stable as 0.21.xx
This is messy crap with different versions of autoconf.
Use an older one or just build via make -f Makefile.dist (you may need to edit Makefile.dist to ajust build option)
Hey thanks for the response. I think I've figured out the issue - libraw-dev version 0.21.3-r0 does not include the 202403 snapshot where the camera the photo was taken on is supported.
I am now trying to install and compile Libraw through master on Github. I'm doing this from an Alpine based docker image, after I clone the repo and run autoreconf --install I get the following errors
#10 22.66 configure.ac:16: error: possibly undefined macro: AC_SUBST
#10 22.66 If this token and others are legitimate, please use m4_pattern_allow.
#10 22.66 See the Autoconf documentation.
#10 22.66 configure.ac:41: error: possibly undefined macro: AC_MSG_WARN
#10 22.67 autoreconf: error: /usr/bin/autoconf failed with exit status: 1
Looks like digikam/LibRaw interaction problem: LibRaw should not release exception out of library, while calling app should not crash on caught exception.
Could you please share the file that results with the problem described?
I'll investigate the problem in depth tomorrow.
At a 1st glance: LibRaw::read_shorts does not work as expected.
It calls libraw_swab() if host byte order does not match file byte order (this is the case: MM/Motorola byte order in file and II/intel byte order on host).
Depending on compile flags, libraw_swab is implemented in two ways:
- own code if LIBRAW_OWN_SWAB defined on compile
- host (libc) swab() function overwise.
Is there any chance to know compile flags used on DO-docker?
Downloaded, thank you (you may remove from Dropbox to not extra distribute the file).
(As expected) the file looks normal regardless of decoding path used (with or without Adobe DNG SDK). Not surprising for uncompressed 16-bit linear (3-channel) DNG: there are very few places where things can go wrong.
Could you please use LibRaw's 4channels sample to check if RAW decoding/unpacking is the same on both platforms. 4channels produces four monochrome tiff files (G.tiff, R.tiff, B.tiff, G2.tiff), one per channel.
G2 should be completely black. Other three should match and provide same checksum on two different systems.
It it is so: the problem is in postprocessing stage (LibRaw::dcraw_process), but first, it's worth making sure.
Sorry, the docker stuff is completely out of our scope.
Could you please compile LibRaw from source on the problematic system and try to reproduce the problem?
Also: it is pointless to discuss some problem with specific raw (dng) file without access to specific file (But if we can't reproduce the problem ourselves, we can't help either).
This is LibRaw (raw processing library) support forum, I don't understand why you are looking for an answer to a question about GUI tool for FFT generation.
I made a powershell script to convert all raw files with dcraw-emu and use exiftool to set original capture date and assign camera icc profile to the tiff.
LibRaw is opensource;
We will be glad to accept your patch that will support the functionality you need.
(using github copy of dcraw.c 1.478 to highlight lines)
-p switch sets cam_profile variable: https://github.com/ncruces/dcraw/blob/master/dcraw.c#L10187
The only code line where this variable is used is apply_profile call: https://github.com/ncruces/dcraw/blob/master/dcraw.c#L10458
The apply_profile function applies the profile, not embed it: https://github.com/ncruces/dcraw/blob/master/dcraw.c#L9651
The -p switch in dcraw was to apply a camera icc profile or embed
Thanks for your reply. But the -z switch to keep capture date was in dcraw. Why is not in libraw anymore. What is the logic behind that?
1) Yes, there is no code that adjusts timestamps
2) dcraw's -p camera-profile is not 'assign camera profile', but covert from camera profile to output profile. This option is supported by dcraw_emu if compiled with LCMS support
Sorry, it is of course 202502, just a mistype
I found the problem. I forgot to update the libraw header files for my project and it was using the old data structures, causing heap overflow and all sorts of weird problems.
It is all good now.
By the way, I only see 202502 snapshot on Github. Where is 202503? Is the master branch 202503? I downloaded the one from the master branch.
Thanks.
Thank you for your feedback.
1) Downloaded latest master (commit ID: ad067c510bacea51755711c1b624da78b1812fba) and commit just before 202503 snapshot (commit ID: 29d9785c2d5f71db7c6ae2834003cd211bd6a421)
2) Compiled both as make CC=clang CXX=clang -f Makefile.dist on my home FreeBSD router (14.2)
3) Checked with Fuji GFX100 test files from rawdb.dnglab.org: four compressed files and two uncompressed via
(to check decode time only)
Results
202403 snapshot (+all patches):
202503 snapshot + two newer changes (PhaseOne checks + CVE numbers):
The new one looks slightly faster (that could be test variation).
So, please check you're using same compile/etc/ mode for both versions (e.g. same OpenMP support: Fuji decoder is OpenMP-capable).
Regarding your 2nd complain:
It is useless to discuss colors/tint/etc without reference to specific RAW file/processing options used.
The result I see from same files set via dcraw_emu -w -T looks absolutely normal: https://www.dropbox.com/scl/fi/46fz50mtg77ddzytccbpa/Fujifilm-GFX100S-14...
That means that system swab() call is broken in this specific environment. A very strange story...
Alex, I'd like to confirm that your suggestion worked and the issue is now fixed.
I used the following flags in my Docker container:
With code tagged 0.21.4 found in the GitHub repo, compiled with
make install.Thank you!
LibRaw-cmake is separate project, not supported by LibRaw team (although still linked to LibRaw account on github)
Please ask your question via issues here: https://github.com/LibRaw/LibRaw-cmake
0.21 branch (0.21.0....0.21.4) is based on 0.21.0 (released in 2022) and contains bugfixes and stability improvements (like move all allocations from non-initialized malloc to zero-filled calloc).
No new cameras, no new RAW formats, stability-only changes.
Snapshots contains new cameras/new raw formats support, but may be not as stable as 0.21.xx
This is explained in details in the update policy section on this site frontpage: https://www.libraw.org/#updatepolicy
This is messy crap with different versions of autoconf.
Use an older one or just build via make -f Makefile.dist (you may need to edit Makefile.dist to ajust build option)
Thank you for looking into this for me, Alex! I will test and get back.
Hey thanks for the response. I think I've figured out the issue - libraw-dev version 0.21.3-r0 does not include the 202403 snapshot where the camera the photo was taken on is supported.
I am now trying to install and compile Libraw through master on Github. I'm doing this from an Alpine based docker image, after I clone the repo and run autoreconf --install I get the following errors
#10 22.66 configure.ac:16: error: possibly undefined macro: AC_SUBST
#10 22.66 If this token and others are legitimate, please use m4_pattern_allow.
#10 22.66 See the Autoconf documentation.
#10 22.66 configure.ac:41: error: possibly undefined macro: AC_MSG_WARN
#10 22.67 autoreconf: error: /usr/bin/autoconf failed with exit status: 1
Am I missing something, I'm following the installation from this guide here
https://www.libraw.org/docs/Install-LibRaw-eng.html
Checked with LIBRAW_OWN_SWAB defined (so, own LibRaw swab used): looks OK.
So the only suspect for now: host (libc) swab() function
Recompilation with LIBRAW_OWN_SWAB should solve the issue.
Looks like digikam/LibRaw interaction problem: LibRaw should not release exception out of library, while calling app should not crash on caught exception.
Could you please share the file that results with the problem described?
It's hard to discuss anything without examples of problematic files on hands, please share (use any file sharing service and post link here)
OK, thanks.
Looks like byte order swapped in REMOTE sample.
I'll investigate the problem in depth tomorrow.
At a 1st glance: LibRaw::read_shorts does not work as expected.
It calls libraw_swab() if host byte order does not match file byte order (this is the case: MM/Motorola byte order in file and II/intel byte order on host).
Depending on compile flags, libraw_swab is implemented in two ways:
- own code if LIBRAW_OWN_SWAB defined on compile
- host (libc) swab() function overwise.
Is there any chance to know compile flags used on DO-docker?
I used the 4chennels tool that comes with the APK package for both containers. The results look quite different!
https://www.dropbox.com/scl/fo/ndnfk0xg4r56l6k1you97/AHeaZGEZ9_0Oq4RWZJE...
Folder prefixed with LOCAL had its results made on my machine, and REMOTE was made on Digital Ocean.
Downloaded, thank you (you may remove from Dropbox to not extra distribute the file).
(As expected) the file looks normal regardless of decoding path used (with or without Adobe DNG SDK). Not surprising for uncompressed 16-bit linear (3-channel) DNG: there are very few places where things can go wrong.
Could you please use LibRaw's 4channels sample to check if RAW decoding/unpacking is the same on both platforms. 4channels produces four monochrome tiff files (G.tiff, R.tiff, B.tiff, G2.tiff), one per channel.
G2 should be completely black. Other three should match and provide same checksum on two different systems.
It it is so: the problem is in postprocessing stage (LibRaw::dcraw_process), but first, it's worth making sure.
Got the permission from the image author to share here: https://www.dropbox.com/scl/fo/ndnfk0xg4r56l6k1you97/AHeaZGEZ9_0Oq4RWZJE...
The file is pretty large, it's named
test.dng.Sorry, the docker stuff is completely out of our scope.
Could you please compile LibRaw from source on the problematic system and try to reproduce the problem?
Also: it is pointless to discuss some problem with specific raw (dng) file without access to specific file (But if we can't reproduce the problem ourselves, we can't help either).
This is LibRaw (raw processing library) support forum, I don't understand why you are looking for an answer to a question about GUI tool for FFT generation.
Pages