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.
right you are, now that is shameful.
Yeah, I barely ever develop/compile any code on windows. I wouldn't try and use 'rm' in the Win CMD but I thought the Makefile.MinGW will be fully Win-compatible.... I guess not, didn't think straight, this lack of movement due to COVID is eating away on my braincells.
You are running mingw32-make from cmd.exe shell, and rm command does not exist in DOS. Even if you have the MSYS bin directory in your PATH where MSYS rm.exe lives, its behavior is probably strange/undefined under cmd.exe...
I prefer to use the MINGW (bash) shell from the start menu and traditional make (installed under MSYS) instead of ming32-make, the behavior is much more consistent with all other *nix platforms and build scripts.
right... so I removed line 134: rm -f lib/libraw.a
from the Makefile.mingw and it finished as expected. Not sure why the rm throws an error. Running it again throws no error even with the rm sinc the 'lib/libraw.a' then exists. Windows... :-/
thanks for the help. Now I'm working on windows defender accepting the compiled *.exe and NOT starting thread alerts everytime they run. Only happens to compiled ones. I'll get it done.
thanks again. Any usage questions I'll post elsewhere.
this is the error message:
rm -f lib/libraw.a
process_begin: CreateProcess(NULL, rm -f lib/libraw.a, ...) failed.
make (e=2): The system cannot find the file specified.
mingw32-make: *** [Makefile.mingw:134: lib/libraw.a] Error 2
never stumbled upon this error, but I suppose it must be my setups then. Tried on two machines one with msys, one with mingw freshly installed.
I don't compile a lot for windows, but I need it running on there since I'd implement it for automation. I wish github would just offer some virtual machines for compiling binaries for whatever platform one needs, still seems a hassle on Win-machines.
Thanks for your comments and help.
Ah, thanks guys, i was looking at the latest available(Windows) binaries.
Tried to build the latest snapshot using Makefile.mingw just now, getting an error at line 78: library: lib/libraw.a on two machines. 😐
Are the Windows binaries available for download somewhere, sorry, didn’t see them anywhere.
Thank you for your help and you so much! Now it is working as expected and the images are loading.
Build environment was OSX 10.15 with XCode and gcc,g++ installed via homebrew. But I will now compile it for Linux under Ubuntu 20.04 and Windows 10 as well.
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)
I need help
Thanks a lot for the work. 🙏🙏
https://www.libraw.org/news/libraw-202101-snapshot
Hello! any news on this? thanks!
Dear Sir:
Please advise the author of the program in question to check https://www.libraw.org/blog and to use the current LibRaw version.
I Have a question about .cr3 format by canon.
When I add .cr3 files and start stacking the program is not creating stacked file.
Could you help me with this issue?
Thanks!
right you are, now that is shameful.
Yeah, I barely ever develop/compile any code on windows. I wouldn't try and use 'rm' in the Win CMD but I thought the Makefile.MinGW will be fully Win-compatible.... I guess not, didn't think straight, this lack of movement due to COVID is eating away on my braincells.
Good find and lazy me, great community here!
You are running mingw32-make from cmd.exe shell, and rm command does not exist in DOS. Even if you have the MSYS bin directory in your PATH where MSYS rm.exe lives, its behavior is probably strange/undefined under cmd.exe...
I prefer to use the MINGW (bash) shell from the start menu and traditional make (installed under MSYS) instead of ming32-make, the behavior is much more consistent with all other *nix platforms and build scripts.
right... so I removed line 134: rm -f lib/libraw.a
from the Makefile.mingw and it finished as expected. Not sure why the rm throws an error. Running it again throws no error even with the rm sinc the 'lib/libraw.a' then exists. Windows... :-/
thanks for the help. Now I'm working on windows defender accepting the compiled *.exe and NOT starting thread alerts everytime they run. Only happens to compiled ones. I'll get it done.
thanks again. Any usage questions I'll post elsewhere.
'normal' rm should not raise return error code if rm -f [nonexistent-file] is used
Because your rm is not 'normal', you may try to remove rm -f lib/libraw.a statement from makefile
this is the error message:
rm -f lib/libraw.a
process_begin: CreateProcess(NULL, rm -f lib/libraw.a, ...) failed.
make (e=2): The system cannot find the file specified.
mingw32-make: *** [Makefile.mingw:134: lib/libraw.a] Error 2
here's the entire console output:
Screenshot
never stumbled upon this error, but I suppose it must be my setups then. Tried on two machines one with msys, one with mingw freshly installed.
I don't compile a lot for windows, but I need it running on there since I'd implement it for automation. I wish github would just offer some virtual machines for compiling binaries for whatever platform one needs, still seems a hassle on Win-machines.
Thanks for your comments and help.
We do not create binaries for snapshot/intermediate releases.
What is make's error message?
Ah, thanks guys, i was looking at the latest available(Windows) binaries.
Tried to build the latest snapshot using Makefile.mingw just now, getting an error at line 78: library: lib/libraw.a on two machines. 😐
Are the Windows binaries available for download somewhere, sorry, didn’t see them anywhere.
Thanks!
Yes, EOS R5 is supported in the latest public snapshot: https://www.libraw.org/news/libraw-202101-snapshot
Please have a look at https://www.libraw.org/blog and at update policy on https://www.libraw.org
Hi, it has been 9 months since the last release, is there any update on 0.21?
I'm also asking because of Canon R5 support.
kind regards
randfee
Thank you for your help and you so much! Now it is working as expected and the images are loading.
Build environment was OSX 10.15 with XCode and gcc,g++ installed via homebrew. But I will now compile it for Linux under Ubuntu 20.04 and Windows 10 as well.
My library librawfx (https://github.com/lanthale/librawfx) is an extension for the JavaFX library to add RAW image support.
something like
./configure CFLAGS="-O3 -DUSE_X3FTOOLS" CXXFLAGS="-O3 -DUSE_X3FTOOLS"
(still know nothing about your environment, so just a proposal, adjust it according to your specific environment/toolset/etc)
Pages