I stripped down the unprocessed_raw sample and achieved what I want (I think) by piping the output through a hash utility like sha256sum or xxh128sum.

Posting here in case it helps someone later:

#include <stdio.h>
#include "libraw/libraw.h"
int main(int ac, char *av[])
{
	LibRaw RawProcessor;
	int ret;  
	if ((ret = RawProcessor.open_file(av[1])) != LIBRAW_SUCCESS)  
	{
		fprintf(stderr, "Cannot open %s: %s\n", av[1], libraw_strerror(ret));  
		return 1;  
	}
	if ((ret = RawProcessor.unpack()) != LIBRAW_SUCCESS)  
	{
		fprintf(stderr, "Cannot unpack %s: %s\n", av[1], libraw_strerror(ret));  
		return 1;  
	}
	size_t bytes = RawProcessor.imgdata.sizes.raw_height * RawProcessor.imgdata.sizes.raw_pitch;  
	fwrite(RawProcessor.imgdata.rawdata.raw_alloc, sizeof(uint8_t), bytes, stdout);  
	fflush(stdout);
}

Compile with g++ rawbytes.cpp -o rawbytes -Ofast -lraw -lm.

You need to add libz (-lz) to your linker input

Thank you. This is helpful.

Thank you very much. This is all new to me but I'm eager to get into it.

One last question - I'm completely new to working with RAW processing, but I've been a coder for 25 years. Can you recommend any conceptual documentation or reference material that will help me understand RAW processing better? There are lots of search results, but if you have a recommended resource I would love to know about it. (Apologies if it's on page 1 of your documentation and I just missed it.)

Thanks again!

it looks like 'your file from another computer' is dynamically linked with libraw.23.dylib

We do not provide dynamic LibRaw for macOS, make -f Makefile.dist will also create static library only.

Please contact the 'file from another computer' vendor for libraw.23.dylib library

Sorry, we do not know how identify -verbose tool works. Is that possible that it checksums not RAW data but rendered image?

If you download a trial of RawDigger at https://www.rawdigger.com/download you can open a GH6 raw file now. RawDigger is a for-purchase product of LibRaw, correct (it says LibRaw LLC in the footer of the site page).

Any chance someone from LibRaw can answer the question, "if RawDigger now supports GH6, does that mean that a current or soon to be released update to LibRaw will have support for the GH6 .RW2 format?"

Hi,
I'm having the same issues with libraw. Processing X-Trans files takes much longer than processing Bayer files.
I'm using the C-API version "0.19.5-Release".
I used the default params (I don't now which interpolation algorithm it is using). I tried digging into the source code to see whats going on, but couldn't figure out what exactly takes that much time in the libraw_dcraw_process call.
Here a few logs:

Opening file: "test.RAF"
libraw_open_file: 2.4638ms
libraw_unpack: 331.530498ms
libraw_dcraw_process: 18.465117336s
libraw_dcraw_make_mem_image: 258.297201ms
tiff.write_image: 64.792601ms (not libraw-function)

Opening file: "test.CR2"
libraw_open_file: 3.3209ms
libraw_unpack: 657.3599ms
libraw_dcraw_process: 720.410201ms
libraw_dcraw_make_mem_image: 63.3256ms
tiff.write_image: 50.7873ms (not libraw-function)

Has anyone looked into this problem already?

Thanks in advance

Thank you. I understand.

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

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

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