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 am using the proposed one from the documenation with ./configure and make. I have modified the makefile but it have not helped. Can I specify it as an option for the ./configure or how can I use ./configure and enable X3F support ?
Lightroom does not utilize ICC profiles for camera color calibration. It only accepts DCP.
ICC and DCP profiles are similar, but DCPs can be more sophisticated. I'm going to quote from the dcamprof documentation (open source command line utility for making color profiles)
"The forward matrix which operates in D50 XYZ space using D50 as the reference illuminant is not unique to DNG profiles, it’s used for ICC profiles too."
"The color matrix is... DNG-specific, it’s used for estimating the temperature and tint of the scene illuminant based on a white balance setting."
Both ICC profiles and DCP profiles can contain LUTs. These are color look up tables.
DCP profiles can contain two types: HueSatMap tables and LookTables. HSM tables basically do additional color correction. LookTables apply a second set of adjustments on top of that. Sometimes there is only an HSM or LookTable. Sometimes there is also only a color matrix in DCPs. They can be designed in a nubmer of ways.
I do not know what you're doing to convert rawdata into cv:Mat
What I see on screenshot is 3xUINT8 data type. That probably wrong because source (bayer) image contains single component per pixel.
Thank you very much!
I successfully received pictures from raw_image, but they are small. As I understand I received thumbnails, which raw contains. How I can access the full format picture?
I received such pictures: https://postimg.cc/gr5k2Kft
Depending of file internals type (bayer, or full color), only one pointer in imgdata.rawdata is non-NULL:
raw_image - for bayer or X-Trans (color filter array) images
color3_image - for full-color (Foveon, linear DNG) images if 3-channel data extractor was used
color4_image - for full-color images with 4-channel data extractor
(if color4_image is not-NULL, this does not always mean you have 4-channel input, it could-be 3-channeld and zeroes in 4th channel, inspect imgdata.idata.colors for that).
And similar three pointers for floating point input: float_image, float3_image, float4_image.
So, your code should check all six pointers (or only three if floating point input is not expected) and select image type based on 'what pointer is non-NULL'
Adobe uses own raw processing engine, different from LibRaw. There is no known rule(s) to convert Adobe sliders into LibRaw's imgdata.params
Also, I do not think that altering imgdata.image values without some knowledge of LibRaw::dcraw_process internals is a good idea. You may either study it (it is opensource, so it is possible), or create own raw processing.
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)
I am using the proposed one from the documenation with ./configure and make. I have modified the makefile but it have not helped. Can I specify it as an option for the ./configure or how can I use ./configure and enable X3F support ?
I do not know what build method you use (providede makefiles, or configure, or qmake pro files, there are many)
Add -DUSE_X3FTOOLS to C and C++ compiler flags
Thank you for the hint and I have seen this but cannot find the place in the makefile where to place USE_X3FTOOLS.
Can you help me out ?
Thank you in advance.
Lightroom does not utilize ICC profiles for camera color calibration. It only accepts DCP.
ICC and DCP profiles are similar, but DCPs can be more sophisticated. I'm going to quote from the dcamprof documentation (open source command line utility for making color profiles)
"The forward matrix which operates in D50 XYZ space using D50 as the reference illuminant is not unique to DNG profiles, it’s used for ICC profiles too."
"The color matrix is... DNG-specific, it’s used for estimating the temperature and tint of the scene illuminant based on a white balance setting."
Both ICC profiles and DCP profiles can contain LUTs. These are color look up tables.
DCP profiles can contain two types: HueSatMap tables and LookTables. HSM tables basically do additional color correction. LookTables apply a second set of adjustments on top of that. Sometimes there is only an HSM or LookTable. Sometimes there is also only a color matrix in DCPs. They can be designed in a nubmer of ways.
If you want to experiment with making your own color profiles, download dcamprof, rawtherapee, buy a color checker, and follow these instructions https://rawpedia.rawtherapee.com/How_to_create_DCP_color_profiles
As stated in LibRaw 0.20 release notes (https://www.libraw.org/news/libraw-0-20-2-Release )
you need to define USE_X3FTOOLS while building LibRaw
X3F support is not enabled by default.
I do not know what you're doing to convert rawdata into cv:Mat
What I see on screenshot is 3xUINT8 data type. That probably wrong because source (bayer) image contains single component per pixel.
Thank you very much!
I successfully received pictures from raw_image, but they are small. As I understand I received thumbnails, which raw contains. How I can access the full format picture?
I received such pictures:
https://postimg.cc/gr5k2Kft
Depending of file internals type (bayer, or full color), only one pointer in imgdata.rawdata is non-NULL:
raw_image - for bayer or X-Trans (color filter array) images
color3_image - for full-color (Foveon, linear DNG) images if 3-channel data extractor was used
color4_image - for full-color images with 4-channel data extractor
(if color4_image is not-NULL, this does not always mean you have 4-channel input, it could-be 3-channeld and zeroes in 4th channel, inspect imgdata.idata.colors for that).
And similar three pointers for floating point input: float_image, float3_image, float4_image.
So, your code should check all six pointers (or only three if floating point input is not expected) and select image type based on 'what pointer is non-NULL'
LibRaw (post)processing is very similar to dcraw.c postprocessing.
In order not to rewrite the same thing many times, this post-processing is explaned in detail here: https://ninedegreesbelow.com/files/dcraw-c-code-annotated-code.html
Thanks for your help, Alex. We'll try to figure out how to apply such a variable contrast transformation ourselves then.
Thank you. I have checked and the options are already set in the actual make file, so it should work.
Adobe uses own raw processing engine, different from LibRaw. There is no known rule(s) to convert Adobe sliders into LibRaw's imgdata.params
Also, I do not think that altering imgdata.image values without some knowledge of LibRaw::dcraw_process internals is a good idea. You may either study it (it is opensource, so it is possible), or create own raw processing.
LibRaw's dcraw_process() is very similar to dcraw.c processing, so you may find this link useful: https://ninedegreesbelow.com/files/dcraw-c-code-annotated-code.html
Pages