Also: the message you quoted is from unprocessed_raw sample code. This sample, yes, supports bayer only (we're open to patches if someone want to complete this sample)
"Only Bayer-pattern RAW files supported, sorry...."
Recent Samsung DNGs are not CFA, but "enhanced" 3-channel LinerRaw (like recent Apple iPhone ProRAW), and w/ ljpeg compression using restart markers...
Recent Samsung models started putting out the "less" normal DNGs - the ljpeg compression is not a single stream, but has restart markers, don't know if LibRaw supports that...
Yes, RawDigger relies on LibRaw imgdata.idata.filters to get CFA layout. Also, if LibRaw CFA pattern/layout detection is wrong it will result into a wrong rendering.
thank you for your swift reply. OK, I understand. I mainly use MATLAB (R2022a) -which uses LibRaw- but encountered the issue of not being able to open GPR files. That is why I started to delve into the LibRaw *.exe files. So I will wait until the next MATLAB release (R2023a). Maybe they then support GoPro's GPR files.
As for metadata, I use Exiftool extensively but found the MATLAB implementation of getting RAW metadata (again using LibRaw) faster than my code (which also needs to call Exiftool). However, for a Nikon P6000 file, the CFA layout delivered by MATLAB is different from the one given in Exiftool. And since I also have RAWdigger and see that the individual channels are displayed correctly, I wondered where the error comes from. That was my reason to ask if there would be a LibRaw *.exe file to extract metadata.
If it would be a LibRaw error, then RAWdigger would display the channels wrongly, I guess. But also a MATLAB error seems strange as they use LibRaw.
If you want, I could send you the file. Many thanks for what you do and for spreading your knowledge!
Cheers
What metadata you're asking for? Probably it is better to use exiftool for it.
Providing LibRaw binaries with 3rd-party decoders/decompressors compiled in (libjpeg, libdeflate/libz, libjasper, Adobe DNG SDK, GoPro SDK) may result into 3rd-party libraries version conflicts: for example LibRaw uses libjpeg-turbo, while calling applications is linked with standard jpeg libraries.
So, the developer who uses LibRaw should select LibRaw configuration and 3rd-party libraries used.
In general: LibRaw is for developers, not for end-users, provided samples are samples only to demonstrate LibRaw abilities.
Tried to test the functionality standalone, meanwhile measuring each function run time.
For Windows, the numbers are more or less the same, but for macOS, the same code runs 4 times slower with the 0.20.2 version.
The only function which has a significant time difference is `proc.dcraw_process()`, which as I said is 4 times slower than on the v19.2 version. The problem is reproducible only on macOS.
Yes, of course I understand the issue of partial support. But nevertheless it doesn't make sense to pass a raw to LibRaw for decoding when the camera's not supported. So while the camera list isn't perfect (and I do understand that), in the absence of any other means to make that determination, that's what I have to do.
Clearly if there's the possibility of a better solution that could be implemented in the future, I'd be very happy to use that.
OK I can fix it like that but surely it should return the "visible" sensor area?
It is cropping off the left / top sensor margin correctly, why return the invalid data from the right/bottom margin?
LibRaw tries to extract as much image as possible, so 'match with other apps' is not default.
If one prefers vendor crop(s), please take look at (v 0.21):
1) imgdata.sizes.raw_inset_crops https://www.libraw.org/docs/API-datastruct-eng.html#libraw_image_sizes_t
2) And LibRaw::adjust_to_raw_inset_crop(..) call https://www.libraw.org/docs/API-CXX.html#adjust_to_raw_inset_crop
Good to know, thanks.
dcraw_emu records tiff/ppm without problems.
unprocessed_raw sample code (not the library itself, but sample!) supports bayer only.
Thanks, so unpacking works, it's writing out to TIFF/PPM that doesn't.
Followup: I do not see any decoding problems with this file: https://raw.pixls.us/getfile.php/6433/nice/Samsung%20-%20Galaxy%20S23%20...
(as expected: we have several samples from latest Samsungs and no known problems w/ raw decoding)
Checked with dcraw_emu [filename]
Also: the message you quoted is from unprocessed_raw sample code. This sample, yes, supports bayer only (we're open to patches if someone want to complete this sample)
Could you please provide specific file link, not entire archive?
See https://raw.pixls.us for samples. LibRaw stops w/
"Only Bayer-pattern RAW files supported, sorry...."
Recent Samsung DNGs are not CFA, but "enhanced" 3-channel LinerRaw (like recent Apple iPhone ProRAW), and w/ ljpeg compression using restart markers...
The discussion will only make sense if specific problematic files are included.
At the moment, we do not have a single example of a file from Samsung on which RAW data would not be unpacked by LibRaw.
Recent Samsung models started putting out the "less" normal DNGs - the ljpeg compression is not a single stream, but has restart markers, don't know if LibRaw supports that...
AFAIK, Samsung phones records more-or-less (*) normal DNG, so already supported
(*) some DNG files from latest Samsung devices contains incorrect thumnail data (while RAW data is OK)
This file looks damaged: it contents does not pass bounds checks in samsung3_load_raw; disabling this checks not results into correct image.
All other samples from Samsung NX500 camera we have are processed OK.
Use open_file() or open_buffer() and check the return code.
Thanks
LibRaw is dual-licensed (LGPL 2.1 and CDDL-1), I do not see any problems from our side to use LibRaw under the terms of one of these licenses.
Could you clarify what exactly is your question?
as per update policy: https://www.libraw.org/#updatepolicy
Yes, RawDigger relies on LibRaw imgdata.idata.filters to get CFA layout. Also, if LibRaw CFA pattern/layout detection is wrong it will result into a wrong rendering.
Sorry, no not know how Matlab uses LibRaw.
Dear Alex,
thank you for your swift reply. OK, I understand. I mainly use MATLAB (R2022a) -which uses LibRaw- but encountered the issue of not being able to open GPR files. That is why I started to delve into the LibRaw *.exe files. So I will wait until the next MATLAB release (R2023a). Maybe they then support GoPro's GPR files.
As for metadata, I use Exiftool extensively but found the MATLAB implementation of getting RAW metadata (again using LibRaw) faster than my code (which also needs to call Exiftool). However, for a Nikon P6000 file, the CFA layout delivered by MATLAB is different from the one given in Exiftool. And since I also have RAWdigger and see that the individual channels are displayed correctly, I wondered where the error comes from. That was my reason to ask if there would be a LibRaw *.exe file to extract metadata.
If it would be a LibRaw error, then RAWdigger would display the channels wrongly, I guess. But also a MATLAB error seems strange as they use LibRaw.
If you want, I could send you the file. Many thanks for what you do and for spreading your knowledge!
Cheers
What metadata you're asking for? Probably it is better to use exiftool for it.
Providing LibRaw binaries with 3rd-party decoders/decompressors compiled in (libjpeg, libdeflate/libz, libjasper, Adobe DNG SDK, GoPro SDK) may result into 3rd-party libraries version conflicts: for example LibRaw uses libjpeg-turbo, while calling applications is linked with standard jpeg libraries.
So, the developer who uses LibRaw should select LibRaw configuration and 3rd-party libraries used.
In general: LibRaw is for developers, not for end-users, provided samples are samples only to demonstrate LibRaw abilities.
Tested (w/ full recompile for both 0.19 and 0.21) and unable to reproduce.
dcraw_process() is only a glue for other functions in processing pipeline, please narrow your search to specific function or code lines.
Hi,
Tried to test the functionality standalone, meanwhile measuring each function run time.
For Windows, the numbers are more or less the same, but for macOS, the same code runs 4 times slower with the 0.20.2 version.
The only function which has a significant time difference is `proc.dcraw_process()`, which as I said is 4 times slower than on the v19.2 version. The problem is reproducible only on macOS.
Any thoughts about this?
Thanks in advance.
Hrach Martirosyan
Yes, of course I understand the issue of partial support. But nevertheless it doesn't make sense to pass a raw to LibRaw for decoding when the camera's not supported. So while the camera list isn't perfect (and I do understand that), in the absence of any other means to make that determination, that's what I have to do.
Clearly if there's the possibility of a better solution that could be implemented in the future, I'd be very happy to use that.
All the best
Counterquestion:
we list Nikon Z9 as
"Nikon Z 9 (HE/HE* formats are not supported yet)",
Is Z9 supported or not?
Pages