Recent comments

Reply to: lossy compression decoding   1 year 1 month ago

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

Reply to: lossy compression decoding   1 year 1 month ago

I did not perform any operations on the data

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

Reply to: lossy compression decoding   1 year 1 month ago

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);

Reply to: lossy compression decoding   1 year 1 month ago

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.

Reply to: lossy compression decoding   1 year 1 month ago

Thank you, I think I need to take a look RawDigger.

Reply to: lossy compression decoding   1 year 1 month ago

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.

Reply to: lossy compression decoding   1 year 1 month ago

What do I need to do to open (black subtraction is on)

Reply to: lossy compression decoding   1 year 1 month ago

Sorry I didn't understand your question

Reply to: lossy compression decoding   1 year 1 month ago

(black subtraction is off) Will opening improve,How to open it ?

Reply to: lossy compression decoding   1 year 1 month ago

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...

Reply to: lossy compression decoding   1 year 1 month ago

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

Reply to: lossy compression decoding   1 year 1 month ago

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.

Reply to: lossy compression decoding   1 year 1 month ago

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.

Reply to: lossy compression decoding   1 year 1 month ago

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

Reply to: lossy compression decoding   1 year 1 month ago

You may use WeTransfer service/free option and send files to info@libraw.org

Reply to: lossy compression decoding   1 year 1 month ago

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

Reply to: lossy compression decoding   1 year 1 month ago

Could you please share a RAW file sample?

Reply to: lossy compression decoding   1 year 1 month ago

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.

Reply to: LibRaw 0.21 supported cameras   1 year 1 month ago

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

Reply to: LibRaw 0.21 supported cameras   1 year 1 month ago

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...

Reply to: lossy compression decoding   1 year 1 month ago

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

Reply to: Canon CR3 file - returning wrong image size?   1 year 1 month ago

LibRaw provides vendor crops as described in my 1st reply: https://www.libraw.org/comment/6618#comment-6618

Reply to: Canon CR3 file - returning wrong image size?   1 year 1 month ago

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!

Reply to: Canon CR3 file - returning wrong image size?   1 year 1 month ago

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...

Reply to: Canon CR3 file - returning wrong image size?   1 year 1 month ago

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

Pages