I've tried that. No change :-(
Visual Studio 2022 17.8.1
I've also disabled the optimization for the get_decoder_info() function and even for the declarations for vc5_dng_load_raw_placeholder() and jxl_dng_load_raw_placeholder() in the header.
Did a full rebuild of LibRaw each time, just in case.
No change in the name returned!
I then moved the call to get_decoder_info into a separate function in my code (returns true if the options should be added) and wrapped that in optimize off / on.
Same result. Still returned the wrong name.
I think this is something really strange with Maximum Optimization that somehow rolls things together on a more global level. Normal Optimization works, so I'll use that for now. Until you maybe change the code to work around this somehow.
void LibRaw::vc5_dng_load_raw_placeholder()
{
// placeholder only, real decoding implemented in GPR SDK
throw LIBRAW_EXCEPTION_UNSUPPORTED_FORMAT;
}
void LibRaw::jxl_dng_load_raw_placeholder()
{
// placeholder only, real decoding implemented in DNG SDK
throw LIBRAW_EXCEPTION_UNSUPPORTED_FORMAT;
}
Looks like Visual studio detects this, compiles as single function, so else if (load_raw == &LibRaw::vc5_dng_load_raw_placeholder)
and else if (load_raw == &LibRaw::jxl_dng_load_raw_placeholder)
Are both true....
Looks like
1) these functions should be separated in additional code unit
2) All optimizations should be disabled at least for common compilers (gcc, clang, visual studio).
I've tested this and it seems to be some kind of code generation / optimization issue with Visual C++ 2022...?
I create LibRaw as a static library.
When I use the debug build, the decoder_name returned is "jxl_dng_load_raw_placeholder()".
When I compile the release build with optimizations disabled (/Od) or set to Optimizations (Favor Speed) (/Ox), the decoder_name returned is also "jxl_dng_load_raw_placeholder()".
But when I build release with Maximum Optimization (Favor Speed) (/O2), the decoder_name is set to "vc5_dng_load_raw_placeholder()"
Looking at the LibRaw source, this should only happen when USE_GPRSDK is defined (it is not in my build) so I can only assume that there is some sort of compiler error or wrong jump produced when optimizing that case statement when the /O2 is enabled.
vc5_dng_load_raw_placeholder is GoPro files decoder name. It was not mentioned in my reply; Also this name should not be returned in get_decoder_info() for both release and debug (unless you load DLL with different LibRaw version....)
and compare the dinfo->name with "jxl_dng_load_raw_placeholder()" and "vc5_dng_load_raw_placeholder()", as you suggested (I hope I understood you correctly).
And this works very well for the problem image. In the debug built.
When I switch to the release built (Visual C++ 2022), the dinfo->name returned is "lossy_dng_load_raw()" for some reason I don't understand yet. I will prepare a release build with debug symbols so I can trace into this. The preprocessor defines etc. the same for both builds.
When I also set the new opcode flags when "lossy_dng_load_raw()" is returned in dinfo->name, the image looks good in the release build too.
Thanks, Alex!
this is really helpful. I will implement your suggestions as soon as possible.
Are these LIBRAW_RAWOPTIONS_DNG_STAGE* flags documented somewhere? I have found them in the source code and see where you apply them, and I have some rough idea about opcodes in DNG files, but I would never have thought that I have to apply them or which of them.
In most cases, the DNG files I have to handle have large-enough embedded previews and that's sufficient for my use-case.
But when it comes to actual processing of RAW data into a usable image, things get a lot more difficult and finding parameters which work across a wide range of RAW files is tough.
The image is linearized via OpcodeList2 tag value; For similar images use of OpcodeList3 is also possible (probably depends on Adobe software version used).
By default, only OpcodeList1 tag is processed by LibRaw
To enable OpcodeList2/3 processing LIBRAW_RAWOPTIONS_DNG_STAGE2_IFPRESENT/LIBRAW_RAWOPTIONS_DNG_STAGE3_IFPRESENT flags should be added to imgdata.rawparams.options
This translates into numeric value of (1<<20)|(1<<21) so 3145728
This is not perfect solution if one do not want to apply OpcodeList2/3 for all DNG files containing these tags.
To improve it: query decoder used via LibRaw::get_decoder_info() and set the flags only for jxl_dng_load_raw_placeholder() and/or lossy_dng_load_raw() decoders.
Please let me know which LibRaw setting or steps I need to perform to get rid of the color cast, if possible.
Or maybe I need to configure the Adobe DNG SDK host instance specifically?
All this is new to me and any help is appreciated.
As mentioned on the this site homepage/LibRaw project description:
Additionally, the LibRaw library offers some basic RAW conversion, intended for cases when such conversion is not the main function of the LibRaw-using application (for example: a viewer for 500+ graphic file formats, including RAW). These methods are inherited from the Dave Coffin’s dcraw.c utility (see below the “Project history” section); their further development is not currently planned
LibRaw RAW postprocessing (sample code) do not apply any custom aspect ratio change, although you may implement your own on processed image.
I have sent an email to the owner of the image and asked if I can provide it to you as an example.
I will post here when I have the permission and provide a download link.
It seems to use the JPXL compression, that's all I can tell so far.
When are you adding "Sony IMX490 imaging sensor (Bayer sensor, with a resolution of 2880 × 1856)" to the list. I need help with conversion of .raw file from this camera to 16-bit Tiff
auto balance is based on the idea of a "average gray" world, which is not true for global colored scenes.
If you take a photo of a green grass, then the result of automatic white balance will not satisfy you too.
I didn't know FastRawViewer has it's own processing. That's interesting...
I too was able to achieve that image, but only after i manually switched the wb method.
Anyway, since i cant invest in a whole new post-processing infra at the moment, and considering your comment:
"I do not think that auto-balance is well suited for such images with overall warm tint."
can you suggest a good way to detect said warm tints, so as to switch from auto to camera wb automatically, or is this something only human eye can detect and decern?
I've tried that. No change :-(
Visual Studio 2022 17.8.1
I've also disabled the optimization for the
get_decoder_info()function and even for the declarations for vc5_dng_load_raw_placeholder() and jxl_dng_load_raw_placeholder() in the header.Did a full rebuild of LibRaw each time, just in case.
No change in the name returned!
I then moved the call to get_decoder_info into a separate function in my code (returns true if the options should be added) and wrapped that in optimize off / on.
Same result. Still returned the wrong name.
I think this is something really strange with Maximum Optimization that somehow rolls things together on a more global level. Normal Optimization works, so I'll use that for now. Until you maybe change the code to work around this somehow.
#pragma optimize( "", off )
before
void LibRaw::vc5_dng_load_raw_placeholder()
and
#pragma optimize( "", on )
before
void LibRaw::adobe_copy_pixel(unsigned row, unsigned col, ushort **rp)
(in src/decoders/dng.cpp)
Will probably fix the issue.
These pragmas are Visual Studio specific; we'll implement wider solution in the next update
Looks interesting.
In fact, both functions have the same body:
void LibRaw::vc5_dng_load_raw_placeholder() { // placeholder only, real decoding implemented in GPR SDK throw LIBRAW_EXCEPTION_UNSUPPORTED_FORMAT; } void LibRaw::jxl_dng_load_raw_placeholder() { // placeholder only, real decoding implemented in DNG SDK throw LIBRAW_EXCEPTION_UNSUPPORTED_FORMAT; }Looks like Visual studio detects this, compiles as single function, so
else if (load_raw == &LibRaw::vc5_dng_load_raw_placeholder)
and
else if (load_raw == &LibRaw::jxl_dng_load_raw_placeholder)
Are both true....
Looks like
1) these functions should be separated in additional code unit
2) All optimizations should be disabled at least for common compilers (gcc, clang, visual studio).
I've tested this and it seems to be some kind of code generation / optimization issue with Visual C++ 2022...?
I create LibRaw as a static library.
When I use the debug build, the decoder_name returned is "jxl_dng_load_raw_placeholder()".
When I compile the release build with optimizations disabled (/Od) or set to Optimizations (Favor Speed) (/Ox), the decoder_name returned is also "jxl_dng_load_raw_placeholder()".
But when I build release with Maximum Optimization (Favor Speed) (/O2), the decoder_name is set to "vc5_dng_load_raw_placeholder()"
Looking at the LibRaw source, this should only happen when USE_GPRSDK is defined (it is not in my build) so I can only assume that there is some sort of compiler error or wrong jump produced when optimizing that case statement when the /O2 is enabled.
LibRaw::open_bayer() is what you're probably looking for.
vc5_dng_load_raw_placeholder is GoPro files decoder name. It was not mentioned in my reply; Also this name should not be returned in get_decoder_info() for both release and debug (unless you load DLL with different LibRaw version....)
I've got this working, following your instructions.
I call:
and compare the dinfo->name with "jxl_dng_load_raw_placeholder()" and "vc5_dng_load_raw_placeholder()", as you suggested (I hope I understood you correctly).
And this works very well for the problem image. In the debug built.
When I switch to the release built (Visual C++ 2022), the dinfo->name returned is "lossy_dng_load_raw()" for some reason I don't understand yet. I will prepare a release build with debug symbols so I can trace into this. The preprocessor defines etc. the same for both builds.
When I also set the new opcode flags when "lossy_dng_load_raw()" is returned in dinfo->name, the image looks good in the release build too.
Any idea?
Followup:
Sorry for wrong info: STAG2/3_IFPRESENT are documented in Changelog only for now: https://github.com/LibRaw/LibRaw/blob/master/Changelog.txt#L250-L257
Sure, these flags are documented in actual documentation provided with LibRaw 202403-snapshot: https://github.com/LibRaw/LibRaw/blob/master/doc/API-datastruct.html#L12...
This site documentation section contains release docs.
We'll probably make these flags (or similar ones) set by default in the next snapshot/release because JPEG-XL compressed DNGs becomes very common.
Thanks, Alex!
this is really helpful. I will implement your suggestions as soon as possible.
Are these LIBRAW_RAWOPTIONS_DNG_STAGE* flags documented somewhere? I have found them in the source code and see where you apply them, and I have some rough idea about opcodes in DNG files, but I would never have thought that I have to apply them or which of them.
In most cases, the DNG files I have to handle have large-enough embedded previews and that's sufficient for my use-case.
But when it comes to actual processing of RAW data into a usable image, things get a lot more difficult and finding parameters which work across a wide range of RAW files is tough.
Thank you for the file sample.
Here is processing results: https://www.dropbox.com/scl/fi/ooqcaseziap0vwo5ario4/2023-11-11-003-Pano...
dcraw_emu command line used for that:
dcraw_emu -dngsdk -R 3145728 -T 2023-11-11 003-Pano.dngTechnical details:
LIBRAW_RAWOPTIONS_DNG_STAGE2_IFPRESENT/LIBRAW_RAWOPTIONS_DNG_STAGE3_IFPRESENTflags should be added toimgdata.rawparams.optionsThis is not perfect solution if one do not want to apply OpcodeList2/3 for all DNG files containing these tags.
To improve it: query decoder used via LibRaw::get_decoder_info() and set the flags only for jxl_dng_load_raw_placeholder() and/or lossy_dng_load_raw() decoders.
I have permission from the image owner and I have uploaded a sample image in a ZIP here:
Sample Image download (12 MB)
Please let me know which LibRaw setting or steps I need to perform to get rid of the color cast, if possible.
Or maybe I need to configure the Adobe DNG SDK host instance specifically?
All this is new to me and any help is appreciated.
You (probably) may receive tag values you want via exif callback: https://www.libraw.org/docs/API-datastruct-eng.html#libraw_callbacks_t and https://www.libraw.org/docs/API-CXX.html#exif
As mentioned on the this site homepage/LibRaw project description:
LibRaw RAW postprocessing (sample code) do not apply any custom aspect ratio change, although you may implement your own on processed image.
I have sent an email to the owner of the image and asked if I can provide it to you as an example.
I will post here when I have the permission and provide a download link.
It seems to use the JPXL compression, that's all I can tell so far.
It is usually pointless to discuss problems in processing a file without having the file itself
open_bayer() call is also available via C-API: https://www.libraw.org/docs/API-C.html
If your python wrapper does not provide access to this call: ask your vendor to add it.
This library is in C++, i have done all of my work in python. Is there any other alternative?
I have tried rawpy it doesn’t support .raw images from above mentioned camera
LibRaw::open_bayer will probably help.
When are you adding "Sony IMX490 imaging sensor (Bayer sensor, with a resolution of 2880 × 1856)" to the list. I need help with conversion of .raw file from this camera to 16-bit Tiff
It will in some future public update.
You can start with our free preview extractor:
https://www.fastrawviewer.com/RawPreviewExtractor
Forgive me for my ignorance, but can this snapshot be used in Windows to preview RAW files in the folder? How then?
Thanks
ILCE-7RM5 (A7-R5) support is provided by the latest snapshot: https://www.libraw.org/news/libraw-202403-snapshot
auto balance is based on the idea of a "average gray" world, which is not true for global colored scenes.
If you take a photo of a green grass, then the result of automatic white balance will not satisfy you too.
Than you so much for the quick response.
I didn't know FastRawViewer has it's own processing. That's interesting...
I too was able to achieve that image, but only after i manually switched the wb method.
Anyway, since i cant invest in a whole new post-processing infra at the moment, and considering your comment:
can you suggest a good way to detect said warm tints, so as to switch from auto to camera wb automatically, or is this something only human eye can detect and decern?
Pages