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.
Both systems run -6 -o 1 -g 3.0 12.0 -r 1.0 1.0 2.2 1.0 -T /vol/test.dng but the results are different.
https://www.dropbox.com/scl/fi/axtohrmyfr2g903pxjvbk/small_compare.png?r... This is a screenshot of what the source DNG looks like when my macOS renders it as a file preview test.dng, the result I got with LibRaw locally LOCAL test.dng.tiff, and the result I got with LibRaw running on Digital Ocean Docker container DO test.dng.tiff. As you can see, the one rendered by DO looks off, even though, in general, there are no issues with the DO LibRaw app.
If the original DNG would be helpful, I'll ask its owner and get back. Please let me know!
Is there anything else I should consider?
Here's detailed info about the DNG file:
$ exiftool test.dng
ExifTool Version Number : 13.25
File Name : test.dng
Directory : .
File Size : 109 MB
File Permissions : -rw-r--r--
File Type : DNG
File Type Extension : dng
MIME Type : image/x-adobe-dng
Exif Byte Order : Big-endian (Motorola, MM)
Make : Plustek
Camera Model Name : OpticFilm 8200i
Orientation : Horizontal (normal)
Software : SilverFast 8.8.0 r25 (Jun 25 2021) d6df961 25.06.
Image Width : 4824
Image Height : 3408
Bits Per Sample : 16 16 16
Compression : Uncompressed
Photometric Interpretation : Linear Raw
Samples Per Pixel : 3
Rows Per Strip : 1
X Resolution : 300
Y Resolution : 300
Planar Configuration : Chunky
Resolution Unit : inches
XMP Toolkit : Adobe XMP Core 7.0-c000 1.000000, 0000/00/00-00:00:00
Company : LaserSoft Imaging
Original Scan Frame : <?xml ... VERY LONG STRING ... >
Scan Frames : <?xml ... VERY LONG STRING ... >
Creator Tool : SilverFast 8.8.0 r25 (Jun 25 2021) d6df961 25.06.
Metadata Date : 2025:04:13 08:42:22-07:00
Document ID : E3BB96E86460FD74E93B6EB4A3FA1A53
Original Document ID : E3BB96E86460FD74E93B6EB4A3FA1A53
Instance ID : xmp.iid:06a79b8e-04a5-4b52-a580-95f09cfce4aa
Format : image/dng
Version : 16.5
Process Version : 15.4
White Balance : As Shot
Color Temperature : 6500
Tint : +10
Exposure 2012 : 0.00
Contrast 2012 : 0
Highlights 2012 : 0
Shadows 2012 : 0
Whites 2012 : 0
Blacks 2012 : 0
Texture : 0
Clarity 2012 : 0
Dehaze : 0
Vibrance : 0
Saturation : 0
Parametric Shadows : 0
Parametric Darks : 0
Parametric Lights : 0
Parametric Highlights : 0
Parametric Shadow Split : 25
Parametric Midtone Split : 50
Parametric Highlight Split : 75
Sharpness : 40
Sharpen Radius : +1.0
Sharpen Detail : 25
Sharpen Edge Masking : 0
Luminance Smoothing : 0
Color Noise Reduction : 25
Color Noise Reduction Detail : 50
Color Noise Reduction Smoothness: 50
Hue Adjustment Red : 0
Hue Adjustment Orange : 0
Hue Adjustment Yellow : 0
Hue Adjustment Green : 0
Hue Adjustment Aqua : 0
Hue Adjustment Blue : 0
Hue Adjustment Purple : 0
Hue Adjustment Magenta : 0
Saturation Adjustment Red : 0
Saturation Adjustment Orange : 0
Saturation Adjustment Yellow : 0
Saturation Adjustment Green : 0
Saturation Adjustment Aqua : 0
Saturation Adjustment Blue : 0
Saturation Adjustment Purple : 0
Saturation Adjustment Magenta : 0
Luminance Adjustment Red : 0
Luminance Adjustment Orange : 0
Luminance Adjustment Yellow : 0
Luminance Adjustment Green : 0
Luminance Adjustment Aqua : 0
Luminance Adjustment Blue : 0
Luminance Adjustment Purple : 0
Luminance Adjustment Magenta : 0
Split Toning Shadow Hue : 0
Split Toning Shadow Saturation : 0
Split Toning Highlight Hue : 0
Split Toning Highlight Saturation: 0
Split Toning Balance : 0
Color Grade Midtone Hue : 0
Color Grade Midtone Sat : 0
Color Grade Shadow Lum : 0
Color Grade Midtone Lum : 0
Color Grade Highlight Lum : 0
Color Grade Blending : 50
Color Grade Global Hue : 0
Color Grade Global Sat : 0
Color Grade Global Lum : 0
Auto Lateral CA : 0
Lens Profile Enable : 0
Lens Manual Distortion Amount : 0
Vignette Amount : 0
Defringe Purple Amount : 0
Defringe Purple Hue Lo : 30
Defringe Purple Hue Hi : 70
Defringe Green Amount : 0
Defringe Green Hue Lo : 40
Defringe Green Hue Hi : 60
Perspective Upright : Off
Perspective Vertical : 0
Perspective Horizontal : 0
Perspective Rotate : 0.0
Perspective Aspect : 0
Perspective Scale : 100
Perspective X : 0.00
Perspective Y : 0.00
Grain Amount : 0
Post Crop Vignette Amount : 0
Shadow Tint : 0
Red Hue : 0
Red Saturation : 0
Green Hue : 0
Green Saturation : 0
Blue Hue : 0
Blue Saturation : 0
HDR Edit Mode : 0
Convert To Grayscale : False
Override Look Vignette : False
Tone Curve Name 2012 : Linear
Camera Profile : Embedded
Camera Profile Digest : 553F5A29E2BFD14973038D1977616F6F
Has Settings : True
Has Crop : False
Already Applied : False
History Action : saved
History Instance ID : xmp.iid:06a79b8e-04a5-4b52-a580-95f09cfce4aa
History When : 2025:04:13 08:42:22-07:00
History Software Agent : Adobe Photoshop Camera Raw 16.5 (Macintosh)
History Changed : /metadata
Tone Curve PV2012 : 0, 0, 255, 255
Tone Curve PV2012 Red : 0, 0, 255, 255
Tone Curve PV2012 Green : 0, 0, 255, 255
Tone Curve PV2012 Blue : 0, 0, 255, 255
Point Colors : -1.000000, -1.000000, -1.000000, -1.000000, -1.000000, -1.000000, -1.000000, -1.000000, -1.000000, -1.000000, -1.000000, -1.000000, -1.000000, -1.000000, -1.000000, -1.000000, -1.000000, -1.000000, -1.000000
Exif Version : 0231
Maker Note Unknown Binary : (Binary data 130 bytes, use -b option to extract)
Exif Image Width : 4824
Exif Image Height : 3408
DNG Version : 1.4.0.0
DNG Backward Version : 1.0.0.0
Unique Camera Model : Plustek OpticFilm 8200i
Color Matrix 1 : 3.2404542 -1.5371385 -0.4985314 -0.969266 1.8760108 0.041556 0.0556434 -0.2040259 1.0572252
As Shot White XY : 0.3127 0.329
Maker Note Safety : Unsafe
Raw Data Unique ID : E3BB96E86460FD74E93B6EB4A3FA1A53
Raw Image Digest : 8290177745e2f8f5b8325a732755da1f
Subfile Type : Reduced-resolution image
Strip Offsets : (Binary data 8186 bytes, use -b option to extract)
Strip Byte Counts : (Binary data 5144 bytes, use -b option to extract)
Profile CMM Type : Linotronic
Profile Version : 2.1.0
Profile Class : Input Device Profile
Color Space Data : RGB
Profile Connection Space : XYZ
Profile Date Time : 2021:05:21 16:05:34
Profile File Signature : acsp
Primary Platform : Microsoft Corporation
CMM Flags : Not Embedded, Independent
Device Manufacturer :
Device Model :
Device Attributes : Reflective, Glossy, Positive, Color
Rendering Intent : Perceptual
Connection Space Illuminant : 0.9642 1 0.82491
Profile Creator :
Profile ID : 0
Profile Copyright : Copyright by LaserSoft Imaging AG
Profile Description : SFprofT (OpticFilm 8200i)
Media White Point : 0.96362 1.01057 0.81055
Red Matrix Column : 0.21921 0.08772 0
Green Matrix Column : 0.13847 0.57034 0
Blue Matrix Column : 0.19788 0.01196 0.84502
Red Tone Reproduction Curve : (Binary data 14 bytes, use -b option to extract)
Green Tone Reproduction Curve : (Binary data 14 bytes, use -b option to extract)
Blue Tone Reproduction Curve : (Binary data 14 bytes, use -b option to extract)
A To B0 : (Binary data 217222 bytes, use -b option to extract)
A To B1 : (Binary data 217222 bytes, use -b option to extract)
A To B2 : (Binary data 217222 bytes, use -b option to extract)
Image Size : 4824x3408
Megapixels : 16.4
Preview TIFF : (Binary data 8995734 bytes, use -b option to extract)
Thumbnail TIFF : (Binary data 276696 bytes, use -b option to extract)
My question is not about python script, but how to generate FFT using other GUI tools that are known to provide 100% correct FFT so that i could compare that correct FFT to the one i am getting in python.
However, may I return to my questions (which were about libraw, not Topaz): When will the library be able to cope with NEF files from the Nikon Z50II? That model is not on the list of new cameras, nor formats, which is somewhat worrying, as the Z50II already is a couple of months on the market. Or is this part of NEFX (or does it come along with the support for the Z f)?
Does NEFX-support include the NEF-Format of the Nikon Z50II? Topaz doesn't open its raw files and their support claims that this would be due to libraw not supporting the new format.
Do you have a date already in mind for the release 0.22?
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.
Thank you for your quick response, Alex.
I'm using
librav-0.21.3-r0on both systems. Here's a screenshot of what I gathered (left is my Docker container running on Apple M1 laptop, right is a Docker container running on Digital Ocean instance): https://www.dropbox.com/scl/fi/umk20exovyygzs952ywfi/versions.png?rlkey=...Both systems run
-6 -o 1 -g 3.0 12.0 -r 1.0 1.0 2.2 1.0 -T /vol/test.dngbut the results are different.https://www.dropbox.com/scl/fi/axtohrmyfr2g903pxjvbk/small_compare.png?r... This is a screenshot of what the source DNG looks like when my macOS renders it as a file preview
test.dng, the result I got with LibRaw locallyLOCAL test.dng.tiff, and the result I got with LibRaw running on Digital Ocean Docker containerDO test.dng.tiff. As you can see, the one rendered by DO looks off, even though, in general, there are no issues with the DO LibRaw app.If the original DNG would be helpful, I'll ask its owner and get back. Please let me know!
Is there anything else I should consider?
Here's detailed info about the DNG file:
My question is not about python script, but how to generate FFT using other GUI tools that are known to provide 100% correct FFT so that i could compare that correct FFT to the one i am getting in python.
Please make sure you're using same LibRaw version compiled with same options/compile flags (e.g. DNG SDK support) and with same run-time options
Sorry, we do not provide consulting on Python.
Probably ChatGPT do.
Thanks!
Bests, Mat
The list of supported cameras will be available at the same time as the next release/snapshot. It's too early to talk about it now.
Thanks, again! But honestly, that, too, was not the primary question.
May I try to isolate it: Will the Nikon Z50II be supported in the next release? And if not, when might that be the case?
Regards,
Mat
Thanks for the quick response!
However, may I return to my questions (which were about libraw, not Topaz): When will the library be able to cope with NEF files from the Nikon Z50II? That model is not on the list of new cameras, nor formats, which is somewhat worrying, as the Z50II already is a couple of months on the market. Or is this part of NEFX (or does it come along with the support for the Z f)?
Cheers!
Hi!
Does NEFX-support include the NEF-Format of the Nikon Z50II? Topaz doesn't open its raw files and their support claims that this would be due to libraw not supporting the new format.
Do you have a date already in mind for the release 0.22?
Cheers, Mat
Pages