In fact, the only difference is errcnt variable is declared openmp-shared (it is atomically changed if error catched, so the difference should be neglible).
I can only recommend performing detailed profiling of both versions and comparing where exactly you're experiencing performance degradation at the individual operator level.
Since I don't see any performance differences on our end, there's nothing to look for there.
Mia Culpa! Your response prompted me to look into this again so I checked my Libraw 0.22 compile flags and found the Libraw VS project did not have the /OPENMP flag set for Debug mode. This accounted for the big performance difference (on a 16 core machine).
Additionally, the LibRaw library offers some basic RAW conversion, intended for cases when such conversion is not the main function of the LibRaw-using application (for example: a viewer for 500+ graphic file formats, including RAW). These methods are inherited from the Dave Coffin’s dcraw.c utility (see below the “Project history” section); their further development is not currently planned, because we do not consider production-quality rendering to be in the scope of LibRaw’s functionality (the methods are retained for compatibility with prior versions and for rapid-fire testing of RAW support and other aspects).
In short: while such a feature might be interesting, it is outside the scope of the library.
There is no such program in LibRaw, this is RAW files reader. It's not very difficult to make it by combining LibRaw (for reading) and Adobe DNG SDK (for DNG creation).
But it's probably easier to file a bug to RawRefinery authors, instead of guessing what exactly their software doesn't like
I was waiting for 0.22 release expecting that my issue will also be resolved by this fix, but it is not. However, I see that original file from Garfield is now works fine, but this file from Samsung still does not. The error is "unpack failed". Can you please check what is wrong with this file?
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?
Great to know that the problem has been resolved
For the files you provide and openmp enabled the difference is neglible:
Also, diff in src/decoders/fuji_compressed.cpp is very small (it changes error handling in openmp case):
diff --git a/src/decoders/fuji_compressed.cpp b/src/decoders/fuji_compressed.cpp index acea0825..40d92d78 100644 --- a/src/decoders/fuji_compressed.cpp +++ b/src/decoders/fuji_compressed.cpp @@ -229,9 +229,9 @@ static inline void fuji_fill_buffer(fuji_compressed_block *info) { if (info->cur_pos >= info->cur_buf_size) { + bool needthrow = false; info->cur_pos = 0; info->cur_buf_offset += info->cur_buf_size; - bool needthrow = false; #ifdef LIBRAW_USE_OPENMP #pragma omp critical #endif @@ -1155,14 +1155,16 @@ void LibRaw::fuji_decode_loop(fuji_compressed_params *common_info, int count, IN const int lineStep = (libraw_internal_data.unpacker_data.fuji_total_lines + 0xF) & ~0xF; #ifdef LIBRAW_USE_OPENMP unsigned errcnt = 0; -#pragma omp parallel for private(cur_block) +#pragma omp parallel for private(cur_block) shared(errcnt) #endif for (cur_block = 0; cur_block < count; cur_block++) { - try{ + try + { fuji_decode_strip(common_info, cur_block, raw_block_offsets[cur_block], block_sizes[cur_block], q_bases ? q_bases + cur_block * lineStep : 0); - } catch (...) + } + catch (...) { #ifdef LIBRAW_USE_OPENMP #pragma omp atomicIn fact, the only difference is errcnt variable is declared openmp-shared (it is atomically changed if error catched, so the difference should be neglible).
I can only recommend performing detailed profiling of both versions and comparing where exactly you're experiencing performance degradation at the individual operator level.
Since I don't see any performance differences on our end, there's nothing to look for there.
Followup:
compiled with clang 19.1.7
Compilation flags: -O3 -fopenmp
Hi Alex.
Thanks for looking into this.
Mia Culpa! Your response prompted me to look into this again so I checked my Libraw 0.22 compile flags and found the Libraw VS project did not have the /OPENMP flag set for Debug mode. This accounted for the big performance difference (on a 16 core machine).
Very sorry to have you chase a ghost.
I'll be more thorough before posting next time.
Regards,
Sean.
Quick test (only unpack) with LibRaw compiled via make -f Makefile.dist (so no openmp), three files with different encoding:
0.22.0:
0.21.5:
CPU: Intel(R) Atom(TM) CPU C3758 @ 2.20GHz (2200.21-MHz K8-class CPU)
Storage: fast SSD (nvme)
So, please provide test file you use for benchmarking for more in-depth study.
Quote from this site 1st page:
In short: while such a feature might be interesting, it is outside the scope of the library.
There is no such program in LibRaw, this is RAW files reader. It's not very difficult to make it by combining LibRaw (for reading) and Adobe DNG SDK (for DNG creation).
But it's probably easier to file a bug to RawRefinery authors, instead of guessing what exactly their software doesn't like
It's not practical to wait instead of submitting samples.
This is JPEG-XL compressed DNG file. Please build LibRaw with Adobe DNG SDK (version 1.7 or 1.7.1, do not forget to enable JPEG-XL support).
See details in the provided README.DNGSDK.txt
I was waiting for 0.22 release expecting that my issue will also be resolved by this fix, but it is not. However, I see that original file from Garfield is now works fine, but this file from Samsung still does not. The error is "unpack failed". Can you please check what is wrong with this file?
https://drive.google.com/file/d/1U5HjaCkKDWCBjeAf-5CbaqjPuz9SFTnv/view?u...
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!
Pages