Separate user here. To clarify, if I’m interested in having the ProfileGainTableMap processed (so images don’t come out underexposed), would building with the DNG SDK and setting these flags accomplish this? I’m currently trying (and failing) to get a build for this, so it’d be helpful to know before I spend more time getting it to build.
I tried to extract the full image and the left image from an dual pixel cr3 RAW file. I have used dcraw_emu.exe -r 1 1 1 1 -M -o 0 -4 -T -s 0 "example.cr3". With changing the -s from 0 to 1 i get the second image. But the imagesis already debayered. Is it possible to get the non debayered images?
ARW files are really TIFF(like)-containers, so all ARW-specific code is specific tag values parsing/assignment to internal data structures.
The main analysis is common to all tiffs.
>> 1st: R6 Mark II is not supported yet
I know and I mentioned in my original post
I do not doubt that libraw will support R6 Mark II sooner or later that is why I am ready to provide sample files and take part in testing if needed.
>> 2nd: your 2298 file is damaged
Probably it is and there are many other files from my R6m2 damanged in same way.
I mention "probably" because it looks strange:
* other software (DXO PureRaw, Adobe Photoshop, FastStone Image Viewer) works with this file fine
* I took and processed thousands of images from this camera already and I got no issues until I tried to take astro images and load in into Siril
* I have many more samples of random files from the camera that are "damaged" (and could be processed fine with other software).
you can try to use FastRawViewer and see what per-channels multipliers "they" suggest ( that is assuming EasyHDR uses the same approach as FRV), then you can adjust as shot WB tag in DNG using exiftool or so and feed it to ACR/LR and use as shot WB there ... ___BUT___ the same colors of course is a different story because the whole color transform is more than just the WB ...
There is no reason to integrate w/ libjxl, because Adobe DNG SDK is already integrated (it is free and BSD-licensed, there are no reasons against using it).
Also, libjxl integration is not enough, such DNG files may need full opcode processing not only Stage1 (provided by LibRaw).
The file also contains absolutely black preview.
Adobe DNG Converter converts it to absolutely black DNG file.
zip compresses it into 300k zipfile (1:100 compression ratio)
Are you sure the file is not completely black, but contains some image?
There is a FFDShow add-on for the new JPEG-XS on GitHub, but I guess it won't read the .nef files. Or looking at it, might even introduce licensing problems? :-)
But how are you coming along? If you need sample files, I am happy to provide (Z8 files).
Sorry, but I don’t understand what exactly your problem is.
.a files are meant to be (statically) linked to your application, what do you mean for "does not remain accessible"? Accessible for what?
In any case, you can build the library as a shared one
Using any internal (non-documented) fields in a class may lead to a rewrite of your application when the next version of the library is released. We treat public/documented fields much more carefully (although there is no complete guarantee that they will never change).
However, internal fields are declared as protected:, not private: (specifically for the case you described), so you can implement your own derived class that will provide the necessary access from the outside
DNG SDK Applies ProfileGainTableMap in dng_renderer (RAW to RGB conversion), not in stage3 opcodes.
Separate user here. To clarify, if I’m interested in having the ProfileGainTableMap processed (so images don’t come out underexposed), would building with the DNG SDK and setting these flags accomplish this? I’m currently trying (and failing) to get a build for this, so it’d be helpful to know before I spend more time getting it to build.
To extract unprocessed data use unprocessed_raw sample
I tried to extract the full image and the left image from an dual pixel cr3 RAW file. I have used dcraw_emu.exe -r 1 1 1 1 -M -o 0 -4 -T -s 0 "example.cr3". With changing the -s from 0 to 1 i get the second image. But the imagesis already debayered. Is it possible to get the non debayered images?
What exactly are you doing and how and what are you failing at?
ARW files are really TIFF(like)-containers, so all ARW-specific code is specific tag values parsing/assignment to internal data structures.
The main analysis is common to all tiffs.
Please check with Adobe DNG Converter and select files that processed OK by this program, but damaged in LibRaw.
>> 1st: R6 Mark II is not supported yet
I know and I mentioned in my original post
I do not doubt that libraw will support R6 Mark II sooner or later that is why I am ready to provide sample files and take part in testing if needed.
>> 2nd: your 2298 file is damaged
Probably it is and there are many other files from my R6m2 damanged in same way.
I mention "probably" because it looks strange:
* other software (DXO PureRaw, Adobe Photoshop, FastStone Image Viewer) works with this file fine
* I took and processed thousands of images from this camera already and I got no issues until I tried to take astro images and load in into Siril
* I have many more samples of random files from the camera that are "damaged" (and could be processed fine with other software).
So, let me know if you need file samples.
1st: R6 Mark II is not supported yet
2nd: your 2298 file is damaged. Adobe DNG Converter also agrees with this: https://www.dropbox.com/scl/fi/s19zw6bylther2fvh6cyp/Screenshot-2024-03-...
you can try to use FastRawViewer and see what per-channels multipliers "they" suggest ( that is assuming EasyHDR uses the same approach as FRV), then you can adjust as shot WB tag in DNG using exiftool or so and feed it to ACR/LR and use as shot WB there ... ___BUT___ the same colors of course is a different story because the whole color transform is more than just the WB ...
Sorry, we're not responsible for Adobe apps. Please direct your request to Adobe's support
yes, you probably need to add ws2_32 to your linker input.
There is no reason to integrate w/ libjxl, because Adobe DNG SDK is already integrated (it is free and BSD-licensed, there are no reasons against using it).
Also, libjxl integration is not enough, such DNG files may need full opcode processing not only Stage1 (provided by LibRaw).
Try to remove
QMAKE_CXXFLAGS+=/MP
(Visual Studio specific flag)
from buildfiles/libraw-common-lib.pro
Is there a reason for using the DNG SDK instead of directly integrating with libjxl?
Would a pull request that attempted to support the libjxl path instead as an option be accepted, just like libjpeg8 is an optional library?
I'm thinking of taking a crack at support via libjxl, but don't want the effort to be redundant.
happy to provide any Z9 RAW file samples if you need them.
Thanks for the great project.
You're right (previous reply deleted), -N is not handled in code. To be removed from help line in future release.
Thanks - I will recheck.
The file also contains absolutely black preview.
Adobe DNG Converter converts it to absolutely black DNG file.
zip compresses it into 300k zipfile (1:100 compression ratio)
Are you sure the file is not completely black, but contains some image?
1) We're aware
2) Yes it will be supported
3) It will be supported via Adobe DNG SDK Integration
There is a FFDShow add-on for the new JPEG-XS on GitHub, but I guess it won't read the .nef files. Or looking at it, might even introduce licensing problems? :-)
But how are you coming along? If you need sample files, I am happy to provide (Z8 files).
Thank you very much for the reply. Hopefully this is what I'm looking for.
All the best.
Assuming you're talking about OpcodeList#, not ProfileGainTableMap (introduced in DNG 1.6).
If LibRaw is compiled with Adobe DNG SDK: it is possible to process via DNG Stage2/Stage3 by specifying corresponding rawoption bits:
Process Stage2/3 only if OpcodeList2/3 present: LIBRAW_RAWOPTIONS_DNG_STAGE2_IFPRESENT,LIBRAW_RAWOPTIONS_DNG_STAGE3_IFPRESENT
Forced Stage2/3 processing: LIBRAW_RAWOPTIONS_DNG_STAGE2 and
LIBRAW_RAWOPTIONS_DNG_STAGE3
If one want to extract specific DNG/TIFF/EXIF tags: use exifparser_handler to setup own callback function.
Sorry, but I don’t understand what exactly your problem is.
.a files are meant to be (statically) linked to your application, what do you mean for "does not remain accessible"? Accessible for what?
In any case, you can build the library as a shared one
Using any internal (non-documented) fields in a class may lead to a rewrite of your application when the next version of the library is released. We treat public/documented fields much more carefully (although there is no complete guarantee that they will never change).
However, internal fields are declared as protected:, not private: (specifically for the case you described), so you can implement your own derived class that will provide the necessary access from the outside
Pages