We cannot provide support for components from other vendors. For all questions related to dng sdk please contact Adobe support.
As an exception for the rule above: to create Adobe DNG SDK library (shared or static) just create corresponding build target (static or shared library) in your build environment (MS VS, XCode, whatever...) with all Adobe DNG SDK sources excluding source/dng_validate.cpp
This saves on step. I was already fiddling with the imgdata.thumbnail.
I now need to figure out how to decode the JXL data into something my software can use. Looking at the JXL official library at the moment...
You got hit by 'automated maximum adjustment' code implemented in LibRaw's postprocessing many years ago to avoid 'pink clouds' problem: real data range is not present in RAW metadata while real data maximum is lower than format maximum.
To turn the feature off: use
imgdata.params.adjust_maximum_thr = 0;
(corresponding dcraw_emu command line switch: -c 0)
It is hard to discuss something without having files in question on hands.
Probably: your Sony (!) images are shot in Small/Medium (pseudo)RAW mode. This is YCC files (similar to lossless JPEGs), already processed and white balanced in camera.
Thanks for fixing that link. Source files and libraries are fine. However the /bin subfolder, normally containing executables such as dcraw_emu, is empty in LibRaw-0.21.3-macOS.zip aside from the .keep_me file.
So I could just pull the repository into a clean directory and run a fresh compile of libraw from master using your suggested simpler way to compile, which avoids configure before make.
make -f Makefile.dist
The created binary of static libraw.a is now usable and can be linked with no unresolved symbols from both master branch and also version 0.21.
My finding is:
The suggested way to compile the binaries using 'autoreconf --install' and 'configure' messed up the source repository and build pipeline specifically on our macos environment. For some unknown reason this ended up in an unusable binary of the static libraw library that could not be linked due to 'undefined symbols'.
I should add, that autoreconf/configure requires installation of additional tools using homebrew package manager on Mac, namely autoconf, automake and pkg-config, that are not part of the standard Apple development environment XCode. Seems these tools messed up detection of the proper C/C++ make configuration on mac platform which led to incompatibilities linking two different libraries (undefined symbols).
I rolled back to plain Apple XCode C/C++ development tools, and uninstalled autoconf & Co, before I tried a fresh install of libraw. That said, autoreconf/configure is not possible by using XCode only on Mac plaform.
Apologies, but I didn't dig deeper in analysis what exactly fails using autoreconf/configure on mac, thus cannot provide insights what could be improved for libraw to be installed the suggested way on macos Sonoma.
Avoiding the suggested installation to run autoreconf/configure to compile libraw static binary on mac Sonoma platform is the solution in my case.
lexa@macair ~ % mkdir test
lexa@macair ~ % cd test
lexa@macair test % git clone https://github.com/LibRaw/LibRaw.git
Cloning into 'LibRaw'...
remote: Enumerating objects: 18973, done.
remote: Counting objects: 100% (1280/1280), done.
remote: Compressing objects: 100% (527/527), done.
remote: Total 18973 (delta 884), reused 1065 (delta 751), pack-reused 17693 (from 1)
Receiving objects: 100% (18973/18973), 13.78 MiB | 21.22 MiB/s, done.
Resolving deltas: 100% (14748/14748), done.
lexa@macair test %
Also, I do not think that LibRaw will even build if git transaction is incomplete, assuming you're starting from scratch with empty folder. If the folder was not empty, it probably contains some previous version.
As you suggested before, I tried building libraw using 'make -f Makefile.dist'. The result is different, but also ended up with 'undefined symbols' on certain methods that cannot be resolved while linking the library.
I tried to pull the repository from scratch in a new directory. This ended with persistent errors indicating the repo cannot be pulled completely without errors. I tried for a couple of hours, but found the specific error permanent. Maybe it's related to my problems.
MacBook-Pro:git user$ git clone https://github.com/LibRaw/LibRaw.git
Cloning into 'LibRaw'...
remote: Enumerating objects: 18973, done.
remote: Counting objects: 100% (1280/1280), done.
remote: Compressing objects: 100% (527/527), done.
error: RPC failed; curl 92 HTTP/2 stream 5 was not closed cleanly: CANCEL (err 8)
error: 3496 bytes of body are still expected
fetch-pack: unexpected disconnect while reading sideband packet
fatal: early EOF
fatal: fetch-pack: invalid index-pack output
The _libraw_open_file is from LibRaw C API
The __ZN6LibRaw9open_fileEPKc is C++ name mangled LibRaw::open_file(char const*), you may use nm with -C option to see the demangled name.
So we are closer to the root cause. Listing all symbols nm and trying to find 'open_file' via grep reports a different signature for class LibRaw 'LibRaw::open_file', than the wrapper library and linker expects.
The linker expected a symbol 'LibRaw::open_file', while the compiled binary of the static library libraw.a has a different signature. Obviously, 'configure' might create confusion about the tools and proper options detected to compile and link the binaries for libraw, which will result in a completely different signature of the C++ class method. I need to see, what the specific root cause for macos will be in this case.
MacBook-Pro:LibRaw user$ nm -a lib/libraw.a | grep open_file
U __ZN6LibRaw9open_fileEPKc
0000000000000110 T _libraw_open_file
lib/libraw.a:x3f_parse_process.o: no symbols
lib/libraw.a:x3f_utils_patched.o: no symbols
0000000000000070 T __ZN6LibRaw9open_fileEPKc
I recommend removing all library instances from everywhere and starting from scratch to make sure there is ONE instance of the library binary in single preferred format (static one, I think) you are linking to, not several different ones in different folders.
I checked the contents of libraw.a using nm. In fact, nm did not list any symbols, but errors of missing "dynamic symbol tables". That's why...
nm -D lib/libraw.a
libraw_c_api.o:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm: error: libraw_c_api.o: File format has no dynamic symbol table
libraw_datastream.o:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm: error: libraw_datastream.o: File format has no dynamic symbol table
...
So there must be something wrong with the automated configure and build.
We cannot provide support for components from other vendors. For all questions related to dng sdk please contact Adobe support.
As an exception for the rule above: to create Adobe DNG SDK library (shared or static) just create corresponding build target (static or shared library) in your build environment (MS VS, XCode, whatever...) with all Adobe DNG SDK sources excluding source/dng_validate.cpp
Thanks, Alex!
This saves on step. I was already fiddling with the
imgdata.thumbnail.I now need to figure out how to decode the JXL data into something my software can use. Looking at the JXL official library at the moment...
We managed to support JPEG-XL and Canon H265 previews in dcraw_make_mem_thumb via this patch/commit: https://github.com/LibRaw/LibRaw/commit/cc118c1c1869e2559dbd0c7639d21915...
Unpacked JPEG XL thumbnail is available via imgdata.thumbnail (and .thumbs_list)
We'll improve dcraw_make_mem_thumb() to handle it too, although this is just another buffer allocation and as-is data copy for JPEG-XL case
That was it: I set adjust_maximum_thr = 0 and now my captures are consistent. Thanks very much!
You got hit by 'automated maximum adjustment' code implemented in LibRaw's postprocessing many years ago to avoid 'pink clouds' problem: real data range is not present in RAW metadata while real data maximum is lower than format maximum.
To turn the feature off: use
imgdata.params.adjust_maximum_thr = 0;
(corresponding dcraw_emu command line switch: -c 0)
Here are your 0018 file processed via:
dcraw_emu -w -T and dcraw_emu -w -c 0 -T respectively
https://www.dropbox.com/scl/fo/8bgts0j5m5aa8007czqkf/AC8-URS3v42QVYOD_wk...
It is hard to discuss something without having files in question on hands.
Probably: your Sony (!) images are shot in Small/Medium (pseudo)RAW mode. This is YCC files (similar to lossless JPEGs), already processed and white balanced in camera.
...didn't get attached. Here it is: https://www.dropbox.com/scl/fi/b1vbngjqyp3837jq0hh8v/LibRaw0.21.3Exposur...
All looks good now, thanks very much!
rebuilded, reuploaded, downloaded to another computer: should work now
Thanks for fixing that link. Source files and libraries are fine. However the /bin subfolder, normally containing executables such as dcraw_emu, is empty in LibRaw-0.21.3-macOS.zip aside from the .keep_me file.
Best Regards,
AJW
It is disclosed on this site 1st page: https://www.libraw.org/#updatepolicy
Thank you for your feedback
Fixed
Glad to hear that our advice to start over from scratch and not use development tools that you don't understand what they do helped you.
Good morning, Alex.
github problems healed overnight.
So I could just pull the repository into a clean directory and run a fresh compile of libraw from master using your suggested simpler way to compile, which avoids configure before make.
The created binary of static libraw.a is now usable and can be linked with no unresolved symbols from both master branch and also version 0.21.
My finding is:
The suggested way to compile the binaries using 'autoreconf --install' and 'configure' messed up the source repository and build pipeline specifically on our macos environment. For some unknown reason this ended up in an unusable binary of the static libraw library that could not be linked due to 'undefined symbols'.
I should add, that autoreconf/configure requires installation of additional tools using homebrew package manager on Mac, namely autoconf, automake and pkg-config, that are not part of the standard Apple development environment XCode. Seems these tools messed up detection of the proper C/C++ make configuration on mac platform which led to incompatibilities linking two different libraries (undefined symbols).
I rolled back to plain Apple XCode C/C++ development tools, and uninstalled autoconf & Co, before I tried a fresh install of libraw. That said, autoreconf/configure is not possible by using XCode only on Mac plaform.
Apologies, but I didn't dig deeper in analysis what exactly fails using autoreconf/configure on mac, thus cannot provide insights what could be improved for libraw to be installed the suggested way on macos Sonoma.
Avoiding the suggested installation to run autoreconf/configure to compile libraw static binary on mac Sonoma platform is the solution in my case.
Thanks again for your help.
Thilo
And, as expected, LibRaw/master, fetched from github, builds via make -f Makefile.dist as expected, samples are linked fine, no unresolved symbols.
I do not see any problems with github:
Also, I do not think that LibRaw will even build if git transaction is incomplete, assuming you're starting from scratch with empty folder. If the folder was not empty, it probably contains some previous version.
$ date
Fri 25 Oct 2024 08:27:58 PM EDT
$ git clone https://github.com/LibRaw/LibRaw.git
Cloning into 'LibRaw'...
remote: Enumerating objects: 18973, done.
remote: Counting objects: 100% (1280/1280), done.
remote: Compressing objects: 100% (470/470), done.
remote: Total 18973 (delta 887), reused 1110 (delta 808), pack-reused 17693 (from 1)
Receiving objects: 100% (18973/18973), 13.82 MiB | 52.21 MiB/s, done.
Resolving deltas: 100% (14751/14751), done.
$ date
Fri 25 Oct 2024 08:28:10 PM EDT
$
As you suggested before, I tried building libraw using 'make -f Makefile.dist'. The result is different, but also ended up with 'undefined symbols' on certain methods that cannot be resolved while linking the library.
I tried to pull the repository from scratch in a new directory. This ended with persistent errors indicating the repo cannot be pulled completely without errors. I tried for a couple of hours, but found the specific error permanent. Maybe it's related to my problems.
The _libraw_open_file is from LibRaw C API
The __ZN6LibRaw9open_fileEPKc is C++ name mangled LibRaw::open_file(char const*), you may use nm with -C option to see the demangled name.
So we are closer to the root cause. Listing all symbols nm and trying to find 'open_file' via grep reports a different signature for class LibRaw 'LibRaw::open_file', than the wrapper library and linker expects.
The linker expected a symbol 'LibRaw::open_file', while the compiled binary of the static library libraw.a has a different signature. Obviously, 'configure' might create confusion about the tools and proper options detected to compile and link the binaries for libraw, which will result in a completely different signature of the C++ class method. I need to see, what the specific root cause for macos will be in this case.
MacBook-Pro:LibRaw user$ nm -a lib/libraw.a | grep open_file U __ZN6LibRaw9open_fileEPKc 0000000000000110 T _libraw_open_file lib/libraw.a:x3f_parse_process.o: no symbols lib/libraw.a:x3f_utils_patched.o: no symbols 0000000000000070 T __ZN6LibRaw9open_fileEPKcI would also be interested to know why the examples from the library link successfully (as far as I understood from your answer)
My recommendation to use the SAME options for linking as in the examples remains in force.
please try to use nm without the -D option
Also your previous reply ( https://www.libraw.org/comment/6846#comment-6846 ) lists both .a and .dylib files in /usr/local/lib while you're refering ./lib folder in your last reply.
I recommend removing all library instances from everywhere and starting from scratch to make sure there is ONE instance of the library binary in single preferred format (static one, I think) you are linking to, not several different ones in different folders.
I checked the contents of libraw.a using nm. In fact, nm did not list any symbols, but errors of missing "dynamic symbol tables". That's why...
So there must be something wrong with the automated configure and build.
Pages