In fact, I did not perform any operations on the data.
int bitOffset = 2;
int out_height = 4024;
int out_width= 6024;
int out_rect.y = 0;
int out_rect.x = 0;
int dwBufLen = out_width * 3 * out_height;
unsigned char *szImgBuff = new (nothrow) unsigned char[dwBufLen];
unsigned short *pSrc = (unsigned short *)rawProcessor->imgdata.rawdata.raw_image;
if (!pSrc)
{
printf("error raw_image is null\n");
return false;
}
unsigned short *pDst = (unsigned short *)szImgBuff;
unsigned short *pDstPix = NULL;
unsigned short *pSrcPix = NULL;
pSrc += out_rect.y * raw_width + out_rect.x;
pDstPix = (unsigned short *)szImgBuff;
for (int y = 0; y < out_height; y++)
{
pSrcPix = pSrc;
pDstPix = pDst;
for (int x = 0; x < out_width; x++, pSrcPix++, pDstPix++)
{
*pDstPix = (*pSrcPix << bitOffset);
}
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 understand.
Yes, pixel values are above 16383 and this is normal for this type of files.
The original data already exceeds 16383,
Data:
======x:3078,y:1969,pSrcPix:16404,pDstPix:80
======x:3080,y:1969,pSrcPix:16404,pDstPix:80
======x:3082,y:1969,pSrcPix:16404,pDstPix:80
======x:3084,y:1969,pSrcPix:16404,pDstPix:80
======x:3086,y:1969,pSrcPix:16404,pDstPix:80
======x:3088,y:1969,pSrcPix:16404,pDstPix:80
======x:3073,y:1970,pSrcPix:16404,pDstPix:80
======x:3075,y:1970,pSrcPix:16404,pDstPix:80
======x:3077,y:1970,pSrcPix:16404,pDstPix:80
======x:3079,y:1970,pSrcPix:16404,pDstPix:80
======x:3081,y:1970,pSrcPix:16404,pDstPix:80
======x:3083,y:1970,pSrcPix:16404,pDstPix:80
======x:3085,y:1970,pSrcPix:16404,pDstPix:80
======x:2962,y:1971,pSrcPix:16404,pDstPix:80
======x:2964,y:1971,pSrcPix:16404,pDstPix:80
======x:2966,y:1971,pSrcPix:16404,pDstPix:80
======x:2968,y:1971,pSrcPix:16404,pDstPix:80
======x:2970,y:1971,pSrcPix:16404,pDstPix:80
======x:2972,y:1971,pSrcPix:16404,pDstPix:80
======x:2965,y:1972,pSrcPix:16404,pDstPix:80
I did not perform any operations on the data
Are you absolutely sure? What do you think the bitwise left shift operator does?
In fact, I did not perform any operations on the data.
int bitOffset = 2;
int out_height = 4024;
int out_width= 6024;
int out_rect.y = 0;
int out_rect.x = 0;
int dwBufLen = out_width * 3 * out_height;
unsigned char *szImgBuff = new (nothrow) unsigned char[dwBufLen];
unsigned short *pSrc = (unsigned short *)rawProcessor->imgdata.rawdata.raw_image;
if (!pSrc)
{
printf("error raw_image is null\n");
return false;
}
unsigned short *pDst = (unsigned short *)szImgBuff;
unsigned short *pDstPix = NULL;
unsigned short *pSrcPix = NULL;
pSrc += out_rect.y * raw_width + out_rect.x;
pDstPix = (unsigned short *)szImgBuff;
for (int y = 0; y < out_height; y++)
{
pSrcPix = pSrc;
pDstPix = pDst;
for (int x = 0; x < out_width; x++, pSrcPix++, pDstPix++)
{
*pDstPix = (*pSrcPix << bitOffset);
}
pSrc += raw_width;
pDst += out_width;
}
outfile.close();
FILE *fp1 = fopen("DSC07102", "wb+");
fwrite(szImgBuff, 1, dwBufLen, fp1);
fclose(fp1);
I think you need to remove data scaling from your code or adjust it based on real source data range, not any assumptions.
In this particular case: assuming that source data is within 0..2^14-1 range is incorrect.
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!
Pages