Undefined symbols for architecture x86_64:
"_uncompress", referenced from:
LibRaw::deflate_dng_load_raw() in libraw.a(fp_dng.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1
I also tried using -lraw instead of adding the full path name to libraw.a still got the same error
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.)
Yes, one of *image pointer in libraw_rawdata_t will be non-zero after LibRaw::unpack() and will contain imgdata.sizes.raw_height rows, imgdata.sizes.raw_width items each, with imgdata.sizes.raw_pitch byte pitch.
Ahh thanks, I think you just helped me understand something.
I haven't checked, but I'm almost certain you're right about it using the rendered image. My understanding is that ImageMagick delegates all the decoding to libraw, libjpeg, libtiff, libpng, etc., and in my case it doesn't necessarily know it's dealing with a RAW image by the time it creates the signature.
So let's say I wanted to write my own signature program using LibRaw that only operates on the image data, leaving the metadata completely out of it. After a quick look at the API, my best guess is that I'd want to hash the contents of libraw_rawdata_t. Does that sound right?
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:
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);
}
So I tried building my program again using the libraw 0.21.1 binaries provided for macos..
I used the command
g++ --std=c++17 -I/Users/aayush/Downloads/LibRaw-0.21.1/libraw -L/Users/aayush/Downloads/LibRaw-0.21.1/lib base64.cpp Server-mac.cpp -o Ninja -lm /Users/aayush/Downloads/LibRaw-0.21.1/lib/libraw.a
and I seem to get the following error
Undefined symbols for architecture x86_64:
"_uncompress", referenced from:
LibRaw::deflate_dng_load_raw() in libraw.a(fp_dng.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1
I also tried using -lraw instead of adding the full path name to libraw.a still got the same error
Thank you. This is helpful.
It is difficult to recommend any specific document/site. May be 'dcraw annotated' will help: https://ninedegreesbelow.com/files/dcraw-c-code-annotated-code.html
(at least, LibRaw postprocessing is derived from dcraw.c code, so this specific document is applicable to LibRaw::dcraw_process() code)
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!
Yes, one of *image pointer in libraw_rawdata_t will be non-zero after LibRaw::unpack() and will contain imgdata.sizes.raw_height rows, imgdata.sizes.raw_width items each, with imgdata.sizes.raw_pitch byte pitch.
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
Ahh thanks, I think you just helped me understand something.
I haven't checked, but I'm almost certain you're right about it using the rendered image. My understanding is that ImageMagick delegates all the decoding to libraw, libjpeg, libtiff, libpng, etc., and in my case it doesn't necessarily know it's dealing with a RAW image by the time it creates the signature.
So let's say I wanted to write my own signature program using LibRaw that only operates on the image data, leaving the metadata completely out of it. After a quick look at the API, my best guess is that I'd want to hash the contents of libraw_rawdata_t. Does that sound right?
Sorry, we do not know how identify -verbose tool works. Is that possible that it checksums not RAW data but rendered image?
We'll release LibRaw with GH6 support on schedule: https://www.libraw.org/#updatepolicy
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?"
> Processing X-Trans files takes much longer than processing Bayer files.
This is expected. If lower quality is acceptable for your task you may switch from (default) 3-pass Markesteijn to 1-pass or to linear approximation.
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
How can I install this library on Android Studio? What documents or folders should I copy or import?
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...
Pages