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?

Here is TIFF-file created by dcraw_emu -w -T [your-file]: https://www.dropbox.com/s/b4st4g9o5846l6f/IMG_2407.DNG.tiff?dl=0
(tested with public snapshot/github version).

I do not see any problems here

I am using "libraw_dcraw_make_mem_image". Maybe this is the issue. What should I use instat ?

We ended up applying camera-specific tone curves that match the embedded thumbnail after LibRaw has finished processing it. It seems to work pretty well. We took inspiration for that from how darktable does it. (darktable is open source so you can check the code if you're interested.) I'm guessing the variable contrast mode in FastRawViewer is doing something similar.

Good luck!

Sorry, know nothing about Debian.

There is no problem with your file and LibRaw fetched from github (current public snapshot) and compiled with -DUSE_ZLIB (and linked with -lz)

_rgb_cam (input data) is similar to DNG CameraMatrixN (https://www.adobe.com/content/dam/acom/en/products/photoshop/pdfs/dng_sp...) so contains both color transform and D65 WB coefficients.

Hi Alex,

thank you very much. I appreciated your quick reply.

Confirmed, it does the trick.

Thilo

LibRaw is not about RAW writing, but about reading.

LibRaw is NOT a complete EXIF/Makernotes parser. We're focused on data that needed for RAW processing, other fields are optional. Please use some other software for complete metadata parsing and interpretation

1)Not sure what is displayed by exiftool, it may be offset from file beginning, not from jpeg preview start.
(hard to tell without having the file)

2) tags larger than 4 bytes contains offset (relative to IFD start), not exact value, so one need to seek to this offset to read the data. There is not enough output in your quote to check this.

BTW, I suggest you to not invent the wheel :), but use some exif parser (e.g. exiv2 if you can tolerate GPL licensing)