Could you please point out how you made it work with VS?
I have also compiled Libraw with enabled LCMS (by modifying Makefile.msvc file) and the generated executables work just fine supporting LCMS. However, not when I link Libraw to my VS. It still seems like it doesn't support LCMS. any advice?
According to your code, you use 'all defaults' for libraw processing (dcraw_process), so daylight white balance and automatic 1%-ETTR brightness correction.
There's other huge gamuts too, like xTremeRGB , MaxRGB, and AllColorsRGB. None of these are in libraw, but the description of xtremeRGB says that, "CAUTION: XtremeRGB may cause hallucinations or eye cancer." (http://www.hutchcolor.com/profiles.html)
LibRaw is limited to whatever raw data is. Processing of raw data (white balance, colour space conversion, gamma) is out of the scope of main LibRaw functionality, we keep such processing for testing purposes only. LibRaw is not a raw converter and isn't meant to be one ;)
> My apologies if I offended or annoyed you.
Not in the least.
> I was under the mistaken impression that the ICC profiles are simply assigned on output
They are not, but even if they were, what good is it to assign one profile while converting to a different one?
I checked, and yes, Coffin's aces_rgb matrix isn't adapted to D65.
I think I made it clear what I'm referring to, and so did you. We can't fix what is not there. Your proposal is technically impossible (and in any case, the starting point is the matrix in the standard), and I explained what we are going to do. Let's return to the topic only when there will be anything new to discuss.
I'm saying that matrices in Coffin's workflow are of a different nature (his workflow doesn't use "forward matrix for ACES", or "ACES colour profile", so no place to change it), and that we will check aces_rgb matrix to see if the chromatic adaptation from ACES "D60-like" white point to D65 necessary for Coffin's workflow is missing.
I checked the ProPhoto and sRGB XYZ values, and when arranged in a matrix the rows sum to the expected D50 values. The ACES one was the only one that was abberant.
The D65 part comes in the MediaWhitePoint tag in the ICC profiles. There's no issue with that, I'm aware of that aspect of Coffin's color profiles and they have correct values in the MediaWhitePoint tag.
The XYZ values in the ICC profile which form the RGB to XYZ matrix ('forward matrix') though should sum to the connection space illuminant however, which is D50 regardless of the media white point. This is because these values take it from the connection space, which is CIE D50 2 degree observer XYZ space, to RGB, and chromatic adaptation to the media white point is done from there. See section 6.3.4.3 of https://www.color.org/specification/ICC1v43_2010-12.pdf
In any case, the sums of the XYZ values found in the ACES profile I extracted are 0.97056 1.00145 0.76492 respectively. Looks like it's almost the correct set of values, but somewhere along the way there was probably a typo. I'm not sure if this is exclusive to libraw or if this was also present in the original dcraw since I don't have the original dcraw currently.
Without coding, just using a simple script with calls to: dcraw.exe, exitfool and dng_validate from Adobe, I have managed to create some synthetic valid DNG files:
- Linear light decomposition to balance different colour temperatures in RAW
- Mean stacking to mimic ultra low ISO/ND filter
- Median stacking to remove moving subjects
- HDR RAW
Last LibRaw public snapshot supports some Arri models if compiled with LIBRAW_OLD_VIDEO_SUPPORT defined. Not sure that LibRaw support this specific camera (Alexa LF listed as supported, do not know what is pus W)
We plan to continue Arri support up to release 0.21, than drop this support: LibRaw is not about video.
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.
I do not know what specific camera you're talking about.
Just inspected some GH5S file. For this file 0x004d/AFPointPosition tag is not in IFD0, but in makernotes section of EXIF.
The bad thing: this is NOT RAW/EXIF, but EXIF contained in embedded JPEG preview.
So, to extract the data you need:
- extract thumbnail (preview) using LibRaw::unpack_thumb
- use some EXIF parser to parse thumbnail's EXIF
I've tried to use these code to catch the exif tag data.
void exif_cb(void *context, int tag, int type, int len, unsigned int ord, void *ifp, INT64 base) { print(tag); if (tag == (0x004d | 0x30000)) { print("get the 0x004d tag"); } }0x004d is from https://exiftool.org/TagNames/Panasonic.html named "AFPointPosition".
I can get all the tags printed, but no "0x004d" found.
p.s.
The rw2 raw file i'm using can be extracted a "0x004d" AFPointPosition tag data by the ExifTool downloaded from https://exiftool.org/
in the next public snapshot (this Fall)
You may try to use 'exif callback': https://www.libraw.org/docs/API-CXX.html#exif
Note: for panasonic's main IFD, tag is or-ed with 0x30000 (to distinguish from normal tiff ifd)
Could you please point out how you made it work with VS?
I have also compiled Libraw with enabled LCMS (by modifying Makefile.msvc file) and the generated executables work just fine supporting LCMS. However, not when I link Libraw to my VS. It still seems like it doesn't support LCMS. any advice?
According to your code, you use 'all defaults' for libraw processing (dcraw_process), so daylight white balance and automatic 1%-ETTR brightness correction.
There's other huge gamuts too, like xTremeRGB , MaxRGB, and AllColorsRGB. None of these are in libraw, but the description of xtremeRGB says that, "CAUTION: XtremeRGB may cause hallucinations or eye cancer." (http://www.hutchcolor.com/profiles.html)
I realize that, just thinking out loud pragmatically 😉
I guess there are ProPhoto and Rec2020 outputs available to cover a "similar" range and precision...
LibRaw is limited to whatever raw data is. Processing of raw data (white balance, colour space conversion, gamma) is out of the scope of main LibRaw functionality, we keep such processing for testing purposes only. LibRaw is not a raw converter and isn't meant to be one ;)
Btw, I'm wondering how useful (or harmful?) is it to have that huge ACES AP0 output color space when LibRaw is limited to uint16 representation...
Sounds like an AP1-based ACEScg D65 adapted option would be good to have as well?
One should perhaps clarify in the docs that AP0 based "ACES2065-1 adapted to D65" is meant by the existing "ACES" enum?
> My apologies if I offended or annoyed you.
Not in the least.
> I was under the mistaken impression that the ICC profiles are simply assigned on output
They are not, but even if they were, what good is it to assign one profile while converting to a different one?
I checked, and yes, Coffin's aces_rgb matrix isn't adapted to D65.
Fixed in master now (the changes are in src/tables/colorconst.cpp) https://github.com/LibRaw/LibRaw/commit/1974214acf47ef260853d74006765746...
My apologies if I offended or annoyed you. I was under the mistaken impression that the ICC profiles are simply assigned on output
I think I made it clear what I'm referring to, and so did you. We can't fix what is not there. Your proposal is technically impossible (and in any case, the starting point is the matrix in the standard), and I explained what we are going to do. Let's return to the topic only when there will be anything new to discuss.
To which matrices are you referring? The cam2rgb matrices? I am talking about what's in the actual icc profiles embedded in the images, to be clear.
I'm saying that matrices in Coffin's workflow are of a different nature (his workflow doesn't use "forward matrix for ACES", or "ACES colour profile", so no place to change it), and that we will check aces_rgb matrix to see if the chromatic adaptation from ACES "D60-like" white point to D65 necessary for Coffin's workflow is missing.
I checked the ProPhoto and sRGB XYZ values, and when arranged in a matrix the rows sum to the expected D50 values. The ACES one was the only one that was abberant.
The D65 part comes in the MediaWhitePoint tag in the ICC profiles. There's no issue with that, I'm aware of that aspect of Coffin's color profiles and they have correct values in the MediaWhitePoint tag.
The XYZ values in the ICC profile which form the RGB to XYZ matrix ('forward matrix') though should sum to the connection space illuminant however, which is D50 regardless of the media white point. This is because these values take it from the connection space, which is CIE D50 2 degree observer XYZ space, to RGB, and chromatic adaptation to the media white point is done from there. See section 6.3.4.3 of https://www.color.org/specification/ICC1v43_2010-12.pdf
In any case, the sums of the XYZ values found in the ACES profile I extracted are 0.97056 1.00145 0.76492 respectively. Looks like it's almost the correct set of values, but somewhere along the way there was probably a typo. I'm not sure if this is exclusive to libraw or if this was also present in the original dcraw since I don't have the original dcraw currently.
Thanks for getting back to me!
> Note that even if the white point is D65 or D60, the rows of the forward matrix should sum to the D50 values.
Not in Coffin's workflow, he uses D65 to avoid an extra step of chromatic adaptation (check his ProPhoto RGB, for example).
Also, aces_rgb[3][3] is not a forward matrix, it's sRGB to ACES matrix (see identity matrix rgb_rgb[3][3] for sRGB).
We will check the aces_rgb matrix to make sure it follows the same logic as other matrices.
Seems ECW Demosaicing looks similar to the one Capture One uses 2021.
Without coding, just using a simple script with calls to: dcraw.exe, exitfool and dng_validate from Adobe, I have managed to create some synthetic valid DNG files:
- Linear light decomposition to balance different colour temperatures in RAW
- Mean stacking to mimic ultra low ISO/ND filter
- Median stacking to remove moving subjects
- HDR RAW
https://www.overfitting.net/2021/04/generando-un-raw-en-formato-dng-part...
Regards
Thank you. Now I use command line tool to decode. Alexa LF plus W is the camera of the ARI file that I exported with other software.
We use Adobe DNG SDK to create DNG.
Last LibRaw public snapshot supports some Arri models if compiled with LIBRAW_OLD_VIDEO_SUPPORT defined. Not sure that LibRaw support this specific camera (Alexa LF listed as supported, do not know what is pus W)
We plan to continue Arri support up to release 0.21, than drop this support: LibRaw is not about video.
Please consider use of other API (e.g. Arri SDK)
Pages