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.
In colour science CCT is derived from xy. xy calculation depends on the colour transform, raw to XYZ. This transform is not one-to-one because raw data isn't colorimetric. Different companies use different colour transforms for the same camera model. Say, the camera and ACR report different CTs for the same shot.
Your best bet is to shoot a camera at each CT setting, compile a table of CTs vs. wb coeffs, and interpolate.
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?
If you're speaking about:
#elif (defined(__APPLE__) || defined(__MACOSX__)) && defined(_REENTRANT)
/* Latest XCode works with OpenMP, need to recheck here */
#undef LIBRAW_USE_OPENMP
This is not bug, but specially added because standard Apple toolchain does not support OpenMP
For other toolchains one may use -DLIBRAW_FORCE_OPENMP to enable this #if-branch:
#if defined(LIBRAW_FORCE_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()?
I'm unable to build openmp app with Xcode/clang because of omp.h missing. find / -name omp.h returns nothing.
So:
1) It is not possible to compile LibRaw with openmp using standard Apple tools (12.4 and 12.5)
2) If you was able to compile it: that means you have omp.h from some other build tools, we're unable to provide support in that case. You may add some #error preprocessor directives into LibRaw sources near #pragma omp to make sure it compiled with openmp or not.
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.
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.
Hey, I would also be interested in this topic of how to prepare a "good" visual representation of a RAW file automatically (similar to what FastRawViewer, RawTherapee, etc are doing). Using only dcraw_process() is not enough. I know in the documentation it also says that you should probably write your own algorithm. Is there any literature or open source examples of a "good enough" implementation that produces better results? Especially the exposure seems to be missing in the processing. Take a look at this example, where the top row are original RAW files as seen through FastRawViewer and the bottom row are the images created with dcraw_process(). You can hardly see the difference between the three exposures.
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.
In colour science CCT is derived from xy. xy calculation depends on the colour transform, raw to XYZ. This transform is not one-to-one because raw data isn't colorimetric. Different companies use different colour transforms for the same camera model. Say, the camera and ACR report different CTs for the same shot.
Your best bet is to shoot a camera at each CT setting, compile a table of CTs vs. wb coeffs, and interpolate.
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?
White balance is not measured in Kelvins.
There is no omp.h file in standard toolchain
This is no longer true. Standard Apple Toolchain works with OpenMP. Just add -Xclang -fopenmp to the compile flags.
I have to add -DLIBRAW_FORCE_OPENMP in the Makefile.dist in order for it work for standard Apple Toolchain.
That aside, but how do I control the number of threads to use? It seems be always the same as the number of logical processors.
Probably we need to remove comment 'need to recheck': rechecked and, yes, it will not work in standard Apple-provided environment
If you're speaking about:
#elif (defined(__APPLE__) || defined(__MACOSX__)) && defined(_REENTRANT)
/* Latest XCode works with OpenMP, need to recheck here */
#undef LIBRAW_USE_OPENMP
This is not bug, but specially added because standard Apple toolchain does not support OpenMP
For other toolchains one may use -DLIBRAW_FORCE_OPENMP to enable this #if-branch:
#if defined(LIBRAW_FORCE_OPENMP)
...
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()?
I'm unable to build openmp app with Xcode/clang because of omp.h missing. find / -name omp.h returns nothing.
So:
1) It is not possible to compile LibRaw with openmp using standard Apple tools (12.4 and 12.5)
2) If you was able to compile it: that means you have omp.h from some other build tools, we're unable to provide support in that case. You may add some #error preprocessor directives into LibRaw sources near #pragma omp to make sure it compiled with openmp or not.
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?
Apple's clang (from XCode 12.4) refuses -fopenmp option, so OpenMP is not supported by this (standard macOS) compiler
If you use another compiler/runtime please refer your OpenMP runtime docs about "How do I control the number of CPU cores...."
I'm having the same problem, Have you found any solution that you can share?
LibRaw supports iPhone's DNG files, but not HEIC files.
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
dcraw_make_mem_image is the last step, applied after all postprocessing steps.
I suggest you to play with quality settings and/or half-size output. Also, OpenMP may help with default quality settings.
I am using "libraw_dcraw_make_mem_image". Maybe this is the issue. What should I use instat ?
What demosaic method for X-Trans do you use?
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!
Hey, I would also be interested in this topic of how to prepare a "good" visual representation of a RAW file automatically (similar to what FastRawViewer, RawTherapee, etc are doing). Using only dcraw_process() is not enough. I know in the documentation it also says that you should probably write your own algorithm. Is there any literature or open source examples of a "good enough" implementation that produces better results? Especially the exposure seems to be missing in the processing. Take a look at this example, where the top row are original RAW files as seen through FastRawViewer and the bottom row are the images created with dcraw_process(). You can hardly see the difference between the three exposures.
https://www.dropbox.com/s/jvdeu9h0bds9bse/libraw_vs_fastrawviewer.png?dl=0
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)
I see. Thanks for the prompt reply!
_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.
What version of LibRaw do you use?
Hi Alex,
thank you very much. I appreciated your quick reply.
Confirmed, it does the trick.
Thilo
Pages