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.
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)
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
make -f Makefile.dist
should do the trick
LibRaw is not about RAW writing, but about reading.
ok, I get it.
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
Thanks for your reply and advice.
I've solved the panasonic rw2 issue.
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)
Hi, sorry to bother you again.
Don't know how the offset works,
Thanks for the tip. I'm trying to parse and get the data from
lr_ptr->imgdata.thumbnail.thumbI used the exiftool program to see the structure (with -v3 command line key to see details)
It clearly shows this:
| 32) JpgFromRaw (SubDirectory) -->
| - Tag 0x002e (713278 bytes, undef[713278]):
[skip[
--- DOC1:JpgFromRaw --------------------------------------------------------
JPEG APP1 (50684 bytes):
0006: 45 78 69 66 00 00 49 49 2a 00 08 00 00 00 10 00 [Exif..II*.......]
[skip]
ExifByteOrder = II
+ [IFD0 directory with 16 entries]
and 0x004d is within Makernotes pointed by this (JpgFromRaw) EXIF
Great, I didn't know that the 0x004d tag is not in Raw exif but in thumbnail exif. Thanks for the advice.
Pages