lossy compression decoding

Does the lossy compression of Sony camera 7A support decoding


What specific Sony lossy

What specific Sony lossy compression variant you're asking about?

-- Alex Tutubalin @LibRaw LLC

First of all, I apologize for

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.

Hello, I don't seem to have

Hello, I don't seem to have found the button to upload files. Can you give me an email address?

The email has been

The email has been successfully sent.
Original file: DSC07102.ARW
Decoded Files: DSC07102 ,Decoding files can be opened using imagej. width x height 6024x4024

get unsigned short* pSrc =

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 RAW data histogram of

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

-- Alex Tutubalin @LibRaw LLC

This is RawDigger settings,

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.

-- Alex Tutubalin @LibRaw LLC

I think you need to remove

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.

-- Alex Tutubalin @LibRaw LLC

In fact, I did not perform

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;
FILE *fp1 = fopen("DSC07102", "wb+");
fwrite(szImgBuff, 1, dwBufLen, fp1);

I did not perform any

I did not perform any operations on the data

Are you absolutely sure? What do you think the bitwise left shift operator does?

-- Alex Tutubalin @LibRaw LLC

The original data already

The original data already exceeds 16383,

Yes, pixel values are above

Yes, pixel values are above 16383 and this is normal for this type of files.

-- Alex Tutubalin @LibRaw LLC