Great to know that the

lexa — Fri, 20 Mar 2026 13:29:55 +0000

Great to know that the problem has been resolved

For the files you provide and

lexa — Fri, 20 Mar 2026 08:39:29 +0000

For the files you provide and openmp enabled the difference is neglible:

0.22
 
$ time ./bin/unprocessed_raw ~/tt/GFX/*RAF
Processing file /home/lexa/tt/GFX/DSCF0029.RAF
[skip]
Processing file /home/lexa/tt/GFX/DSCF0307.RAF
[skip]
Processing file /home/lexa/tt/GFX/DSCF0614.RAF
[skip]
 
real    0m4,604s
user    0m32,124s
sys     0m0,811s
 
0.21
 
$ time ./bin/unprocessed_raw ~/tt/GFX/*RAF
Processing file /home/lexa/tt/GFX/DSCF0029.RAF
[skip]
Processing file /home/lexa/tt/GFX/DSCF0307.RAF
[skip]
Processing file /home/lexa/tt/GFX/DSCF0614.RAF
[skip]
 
real    0m4,687s
user    0m32,431s
sys     0m0,758s

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 atomic

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.

Followup:

lexa — Fri, 20 Mar 2026 09:32:10 +0000

Followup:
compiled with clang 19.1.7
Compilation flags: -O3 -fopenmp

Hi Alex.

Sean — Fri, 20 Mar 2026 07:55:39 +0000

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

lexa — Fri, 13 Mar 2026 18:54:22 +0000

Quick test (only unpack) with LibRaw compiled via make -f Makefile.dist (so no openmp), three files with different encoding:

0.22.0:

$ time ./bin/unprocessed_raw ~/tt/GFX100II/GFX100_II_1*RAF
Processing file /home/lexa/tt/GFX100II/GFX100_II_14bits_uncompressed_4x3.RAF
Image size: 11662x8746
Raw size: 11808x8754
Margins: top=2, left=0
Unpacked....
Stored to file /home/lexa/tt/GFX100II/GFX100_II_14bits_uncompressed_4x3.RAF.pgm
Processing file /home/lexa/tt/GFX100II/GFX100_II_16bits_lossless_4x3.RAF
Image size: 11662x8746
Raw size: 11808x8754
Margins: top=2, left=0
Unpacked....
Stored to file /home/lexa/tt/GFX100II/GFX100_II_16bits_lossless_4x3.RAF.pgm
Processing file /home/lexa/tt/GFX100II/GFX100_II_16bits_lossy_4x3.RAF
Image size: 11662x8746
Raw size: 11808x8754
Margins: top=2, left=0
Unpacked....
Stored to file /home/lexa/tt/GFX100II/GFX100_II_16bits_lossy_4x3.RAF.pgm

real    0m22,756s
user    0m21,958s
sys     0m0,783s

0.21.5:

$ time ./bin/unprocessed_raw ~/tt/GFX100II/GFX100_II_1*RAF
Processing file /home/lexa/tt/GFX100II/GFX100_II_14bits_uncompressed_4x3.RAF
Image size: 11662x8752
Raw size: 11808x8754
Margins: top=2, left=0
Unpacked....
Stored to file /home/lexa/tt/GFX100II/GFX100_II_14bits_uncompressed_4x3.RAF.pgm
Processing file /home/lexa/tt/GFX100II/GFX100_II_16bits_lossless_4x3.RAF
Image size: 11662x8752
Raw size: 11808x8754
Margins: top=2, left=0
Unpacked....
Stored to file /home/lexa/tt/GFX100II/GFX100_II_16bits_lossless_4x3.RAF.pgm
Processing file /home/lexa/tt/GFX100II/GFX100_II_16bits_lossy_4x3.RAF
Image size: 11662x8752
Raw size: 11808x8754
Margins: top=2, left=0
Unpacked....
Stored to file /home/lexa/tt/GFX100II/GFX100_II_16bits_lossy_4x3.RAF.pgm

real    0m22,798s
user    0m21,929s
sys     0m0,854s

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

lexa — Thu, 12 Feb 2026 10:32:12 +0000

Quote from this site 1st page:

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

lexa — Tue, 10 Feb 2026 09:23:32 +0000

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

ib — Thu, 15 Jan 2026 15:26:23 +0000

It's not practical to wait instead of submitting samples.

This is JPEG-XL compressed

lexa — Thu, 15 Jan 2026 14:58:19 +0000

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

Still some images are not supported

Andrey — Thu, 15 Jan 2026 14:05:21 +0000

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

lexa — Sat, 15 Nov 2025 14:04:18 +0000

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.

Solved

0x — Sat, 15 Nov 2025 11:22:52 +0000

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

lexa — Fri, 14 Nov 2025 14:43:38 +0000

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

0x — Fri, 14 Nov 2025 13:33:52 +0000

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

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.

raw-identify -v DSCF5078.RAF

lexa — Fri, 14 Nov 2025 10:13:40 +0000

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?

cam_xyz and rgb_cam not populated for X-T5 and X-T50 cameras

0x — Fri, 14 Nov 2025 09:36:06 +0000

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

and this is what i get but shouldn't automatically these matrices be populated
[2025-11-14 12:54:13.048] [warning] BEFORE_CALLING_UNPACK
--- cam_xyz ---
0       0       0
0       0       0
0       0       0
0       0       0
--- cmatrix ---
0       0       0       0
0       0       0       0
0       0       0       0
--- rgb_cam ---
1       0       0       0
0       1       0       0
0       0       1       0
--- pre_mul ---
1       1       1       0
--- cam_mul ---
596     302     541     0
 
[2025-11-14 12:54:13.102] [warning] AFTER_CALLING_UNPACK
--- cam_xyz ---
0       0       0
0       0       0
0       0       0
0       0       0
--- cmatrix ---
0       0       0       0
0       0       0       0
0       0       0       0
--- rgb_cam ---
1       0       0       0
0       1       0       0
0       0       1       0
--- pre_mul ---
1       1       1       0
--- cam_mul ---
596     302     541     0
[2025-11-14 12:54:13.108] [info] flip: 0
[2025-11-14 12:54:13.108] [warning] DID NOT FOUND A VALID cam_xyz MATRIX
[2025-11-14 12:54:20.715] [warning] AFTER_CALLING_DC_RAW_PROCESS
--- cam_xyz ---
0       0       0
0       0       0
0       0       0
0       0       0
--- cmatrix ---
0       0       0       0
0       0       0       0
0       0       0       0
--- rgb_cam ---
1       0       0       0
0       1       0       0
0       0       1       0
--- pre_mul ---
1.97351 1       1.79139 1
--- cam_mul ---
596     302     541     0
[2025-11-14 12:54:20.719] [info] dcraw_process completed successfully

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.

C++ API calls

0x — Fri, 14 Nov 2025 06:44:31 +0000

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

lexa — Fri, 14 Nov 2025 06:11:04 +0000

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?

Wrong color with fujifilm x-t50

0x — Thu, 13 Nov 2025 19:36:06 +0000

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

lexa — Sat, 01 Nov 2025 10:02:52 +0000

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

lexa — Sat, 01 Nov 2025 10:01:52 +0000

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

Chris Macke — Fri, 17 Oct 2025 15:07:24 +0000

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

elarsen — Sat, 11 Oct 2025 15:34:23 +0000

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

lexa — Wed, 10 Sep 2025 08:19:51 +0000

Thank you for the samples provided.

We'll consider adding Samsung lossy compression support into some version of public LibRaw.

Hello,

cc — Thu, 28 Aug 2025 10:05:00 +0000

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!

Recent comments

Great to know that the

For the files you provide and

Followup:

Hi Alex.

Quick test (only unpack) with

Quote from this site 1st page

There is no such program in

It's not practical to wait

This is JPEG-XL compressed

Still some images are not supported

Version mismatch (shared lib

Solved

Please make sure that the

Yes the problem is you see

raw-identify -v DSCF5078.RAF

cam_xyz and rgb_cam not populated for X-T5 and X-T50 cameras

C++ API calls

Here is screenshot of

Wrong color with fujifilm x-t50

New Samsung v3 decoder is

LIBRAW_OWN_SWAB is now

I'm using this bash script to

Thank you for this thread, it

Thank you for the samples

Hello,