get unsigned short* pSrc = rawProcessor->imgdata.rawdata.raw_image, Loop through length and width, and offset pSrc by two bytes to the left. I will send a photo of the results to your email.
The email has been successfully sent.
Original file: DSC07102.ARW
Decoded Files: DSC07102 ,Decoding files can be opened using imagej. width x height 6024x4024
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...
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, I think I need to take a look RawDigger.
This is RawDigger settings, described in RD user manual.
If you use LibRaw's imgdata.rawdata.raw_image values: this is unaltered values, no scaling, no black subtraction.
And, indeed, data range for the file you sent is 0...16500, not 0....65535(and above), so please remove scaling from the code you use.
What do I need to do to open (black subtraction is on)
Sorry I didn't understand your question
(black subtraction is off) Will opening improve,How to open it ?
Here is RawDigger's 'Overexposure areas' with overexposure level set to 16383 (black subtraction is off), looks very similar to the photo you sent me: https://www.dropbox.com/s/y9he0u67dm1bgvs/Screenshot%202023-04-24%2012.0...
Here is RAW data histogram of the RAW image you sent: https://www.dropbox.com/s/bapkupc7bw3m220/Screenshot%202023-04-24%2012.0...
(black subtraction is turned off).
As you can see, the maximum value is 16500, slightly above 16383 (2^14-1)
If you scale data before recording by multiplying to 4 (to get 65535 range you mentioned above) this will result into 16-bit overflow.
If you do NOT scale data you'll never see ~65535 range because camera data range is (about) 0-2^14
get unsigned short* pSrc = rawProcessor->imgdata.rawdata.raw_image, Loop through length and width, and offset pSrc by two bytes to the left. I will send a photo of the results to your email.
Here is your file converted via dcraw_emu -T -w: https://www.dropbox.com/s/ipedoyrum83pfqp/DSC07102.ARW.tif?dl=0
I do not see any problem with decoding/rendering.
I do not know how your decoded file is created, have not seen into it, so could not comment.
The email has been successfully sent.
Original file: DSC07102.ARW
Decoded Files: DSC07102 ,Decoding files can be opened using imagej. width x height 6024x4024
You may use WeTransfer service/free option and send files to info@libraw.org
Hello, I don't seem to have found the button to upload files. Can you give me an email address?
Could you please share a RAW file sample?
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
Good to know, thanks.
Pages