First of all, I apologize for not seeing your reply in a timely manner,I am using compressed RAW format photos from Sony a7.
After decoding, some of the data exceeds 65535, and strange black spots will appear in the photos afterwards.
If you are an end user of some application that uses LibRaw, then you can try to create user pressure on your vendor to take advantage of the early access option
The page says "if our RawDigger announced at our blog, https://www.rawdigger.com/news, supports the camera / format, that's because LibRaw supports it."
The rawdigger news said it supported the GH6, but libraw apparently doesn't. Are you really saying that there won't be an update to support the GH6 until at least 1.5years from the latest major release of libraw, which will be mid-2024 at the earliest? The camera will be over 2 years old by that point...
What specific Sony lossy compression variant you're asking about?
LibRaw provides vendor crops as described in my 1st reply: https://www.libraw.org/comment/6618#comment-6618
Thanks for looking into this so quickly, I still think the crop should match the metadata in the file, then the returned data would match the jpeg the camera produces as well as other apps etc. but as you say, there is real picture info there, and the choice is yours!
Thank you for sample files; downloaded, you may remove them to clean up google drive space.
The 6742x4498 crop looks correct, no black/white borders on image: https://www.dropbox.com/s/ugnygdg8gp7dpx5/Screenshot%202023-04-16%201529...
Here's a link to a folder with some sample files. https://drive.google.com/drive/folders/1DwMJFINzWfmGnCNYz7FptMZ74m5u8439...
Note the first 3 files are basically black, last 2 are 'real' photos.
The Camera is just a Canon R with a modified infra-red cut filter, apart from the name change, the files should look exactly like Canon R files
We do not have sample files from EOS Ra camera (so this camera not listed as 'supported'), could you please provide several ones?
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
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.