Version mismatch (shared lib/application) will result in the same problem that you already received, but it may be on the user side if you distribute your application.
Therefore, the supplied makefiles do not create shared libraries: we don't want to spend even more time on support if you have problems similar to the one you're experiencing.
In any case, I am sure that creating shared libraries is not a difficult task for a developer with minimal experience.
Thanks Alex, you were right i had the wrong header, seems like some how i was still using the old version! silly me! i noticed the build system is only building the libraw as static, is it possible to build it as shared somehow?
the red color is pale my question is how am i gonna get the one you shared by calling the libraw c++ api methods because calling dcraw_process() and make_mem_image() even by setting the gamm[0] and gamm[1] does not give me true colors i think in the demosaicing and color rendering i have to do something to get to these colors: https://www.dropbox.com/scl/fi/tens8j8oks2ozwchh1otp/Screenshot-2025-11-...
if you check these two links they have different shade of red , the thing is this happens for the raf images that have
rawProcessor.imgdata.color.cam_xyz
this parameter as null or empty.
decode(const std::string &path) {
LibRaw rawProcessor;
int ret = rawProcessor.open_file(path.c_str());
if (ret != LIBRAW_SUCCESS) {
throw FileLoadException("Cannot open RAW file: " + path);
}
// --- Processing parameters ---
rawProcessor.imgdata.params.use_auto_wb = 0;
rawProcessor.imgdata.params.use_camera_wb = 1;
rawProcessor.imgdata.params.use_camera_matrix = 3;
rawProcessor.imgdata.params.output_bps = 16;
rawProcessor.imgdata.params.exp_correc = 0;
rawProcessor.imgdata.params.med_passes = 1;
rawProcessor.imgdata.params.fbdd_noiserd = 1;
rawProcessor.imgdata.params.four_color_rgb = 1;
rawProcessor.imgdata.params.user_qual = 4;
rawProcessor.imgdata.params.use_fuji_rotate = 1;
rawProcessor.imgdata.params.dcb_iterations = 1;
rawProcessor.imgdata.params.dcb_enhance_fl = 1;
rawProcessor.imgdata.params.no_interpolation = 0;
rawProcessor.imgdata.params.output_color = 1;
rawProcessor.imgdata.params.no_auto_bright = 1;
ret = rawProcessor.unpack();
if (ret != LIBRAW_SUCCESS) {
throw Exception("Failed to unpack RAW file: " + path);
}
// --- Process the RAW data ---
ret = rawProcessor.dcraw_process();
if (ret != LIBRAW_SUCCESS) {
throw EXCEPTION();
}
libraw_processed_image_t *procImage = rawProcessor.dcraw_make_mem_image(&ret);
if (!procImage || !procImage->data) {
if (procImage) LibRaw::dcraw_clear_mem(procImage);
rawProcessor.recycle();
throw Exception("Failed to get processed image memory");
}
//return processed image data
}
the above code is how i get the attached look and color i think somehow in the demosaicing part the colors do not render as they should! and that's when the "rawProcessor.imgdata.color.cam_xyz" is empty or all zeros what i understood is even if i populate that base on the colordata.c info nothing changes for the end result. what am i missing to get to the look and color you shared in the link? thanks.
Hello again Alex , these logs might help with the situation this happens for the RAF files that have this
matrices as so! but i see that in the source there is this line in the colordata.cpp
{ LIBRAW_CAMERAMAKER_Fujifilm, "X-T5", 0, 0, // same CMs: X-T5 and X-T50
{ 11809,-5358,-1141,-4248,12164,2343,-514,1097,5848 } },
i am on this commit : HEAD is now at 3733457d imported 0.22-PreRC1
also what is the relation between cam_xyz and rgb_cam? can we populate the rgb_cam from cam_xyz? i am asking does the data from colordata.cpp is the cam_xyz?
{ LIBRAW_CAMERAMAKER_Fujifilm, "X-T5", 0, 0, // same CMs: X-T5 and X-T50
{ 11809,-5358,-1141,-4248,12164,2343,-514,1097,5848 } },
how does libraw knows what color_xyz shall be used ?
i tried to set use_camera_matrix with different values from 0 - 3 always same colors! so i might need some help here cause i got really confused . thanks.
This is the color i get!
i am not calling dcraw_emu() directly! i am using c++ api of libraw but the thing for other raf files the colors render correct except this image!
And my libraw::capabilities is as so: LibRaw capabilities bitmask: 0xC0
here is what i get https://www.dropbox.com/scl/fi/ieqfn6st54d0f2iul7s2k/wrong-color.png?rlk...
Hello i noticed a weird situation with libraw recently i found this raw file which renders with pale and desaturated red color! a different shade of color for other fuji Raf files i have not noticed such thing also tried different params yet always returned the same weird red color the thing is i test the same image with almost many many image processing software from rawtherapee to lightroom even rapid raw and raproc they all rendered the image as the jpeg colors except when used libraw with different setting and params we got the same pale here is the link to the image, i shall say i tested both the master branch and even 0.21.4 ! https://johnricardstock.photoshelter.com/dnld-hires/DSCF5078.RAF?dl_id=A...|e
Hello,
I noticed that version 0.21.0 was released on December 26, 2022.
According to the update policy, major releases usually come out every 1.5 to 3 years.
Does this mean that version 0.22.0 is expected to be released sometime in 2025?
Is there already a planned release schedule or roadmap that you could share?
Oh... Can't believe I didn't think of that. Exported a TIFF first try with /usr/src/app/libraw/bin/dcraw_emu -dngsdk -T -Z out.tiff /usr/src/app/testfiles/unreadable.dng.
I don't see the dng_host object in here. That's all that is required to allow unpacking these DNGs right? I'm already compiling against the working libraw and ImageMagick has other DNG reading code, but is just missing the dng_host for the Adobe DNG SDK?
Thank you very much for the incredibly fast response though!
As mentioned in the README.DNGSDK.txt file in the LibRaw distribution:
In your application
* create dng_host object (or derived object, e.g. with multithreaded) entity in your program;
* pass it to LibRaw via LibRaw::set_dng_host(dng_host *) call to enable DNG SDK use on runtime
mem_image sample does not have this pieces of code, so please test with dcraw_emu -dngsdk
I am pretty sure that there are plenty of people expecting support for cameras not listed as supported - I am asking a slightly different question. I notice Nikon Z50 is supported and works, but Z50II is neither listed not works. Clearly thet images are different with respect to thumbnails. What can I as a z50II user do to help/assist with adding support for this model?
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.
Version mismatch (shared lib/application) will result in the same problem that you already received, but it may be on the user side if you distribute your application.
Therefore, the supplied makefiles do not create shared libraries: we don't want to spend even more time on support if you have problems similar to the one you're experiencing.
In any case, I am sure that creating shared libraries is not a difficult task for a developer with minimal experience.
Thanks Alex, you were right i had the wrong header, seems like some how i was still using the old version! silly me! i noticed the build system is only building the libraw as static, is it possible to build it as shared somehow?
Please make sure that the header files you use when building your application match the version of the library you are using.
Also: rawProcessor.imgdata.color.cam_xyz can never be null because this is pre-allocated array in imgdata.color
Yes the problem is you see when i shared my photo
this one: https://www.dropbox.com/scl/fi/ieqfn6st54d0f2iul7s2k/wrong-color.png?rlk...
the red color is pale my question is how am i gonna get the one you shared by calling the libraw c++ api methods because calling dcraw_process() and make_mem_image() even by setting the gamm[0] and gamm[1] does not give me true colors i think in the demosaicing and color rendering i have to do something to get to these colors:
https://www.dropbox.com/scl/fi/tens8j8oks2ozwchh1otp/Screenshot-2025-11-...
if you check these two links they have different shade of red , the thing is this happens for the raf images that have
this parameter as null or empty.
decode(const std::string &path) { LibRaw rawProcessor; int ret = rawProcessor.open_file(path.c_str()); if (ret != LIBRAW_SUCCESS) { throw FileLoadException("Cannot open RAW file: " + path); } // --- Processing parameters --- rawProcessor.imgdata.params.use_auto_wb = 0; rawProcessor.imgdata.params.use_camera_wb = 1; rawProcessor.imgdata.params.use_camera_matrix = 3; rawProcessor.imgdata.params.output_bps = 16; rawProcessor.imgdata.params.exp_correc = 0; rawProcessor.imgdata.params.med_passes = 1; rawProcessor.imgdata.params.fbdd_noiserd = 1; rawProcessor.imgdata.params.four_color_rgb = 1; rawProcessor.imgdata.params.user_qual = 4; rawProcessor.imgdata.params.use_fuji_rotate = 1; rawProcessor.imgdata.params.dcb_iterations = 1; rawProcessor.imgdata.params.dcb_enhance_fl = 1; rawProcessor.imgdata.params.no_interpolation = 0; rawProcessor.imgdata.params.output_color = 1; rawProcessor.imgdata.params.no_auto_bright = 1; ret = rawProcessor.unpack(); if (ret != LIBRAW_SUCCESS) { throw Exception("Failed to unpack RAW file: " + path); } // --- Process the RAW data --- ret = rawProcessor.dcraw_process(); if (ret != LIBRAW_SUCCESS) { throw EXCEPTION(); } libraw_processed_image_t *procImage = rawProcessor.dcraw_make_mem_image(&ret); if (!procImage || !procImage->data) { if (procImage) LibRaw::dcraw_clear_mem(procImage); rawProcessor.recycle(); throw Exception("Failed to get processed image memory"); } //return processed image data }the above code is how i get the attached look and color i think somehow in the demosaicing part the colors do not render as they should! and that's when the "rawProcessor.imgdata.color.cam_xyz" is empty or all zeros what i understood is even if i populate that base on the colordata.c info nothing changes for the end result. what am i missing to get to the look and color you shared in the link? thanks.
raw-identify -v DSCF5078.RAF (0.22-PreRC1) results in:
Camera2RGB matrix (mode: 1):
1.2560 -0.0421 -0.2139
-0.1496 1.5498 -0.4001
0.0046 -0.3618 1.3572
XYZ->CamRGB matrix:
1.1809 -0.5358 -0.1141
-0.4248 1.2164 0.2343
-0.0514 0.1097 0.5848
The 1st one is rgb_cam, the second one is cam_xyz
BTW, have you checked that red colors you expected are in-gamut for sRGB?
Hello again Alex , these logs might help with the situation this happens for the RAF files that have this
matrices as so! but i see that in the source there is this line in the colordata.cpp
{ LIBRAW_CAMERAMAKER_Fujifilm, "X-T5", 0, 0, // same CMs: X-T5 and X-T50 { 11809,-5358,-1141,-4248,12164,2343,-514,1097,5848 } },i am on this commit : HEAD is now at 3733457d imported 0.22-PreRC1
also what is the relation between cam_xyz and rgb_cam? can we populate the rgb_cam from cam_xyz? i am asking does the data from colordata.cpp is the cam_xyz?
{ LIBRAW_CAMERAMAKER_Fujifilm, "X-T5", 0, 0, // same CMs: X-T5 and X-T50 { 11809,-5358,-1141,-4248,12164,2343,-514,1097,5848 } },how does libraw knows what color_xyz shall be used ?
i tried to set use_camera_matrix with different values from 0 - 3 always same colors! so i might need some help here cause i got really confused . thanks.
This is the color i get!
i am not calling dcraw_emu() directly! i am using c++ api of libraw but the thing for other raf files the colors render correct except this image!
And my libraw::capabilities is as so: LibRaw capabilities bitmask: 0xC0
here is what i get
https://www.dropbox.com/scl/fi/ieqfn6st54d0f2iul7s2k/wrong-color.png?rlk...
Here is screenshot of
- On the left: tiff file created by dcraw_emu -T -w file (LibRaw/master from github)
- On the right: JPEG preview from the file (simple_dcraw -e filename)
https://www.dropbox.com/scl/fi/tens8j8oks2ozwchh1otp/Screenshot-2025-11-...
What's wrong with this pair of images?
Hello i noticed a weird situation with libraw recently i found this raw file which renders with pale and desaturated red color! a different shade of color for other fuji Raf files i have not noticed such thing also tried different params yet always returned the same weird red color the thing is i test the same image with almost many many image processing software from rawtherapee to lightroom even rapid raw and raproc they all rendered the image as the jpeg colors except when used libraw with different setting and params we got the same pale here is the link to the image, i shall say i tested both the master branch and even 0.21.4 !
https://johnricardstock.photoshelter.com/dnld-hires/DSCF5078.RAF?dl_id=A...|e
New Samsung v3 decoder is available in LibRaw 0.22-preRC1: https://www.libraw.org/news/libraw-022-prerc1
Thank you again for samples provided!
LIBRAW_OWN_SWAB is now default for non-Windows/non-Mac platforms (on Windows and Mac swab on same input/output buffer is known to work OK).
LibRaw 0.22-preRC1 is available on our Github: https://www.libraw.org/news/libraw-022-prerc1
I'm using this bash script to build a universal dylib library which can be dropped into Xcode.
https://gist.github.com/chrismacke/c123a6c25c211932099628d0504e5808
Thank you for this thread, it helped me diagnose the issue with corrupted output files.
According to the Alpine maintainers, passing overlapping src and dst to swab() call is undefined behavior: https://www.man7.org/linux/man-pages/man3/swab.3p.html
Thank you for the samples provided.
We'll consider adding Samsung lossy compression support into some version of public LibRaw.
Hello,
I noticed that version 0.21.0 was released on December 26, 2022.
According to the update policy, major releases usually come out every 1.5 to 3 years.
Does this mean that version 0.22.0 is expected to be released sometime in 2025?
Is there already a planned release schedule or roadmap that you could share?
Thanks a lot!
All good, thanks for the help!
Sorry, know nothing about ImageMagick internals.
Oh... Can't believe I didn't think of that. Exported a TIFF first try with
/usr/src/app/libraw/bin/dcraw_emu -dngsdk -T -Z out.tiff /usr/src/app/testfiles/unreadable.dng.I'm assuming then that the reason it didn't actually work in ImageMagick is because their DNG code is missing support for it? https://github.com/ImageMagick/ImageMagick/blob/main/coders/dng.c
I don't see the dng_host object in here. That's all that is required to allow unpacking these DNGs right? I'm already compiling against the working libraw and ImageMagick has other DNG reading code, but is just missing the dng_host for the Adobe DNG SDK?
Thank you very much for the incredibly fast response though!
As mentioned in the README.DNGSDK.txt file in the LibRaw distribution:
mem_image sample does not have this pieces of code, so please test with dcraw_emu -dngsdk
I got a proper photo from my phone that I added to the repository now and set it as the default file to be tested with the script.
Please check out all the formats / crops with our RawDigger Beta:
https://www.rawdigger.com/news/rawdigger-1-4-10-beta
I am pretty sure that there are plenty of people expecting support for cameras not listed as supported - I am asking a slightly different question. I notice Nikon Z50 is supported and works, but Z50II is neither listed not works. Clearly thet images are different with respect to thumbnails. What can I as a z50II user do to help/assist with adding support for this model?
Does this lead to any incorrect consequences?
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.
Pages