Alex,
I also added a T4iExample.CR2 to the dropbox share. The method I last suggested works without the LibRaw::unpack() call. My need for a valid black level is only required if the user does not wish to calibrate their astro images using BIAS frames. These BIAS frames are images shot with the lens cap on and at the fastest shutter speed of the camera. They are very easy to generate and they act as pixel-by-pixel black level references. A valid black level is vital for astro image calibration...especially for what is called FLAT frames so having the user resort to using the black level values we are discussing here is essentially a simplified estimate.
Alex,
I did try using the cblack[] values but they also were zero. I did find that the Canon.ChannelBlackLevel[] values were populated. I am going to check all three (imgdata.color.black, imgdata.color.cblack[] and Canon.ChannelBlackLevel[]). The first non-zero value I find will dictate what value I use. Do you agree?
The problem was related with openCV not rawpy or libraw. OpenCV uses BGR format,not RGB. so when i used cv2.imshow() after debayering using libraw , the colors swapped in R and B channel.
Sloution: convert RGB matrix to BGR before using cv2.imshow(). Open CV has a builtin function to do so, cv2.cvtColor(img, cv2.COLOR_RGB2BGR)
Under Windows:
The problem may relate to FILE* pointer:
- you create one in your code (using runtime you specify on linking your code)
- and pass it to libjpeg.dll
You need to make sure that libjpeg.dll uses same runtime version with same FILE* structure layout.
(the problem is windows-specific, on Linux/Unix and Mac FILE* is handled by the single system runtime)
Thanks a lot for your support! This works. Somehow my code didn't work with release-DLL version, VCRT kept giving errors. However, it works nice with static lib or debug build. Go figure! :)
Again, thanks for your help. It gave me the assurance that I was on the right path.
I had the libraw-package of my distribution installed and g++ seams to find the files first, where the package-manager has put them. Deinstalling the package resolved the error. Everything works as expected now.
I could not see what exceptions you get.
This snippet, created from your code (removed _putenv, _snprintf_s replaced w/ simple sprintf) compiles and converts single ARW file to jpeg: https://www.dropbox.com/s/1lq7npmuip2xne5/raw2jpeg.zip?dl=0
example.txt cut to write function only (JPEG read complains about put_scanline_someplace, so entire JPEG reading code removed).
Needed #includes added to example.txt and main (stdlib.h)
Compiled/tested under FreeBSD (under Linux is should be the same) using this command line:
clang -I/usr/local/include -I../LibRaw -o raw2jpeg main.cpp example.cpp -L/usr/local/lib -ljpeg -L../LibRaw/lib -lraw -lcxxrt
libjpeg-turbo 2.0.2 is installed in /usr/local
LibRaw is compiled in ../LibRaw
Do you see any glaring errors? Thanks a lot in advance!
int main(int ac, char* av[])
{
int ret;
char outfn[1024];
LibRaw RawProcessor;
_putenv((char*)"TZ=UTC"); // dcraw compatibility, affects TIFF datestamp field
#define P1 RawProcessor.imgdata.idata
#define S RawProcessor.imgdata.sizes
#define C RawProcessor.imgdata.color
#define T RawProcessor.imgdata.thumbnail
#define P2 RawProcessor.imgdata.other
#define OUT RawProcessor.imgdata.params
OUT.output_bps = 8;
if ((ret = RawProcessor.open_file(av[1])) != LIBRAW_SUCCESS)
return 1;
if ((ret = RawProcessor.unpack()) != LIBRAW_SUCCESS)
return 1;
ret = RawProcessor.dcraw_process();
if (LIBRAW_SUCCESS != ret)
if (LIBRAW_FATAL_ERROR(ret))
return 1;
libraw_processed_image_t* image = RawProcessor.dcraw_make_mem_image(&ret);
if (LIBRAW_SUCCESS != ret)
if (LIBRAW_FATAL_ERROR(ret))
return 1;
imgdata.params.bright options affects only output (gamma) curve that used on (internal) linear data -> gamma corrected output. Is is very similar to Photoshop curve tool w/ linear curve that starts at 0,0 and ends, for example, at 100,255 (source, dest)
To adjust exposure one may use exp_correc/exp_shift/exp_preserve parameters.
Sorry, there is no way to provide getters for all points in LibRaw that may be need by user (user's code)
(and, also, maintain this when LibRaw internals get changed).
C-wrappers are trivial, you may implement your own via banal copy/paste/change accessed field name.
Alex,
I don't know how to program in C or C++. I rely on being able to access LibRaw using either the C getters/putters or an executable. Accessing the libraw_rawdata_t structure is not available via the C getters/putters.
It looks like your problem is different from 'no way to set output_tiff=1 via C-API':
- LibRaw internals are different from dcraw's while we keep some compatibility via dcraw_emu sample
- in particular, there is no document_mode (-d/-D options in dcraw), because unaltered raw data is already accessible via https://www.libraw.org/docs/API-datastruct.html#libraw_rawdata_t
So, it looks like you need to implement direct access to this data from your app (I'm not sure you need intermediate TIFF storage because data is already here).
Alex,
I should have explained that I program in a language call LabVIEW. It has very limited ability to interact with LibRaw. The only method available is to use calls to the dll which is why I am trying to use the C setter/getters. If I could determine the pointer to the libraw_output_params_t structure I might be able to write to the structure but I see a long road ahead of me if I go down that road.
I need access to the RAW RGGB data for my astronomy image calibration application which I had based on
"DCRAW -v -D -4 -T filename" and am now trying to migrate to LibRaw. I suspect the quickest way for me to proceed is to use the example 4channels.exe. Do you agree or it there another way to proceed?
Unless you want to survive ABI change (e.g. libraw.dll/.so upgrade to very different version), you do not need setter.
Look into half_mt.c sample how to set fields in params w/o setter.
Yes I know: I wrote “understand” instead of “guess”, because I was trying to fix the thing in one time, instead of by instalments . Then:
I’ve read that a raw file stores exposition (E) values linearly, and that a GAMMA function can be applied to them during raw conversion in order to increase the range of pixel values in the lower zones of exposition. This last result can be achieved if E values have not yet been rounded to nearest integers, otherwise the GAMMA application adds no information about these zones. As a first step, could you tell whether or not you agree on this point?
X-Pro3 is supported in current snapshot.
Black level calculated based on real black frame data (we consider/is) more accurate (compared to metadata values)
Alex,
I also added a T4iExample.CR2 to the dropbox share. The method I last suggested works without the LibRaw::unpack() call. My need for a valid black level is only required if the user does not wish to calibrate their astro images using BIAS frames. These BIAS frames are images shot with the lens cap on and at the fastest shutter speed of the camera. They are very easy to generate and they act as pixel-by-pixel black level references. A valid black level is vital for astro image calibration...especially for what is called FLAT frames so having the user resort to using the black level values we are discussing here is essentially a simplified estimate.
Peter
Thanks (I needed to look in the debugger to remember)
For (most/some) Canon files, black level is calculated based on dark frame values. So, it is only available after LibRaw::unpack() call
Alex,
Here is a dropbox link to a T5i and a T7i RAW file
Peter
https://www.dropbox.com/sh/qn0j23qun6gbuoo/AAB0aoKOhpzHchFar2Z4WKDsa?dl=0
Could you please share raw sample?
Alex,
I did try using the cblack[] values but they also were zero. I did find that the Canon.ChannelBlackLevel[] values were populated. I am going to check all three (imgdata.color.black, imgdata.color.cblack[] and Canon.ChannelBlackLevel[]). The first non-zero value I find will dictate what value I use. Do you agree?
Peter
You need to use both black and cblack[] values: https://www.libraw.org/docs/API-datastruct.html#libraw_colordata_t
The problem was related with openCV not rawpy or libraw. OpenCV uses BGR format,not RGB. so when i used cv2.imshow() after debayering using libraw , the colors swapped in R and B channel.
Sloution: convert RGB matrix to BGR before using cv2.imshow(). Open CV has a builtin function to do so, cv2.cvtColor(img, cv2.COLOR_RGB2BGR)
Could you please share raw file?
Under Windows:
The problem may relate to FILE* pointer:
- you create one in your code (using runtime you specify on linking your code)
- and pass it to libjpeg.dll
You need to make sure that libjpeg.dll uses same runtime version with same FILE* structure layout.
(the problem is windows-specific, on Linux/Unix and Mac FILE* is handled by the single system runtime)
Thanks a lot for your support! This works. Somehow my code didn't work with release-DLL version, VCRT kept giving errors. However, it works nice with static lib or debug build. Go figure! :)
Again, thanks for your help. It gave me the assurance that I was on the right path.
I got it solved by myself:
I had the libraw-package of my distribution installed and g++ seams to find the files first, where the package-manager has put them. Deinstalling the package resolved the error. Everything works as expected now.
I could not see what exceptions you get.
This snippet, created from your code (removed _putenv, _snprintf_s replaced w/ simple sprintf) compiles and converts single ARW file to jpeg: https://www.dropbox.com/s/1lq7npmuip2xne5/raw2jpeg.zip?dl=0
example.txt cut to write function only (JPEG read complains about put_scanline_someplace, so entire JPEG reading code removed).
Needed #includes added to example.txt and main (stdlib.h)
Compiled/tested under FreeBSD (under Linux is should be the same) using this command line:
clang -I/usr/local/include -I../LibRaw -o raw2jpeg main.cpp example.cpp -L/usr/local/lib -ljpeg -L../LibRaw/lib -lraw -lcxxrt
libjpeg-turbo 2.0.2 is installed in /usr/local
LibRaw is compiled in ../LibRaw
It looks like it is simpler to implement it for one time in one of libraw samples: https://github.com/LibRaw/LibRaw/commit/52b7066b3ed285ed84c20a2442c59331...
Thank you very much for your help! I feel like I am close, but I am still getting an exception at
write_JPEG_file(outfn, 10);
This is the same function as in libjpeg-turbo example. (https://github.com/libjpeg-turbo/libjpeg-turbo/blob/master/example.txt)
Do you see any glaring errors? Thanks a lot in advance!
int main(int ac, char* av[])
{
int ret;
char outfn[1024];
LibRaw RawProcessor;
_putenv((char*)"TZ=UTC"); // dcraw compatibility, affects TIFF datestamp field
#define P1 RawProcessor.imgdata.idata
#define S RawProcessor.imgdata.sizes
#define C RawProcessor.imgdata.color
#define T RawProcessor.imgdata.thumbnail
#define P2 RawProcessor.imgdata.other
#define OUT RawProcessor.imgdata.params
OUT.output_bps = 8;
if ((ret = RawProcessor.open_file(av[1])) != LIBRAW_SUCCESS)
return 1;
if ((ret = RawProcessor.unpack()) != LIBRAW_SUCCESS)
return 1;
ret = RawProcessor.dcraw_process();
if (LIBRAW_SUCCESS != ret)
if (LIBRAW_FATAL_ERROR(ret))
return 1;
libraw_processed_image_t* image = RawProcessor.dcraw_make_mem_image(&ret);
if (LIBRAW_SUCCESS != ret)
if (LIBRAW_FATAL_ERROR(ret))
return 1;
_snprintf_s(outfn, sizeof(outfn), "%s.jpeg", av[1]);
image_height = image->height;
image_width = image->width;
image_buffer = (JSAMPLE*)image->data;
write_JPEG_file(outfn, 10);
LibRaw::dcraw_clear_mem(image);
RawProcessor.recycle(); // just for show this call
return 0;
}
imgdata.params.bright options affects only output (gamma) curve that used on (internal) linear data -> gamma corrected output. Is is very similar to Photoshop curve tool w/ linear curve that starts at 0,0 and ends, for example, at 100,255 (source, dest)
To adjust exposure one may use exp_correc/exp_shift/exp_preserve parameters.
use
libraw_processed_image_t *image = RawProcessor.dcraw_make_mem_image(&ret);
to make 3-channel RGB image (output_bps should be set to 8 for JPEG)
and
LibRaw::dcraw_clear_mem(image);
to clean (deallocate) libraw_processed_image_t after JPEG creation is done.
Sorry, there is no way to provide getters for all points in LibRaw that may be need by user (user's code)
(and, also, maintain this when LibRaw internals get changed).
C-wrappers are trivial, you may implement your own via banal copy/paste/change accessed field name.
Alex,
I don't know how to program in C or C++. I rely on being able to access LibRaw using either the C getters/putters or an executable. Accessing the libraw_rawdata_t structure is not available via the C getters/putters.
Peter
It looks like your problem is different from 'no way to set output_tiff=1 via C-API':
- LibRaw internals are different from dcraw's while we keep some compatibility via dcraw_emu sample
- in particular, there is no document_mode (-d/-D options in dcraw), because unaltered raw data is already accessible via https://www.libraw.org/docs/API-datastruct.html#libraw_rawdata_t
So, it looks like you need to implement direct access to this data from your app (I'm not sure you need intermediate TIFF storage because data is already here).
Alex,
I should have explained that I program in a language call LabVIEW. It has very limited ability to interact with LibRaw. The only method available is to use calls to the dll which is why I am trying to use the C setter/getters. If I could determine the pointer to the libraw_output_params_t structure I might be able to write to the structure but I see a long road ahead of me if I go down that road.
I need access to the RAW RGGB data for my astronomy image calibration application which I had based on
"DCRAW -v -D -4 -T filename" and am now trying to migrate to LibRaw. I suspect the quickest way for me to proceed is to use the example 4channels.exe. Do you agree or it there another way to proceed?
Unless you want to survive ABI change (e.g. libraw.dll/.so upgrade to very different version), you do not need setter.
Look into half_mt.c sample how to set fields in params w/o setter.
Yes I know: I wrote “understand” instead of “guess”, because I was trying to fix the thing in one time, instead of by instalments . Then:
I’ve read that a raw file stores exposition (E) values linearly, and that a GAMMA function can be applied to them during raw conversion in order to increase the range of pixel values in the lower zones of exposition. This last result can be achieved if E values have not yet been rounded to nearest integers, otherwise the GAMMA application adds no information about these zones. As a first step, could you tell whether or not you agree on this point?
my reply says nothing about gamma
Pages