Nevermind, of course, is is prefixed, I don't know why I didn't see it: libraw_COLOR Sorry for the noise!

Unaltered ('as unpacked') pixel values are stored in imgdata.rawdata array(s)

samples/unprocessed_raw.cpp example writes (unaltered) data to TIFF file, probably this is code example you're looking for

ilce 7rm3a - sony alpha 7r iiia is actually Almosen same like ilce 7rm3 - sony alpha 7r iii

Not sure it is good idea (unless specified explicitly by library user via some flag?)
cam_xyz contains built-in data (from colordata.cpp), dng_color filled by DNG tags, not sure DNG data should always overwrite built-in data.

Thank you. I looked in to this more, it turns out the libraw->rawdata.color.cam_xyz field is blank with DNG images. I had to look at libraw->rawdata.color.dng_color

Sorry about the mistaken post!

I have a suggestion: Maybe put DNG's ColorMatrix2 (Daylight) in to the cam_xyz field? It might reduce confusion for some developers.

I am using build from latest source code from github.

What I want to do is to give user a Color temperature slider that needs to start with the color temp of the photo (say 5000K) and let him move in the range of say 2000-10000K.

So how do I compute this using the various data obtained in libraw_colordata_t? I thought cam_mul is a start?

There is no omp.h file in standard toolchain

Probably we need to remove comment 'need to recheck': rechecked and, yes, it will not work in standard Apple-provided environment

Just follow the instructions on this link:

https://mac.r-project.org/openmp/

I grabbed the OpenMP dylib there and it compiles fine. No need to download another version of llvm.

In fact, I finally got LibRaw to work. There is a bug in Libraw_types.h in which it failed to detect -fopenmp when compiling via Xcode. Fixing that LibRaw compiles just fine using Xcode 12.4 with OpenMP support.

The question I have now is: how to control the number of threads during decode? It seems the #pragma parallel will cause the number of threads creation the same as the number of logical processor. I don't want that many. Is there a way I can alter that during runtime before calling unpack()?

Xcode 12.4 actually works with -fopenmp, you need to add -Xclang option just before it.

I made a small sample code like this:

int main(int argc, const char * argv[]) {
omp_set_num_threads(8);
#pragma omp parallel
#pragma omp critical
NSLog(@"Greetings from thread %d", omp_get_thread_num());
return NSApplicationMain(argc, argv);
}

And I get this on the console:

2021-10-20 16:23:46.653740-0700 Test[14661:304853] Greetings from thread 0
2021-10-20 16:23:46.653954-0700 Test[14661:304941] Greetings from thread 1
2021-10-20 16:23:46.653985-0700 Test[14661:304943] Greetings from thread 3
2021-10-20 16:23:46.654015-0700 Test[14661:304942] Greetings from thread 2
2021-10-20 16:23:46.654045-0700 Test[14661:304944] Greetings from thread 4
2021-10-20 16:23:46.654069-0700 Test[14661:304947] Greetings from thread 7
2021-10-20 16:23:46.654085-0700 Test[14661:304946] Greetings from thread 6
2021-10-20 16:23:46.654102-0700 Test[14661:304945] Greetings from thread 5

My problem now is with libraw:

In the Makefile.dist, I uncommented CFLAGS+=-fopenmp and I added -Xclang to it, so it looks like:

CFLAGS+=-Xclang -fopenmp

It compiles fine, but when I linked my project, it'll link even I did not have libomp.dylib. So libraw is not really compiled with OpenMP support with the CFLAGS line above.

So what else is missing?

I'm having the same problem, Have you found any solution that you can share?