thank you for your reply Alex! Cleared up some stuff and I'm somehow happy that unpack already applies the curve.
Regarding 1): How much can be relied on the pixels just outside of the active pixel area? Most algorithms I have currently implemented need 2-3 pixels on the outside to get the pixels at the edge. Therefore I currently copy the 2 rows/cols at the edge to the outside but would like to save the processing time of this step. Or is the usability of this pixels mostly depending on the raw format?
1)Yes, raw_image is raw_width*raw_height 1D array. It is uncropped, full image (including 'masked areas') is read by unpack().
Black level is not subtracted, phase one postprocessing is not performed, but linearization curve is applied to raw_image data (see below)
2) Yes, curve is populated on the early stage of open_file() with curve[i] = i; (for full range loop, from 0 to 65535)
After open_file(), the curve[] will contain linearization curve read from file metadata.
Unfortunately, some formats (e.g. Nikon NEF) store curve not in metadata, but in raw image data itself. For these formats curve is read on unpack() stage.
curve[] size is not set anywhere: curve usage is specific for specific data format/unpacker code, curve is applied at unpack() stage.
Note: same curve[] array is used for gamma correction of output.
3) Use LibRaw::COLOR(row,col) call to get color at row,col.
Please note, that row,col are 'visible area' (cropped) coordinates (i.e. uncropped at top_margin/left_margin is COLOR(0,0))
Is the camera color matrix you're talking about rgb_cam?
Since it gets only used when use_camera_matrix=1, I guess that this matrix is a "camera as shot" to rgb6500K... Is that Right?
In the case of my image, there is quite a big difference between use_camera_matrix=1 and LibRaw built in... LibRaw built in produces a much warmer image -I like it better on that specific picture-...
Any idea about the reason behind that? Are Sony raw files known to have differences between the camera_matrix and the cam_mul they include? Or is cam_mul not in the raw file but calculated from camera_matrix for Sony raws?
Still, it worries me that use_camera_wb=1 and user_mul=copyof(cam_mul) -not touching anything else- create 2 different pictures.
I had the idea to put use_camera_wb=1 AFTER open() instead of before. If I use it that way, then I get the same picture as with user_mul=copyof(cam_mul).
Do you confirm that this picture I get using use_camera_wb=1 AFTER open() or user_mul=copyof(cam_mul) is the correct "as shot" one, and that use_camera_wb=1 should be used after open() and not before?
I was referring to that page telling that use_camera_wb could affect open(), and therefore was affecting it before open(), but maybe it's wrong...
Things are complicated because unpack() saves all color data into rawdata.color (and raw2image restores it). This is made to restore postprocessing initial state to run dcraw_process() multiple times with single unpack().
So, just use recommended way:
- default settings (nothing touched in params) to get daylight WB
- use_camera_wb=1 to get As shot
- use_auto_wb - to get automatic WB
- user_mul[] to get custom WB
If you mix these 3 customs settings, result is undefined (precedence is not specified, take look into source if you interested)
If I copy cam_mul to pre_mul BEFORE unpack(), I get the same picture (picture1) as if I copy cam_mul to user_mul.
If I copy cam_mul to pre_mul AFTER unpack(), I get picture2, different from the first one. However, copying cam_mul to user_mul after unpack() still produces picture1.
That may be simply because the right way to do is to set user_mul, not pre_mul... ;)
What worries me is that if I use_camera_wb=1, and do not touch user_mul nor pre_mul, I get picture3 (different from picture1). I was expecting to get picture1...
As written on my pictures, I put either:
a copy of all 4 cam_mul values in user_mul
a copy of all 4 cam_mul values in pre_mul
I found some LibRaw code (scale colors) where either user_mul or cam_mul are being copied to pre_mul, which seem to confirm what I thought...
I just cannot understand why my pictures are different... I'll have to re-check...
Bayer images contains only one color channel information per pixel (each pixel is red or green or blue).
To get full-colored image from raw bayer data one need to
1) decode bayer (one component per pixe) data
2) do demosaic (de-bayer) so:
- apply white balance
- interpolate color data for missing color values
- convert to output color space
- do gamma correction.
In LibRaw this is made by this call sequence:
open_file() ; // read image metadata
unpack(); // decode bayer data
dcraw_process(); // white balance, color interpolation, color space conversion
dcraw_make_mem_image(); // gamma correction, image rotation, 3-component RGB bitmap creation
I had finally some rawdatas but, it wasn't what i expected. It seems that i have a monochromous picture only raw_image is filled how can i acces the raw data without processes ?
Because i've always worked with ppm and pgm pictures, for that projecti needd to use my .NEF in order to make some deep image processing on it with OpenCV. I'd like to get frow libraw a Matrix (Height x Width x Channels (here 3)) to put it in OpenCV and start to process the images.
if (O.ca_correc >0 ) {cablue=O.cablue; cared=O.cared; CA_correct_RT(cablue, cared);}
if (O.cfaline >0 ) {linenoise=O.linenoise; cfa_linedn(linenoise);}
if (O.cfa_clean >0 ) {lclean=O.lclean; cclean=O.cclean; cfa_impulse_gauss(lclean,cclean);}
CA_correct_RT() - is for demosaic pack GPL3, backported code from RawTherapee, chromatic abberration corrector.
cfs_linedn() - some kind of de-banding by high frequency filtering, again from Emil Martinec/RawTherapee/GPL3
cfa_impulse_gauss() - out of range pixels cleaning, same source/copyright
All three was contributed by RawTherapee in 2011.
LibRaw contribution policy is very simple
1) we accept *all* contributed code
2) the default settings are 'not used'
3) no extensive testing, just test that output image is not completely damaged
The same true for dcraw_process() itself.
Our "mission" is to decode RAW data and metadata. We're happy if user (developer) interaction with LibRaw ends just after unpack()/unpack_thumb() calls and all postprocessing is done by calling application. Standard postprocessing is very similar to dcraw (as dcraw_process() implies), it is not fast and not high quality.
What about the cfaline / linenoise parameters, 1st block, with:
int cfaline; float linenoise;
Line noise (banding) reduction.
positive value turns this feature on (default: off).
linenoise - amount of reduction. Useful range is 0.001 to 0.02. Default value is 0.0
It's used for the same purpose apparently. Is that directly coming from dcraw? You didn't play with it either? Any idea if that's meant to affect things for unpack() or for raw2image()/dcraw_process()/dcraw_make_mem_image()?
I'll try to reverse-engineer this a bit but would be great to have any additional information on what your source code does with this if you have it hanging around. The code is quite... dense on that level!
wf_debanding() is contributed to LibRaw by one of our users.
I've never used it in real processing, just several experiments several years ago. So, try to play with parameters yourself
Made some progress thanks to your explanations. I can play with the color channels and display the results of some personal post-processing. Very nice.
I wanted to ask you some more details on what "banding / debanding" does? In your documentation, I read this for Structure libraw_rawdata_t: holds unpacked RAW data:
int cfaline; float linenoise;
Line noise (banding) reduction.
positive value turns this feature on (default: off).
linenoise - amount of reduction. Useful range is 0.001 to 0.02. Default value is 0.0 i.e. not clean anything.
(...)
int wf_debanding; float wf_deband_treshold[4];
wf_debanding: 1 turns on banding suppression (slow!), 0 turns it off.
wf_deband_treshold[] - per channel debanding thresholds.
I'm reading some general stuff about banding in general, I understand the noise pattern that is targeted. Could you explain in which respect the first parameter (1st block) and the 2nd ones (2nd block) affect the image? They both deal with "banding", so it is unclear what each does.
In addition, do they affect the raw image right after unpack(), or does one, or both, affect only the post-processed one in imgdata.image? (after either raw2image() or dcraw_process())
Will start implementing Libraw functions in my project (still at a very early, poorly documented and modest stage).
You can currently see it as "QtFits" in github: https://github.com/raphaelattie/QtFits.git
Dealing so far with FITS files, the name of the future app will of course change after implementing Libraw-dependent classes, thanks to which I will not just handle FITS files anymore.
dcraw_make_mem_image() just copies values from image[] to separate memory array with
- gamma curve
- 16 to 8 bit correction (if requested; this is default)
- rotation.
Hey,
thank you for your reply Alex! Cleared up some stuff and I'm somehow happy that unpack already applies the curve.
Regarding 1): How much can be relied on the pixels just outside of the active pixel area? Most algorithms I have currently implemented need 2-3 pixels on the outside to get the pixels at the edge. Therefore I currently copy the 2 rows/cols at the edge to the outside but would like to save the processing time of this step. Or is the usability of this pixels mostly depending on the raw format?
1)Yes, raw_image is raw_width*raw_height 1D array. It is uncropped, full image (including 'masked areas') is read by unpack().
Black level is not subtracted, phase one postprocessing is not performed, but linearization curve is applied to raw_image data (see below)
2) Yes, curve is populated on the early stage of open_file() with curve[i] = i; (for full range loop, from 0 to 65535)
After open_file(), the curve[] will contain linearization curve read from file metadata.
Unfortunately, some formats (e.g. Nikon NEF) store curve not in metadata, but in raw image data itself. For these formats curve is read on unpack() stage.
curve[] size is not set anywhere: curve usage is specific for specific data format/unpacker code, curve is applied at unpack() stage.
Note: same curve[] array is used for gamma correction of output.
3) Use LibRaw::COLOR(row,col) call to get color at row,col.
Please note, that row,col are 'visible area' (cropped) coordinates (i.e. uncropped at top_margin/left_margin is COLOR(0,0))
Being very similar to Adobe is surely not bad at all! ;)
LibRaw's embedded color profile (usually very similar to Adobe's) may differ from camera provided color data, so result difference is expected.
Is the camera color matrix you're talking about rgb_cam?
Since it gets only used when use_camera_matrix=1, I guess that this matrix is a "camera as shot" to rgb6500K... Is that Right?
In the case of my image, there is quite a big difference between use_camera_matrix=1 and LibRaw built in... LibRaw built in produces a much warmer image -I like it better on that specific picture-...
Any idea about the reason behind that? Are Sony raw files known to have differences between the camera_matrix and the cam_mul they include? Or is cam_mul not in the raw file but calculated from camera_matrix for Sony raws?
Thanks,
Sylvain.
Looks like Sony file (ARW extension).
For Sony files (with color profile data embedded in file), if use_camera_wb is on, then camera color matrix is used instead of LibRaw built in.
To get same results for use_camera_wb and user_mul set to camera WB values, set use_camera_matrix to 0
You can download my file here
Sylvain.
File from what camera you use for testing?
Understood...
Still, it worries me that use_camera_wb=1 and user_mul=copyof(cam_mul) -not touching anything else- create 2 different pictures.
I had the idea to put use_camera_wb=1 AFTER open() instead of before. If I use it that way, then I get the same picture as with user_mul=copyof(cam_mul).
Do you confirm that this picture I get using use_camera_wb=1 AFTER open() or user_mul=copyof(cam_mul) is the correct "as shot" one, and that use_camera_wb=1 should be used after open() and not before?
I was referring to that page telling that use_camera_wb could affect open(), and therefore was affecting it before open(), but maybe it's wrong...
Things are complicated because unpack() saves all color data into rawdata.color (and raw2image restores it). This is made to restore postprocessing initial state to run dcraw_process() multiple times with single unpack().
So, just use recommended way:
- default settings (nothing touched in params) to get daylight WB
- use_camera_wb=1 to get As shot
- use_auto_wb - to get automatic WB
- user_mul[] to get custom WB
If you mix these 3 customs settings, result is undefined (precedence is not specified, take look into source if you interested)
So, after re-checking:
If I copy cam_mul to pre_mul BEFORE unpack(), I get the same picture (picture1) as if I copy cam_mul to user_mul.
If I copy cam_mul to pre_mul AFTER unpack(), I get picture2, different from the first one. However, copying cam_mul to user_mul after unpack() still produces picture1.
That may be simply because the right way to do is to set user_mul, not pre_mul... ;)
What worries me is that if I use_camera_wb=1, and do not touch user_mul nor pre_mul, I get picture3 (different from picture1). I was expecting to get picture1...
As written on my pictures, I put either:
a copy of all 4 cam_mul values in user_mul
a copy of all 4 cam_mul values in pre_mul
I found some LibRaw code (scale colors) where either user_mul or cam_mul are being copied to pre_mul, which seem to confirm what I thought...
I just cannot understand why my pictures are different... I'll have to re-check...
What values you use in user_mul ?
rgb_cam is [3][4] matrix, while pre_mul are [4] WB multipliers.
Am I right to think that rgb_cam is filled with the values of pre_mul?
Thanks,
Sylvain.
Bayer images contains only one color channel information per pixel (each pixel is red or green or blue).
To get full-colored image from raw bayer data one need to
1) decode bayer (one component per pixe) data
2) do demosaic (de-bayer) so:
- apply white balance
- interpolate color data for missing color values
- convert to output color space
- do gamma correction.
In LibRaw this is made by this call sequence:
open_file() ; // read image metadata
unpack(); // decode bayer data
dcraw_process(); // white balance, color interpolation, color space conversion
dcraw_make_mem_image(); // gamma correction, image rotation, 3-component RGB bitmap creation
Thanks,
I had finally some rawdatas but, it wasn't what i expected. It seems that i have a monochromous picture only raw_image is filled how can i acces the raw data without processes ?
Because i've always worked with ppm and pgm pictures, for that projecti needd to use my .NEF in order to make some deep image processing on it with OpenCV. I'd like to get frow libraw a Matrix (Height x Width x Channels (here 3)) to put it in OpenCV and start to process the images.
Really thanks again !
Bdaniel
Alright Alex, thank you for these precisions, they are very helpful.
quote from libraw_cxx:
if (O.ca_correc >0 ) {cablue=O.cablue; cared=O.cared; CA_correct_RT(cablue, cared);} if (O.cfaline >0 ) {linenoise=O.linenoise; cfa_linedn(linenoise);} if (O.cfa_clean >0 ) {lclean=O.lclean; cclean=O.cclean; cfa_impulse_gauss(lclean,cclean);}CA_correct_RT() - is for demosaic pack GPL3, backported code from RawTherapee, chromatic abberration corrector.
cfs_linedn() - some kind of de-banding by high frequency filtering, again from Emil Martinec/RawTherapee/GPL3
cfa_impulse_gauss() - out of range pixels cleaning, same source/copyright
All three was contributed by RawTherapee in 2011.
LibRaw contribution policy is very simple
1) we accept *all* contributed code
2) the default settings are 'not used'
3) no extensive testing, just test that output image is not completely damaged
The same true for dcraw_process() itself.
Our "mission" is to decode RAW data and metadata. We're happy if user (developer) interaction with LibRaw ends just after unpack()/unpack_thumb() calls and all postprocessing is done by calling application. Standard postprocessing is very similar to dcraw (as dcraw_process() implies), it is not fast and not high quality.
Ok, that addresses wf_debanding(), thanks.
What about the cfaline / linenoise parameters, 1st block, with:
int cfaline; float linenoise;
Line noise (banding) reduction.
positive value turns this feature on (default: off).
linenoise - amount of reduction. Useful range is 0.001 to 0.02. Default value is 0.0
It's used for the same purpose apparently. Is that directly coming from dcraw? You didn't play with it either? Any idea if that's meant to affect things for unpack() or for raw2image()/dcraw_process()/dcraw_make_mem_image()?
I'll try to reverse-engineer this a bit but would be great to have any additional information on what your source code does with this if you have it hanging around. The code is quite... dense on that level!
wf_debanding() is contributed to LibRaw by one of our users.
I've never used it in real processing, just several experiments several years ago. So, try to play with parameters yourself
Hi there,
Made some progress thanks to your explanations. I can play with the color channels and display the results of some personal post-processing. Very nice.
I wanted to ask you some more details on what "banding / debanding" does? In your documentation, I read this for
Structure libraw_rawdata_t: holds unpacked RAW data:int cfaline; float linenoise;Line noise (banding) reduction.
positive value turns this feature on (default: off).
linenoise - amount of reduction. Useful range is 0.001 to 0.02. Default value is 0.0 i.e. not clean anything.
(...)
int wf_debanding; float wf_deband_treshold[4];wf_debanding: 1 turns on banding suppression (slow!), 0 turns it off.
wf_deband_treshold[] - per channel debanding thresholds.
I'm reading some general stuff about banding in general, I understand the noise pattern that is targeted. Could you explain in which respect the first parameter (1st block) and the 2nd ones (2nd block) affect the image? They both deal with "banding", so it is unclear what each does.
In addition, do they affect the raw image right after unpack(), or does one, or both, affect only the post-processed one in imgdata.image? (after either raw2image() or dcraw_process())
Thanks
Do you use bayer-matrix camera to test with?
If not, rawdata.raw_image will be NULL, while rawdata.color3_image or rawdata.color4_image is not
All clear! :-)
Will start implementing Libraw functions in my project (still at a very early, poorly documented and modest stage).
You can currently see it as "QtFits" in github: https://github.com/raphaelattie/QtFits.git
Dealing so far with FITS files, the name of the future app will of course change after implementing Libraw-dependent classes, thanks to which I will not just handle FITS files anymore.
Thanks
dcraw_make_mem_image() just copies values from image[] to separate memory array with
- gamma curve
- 16 to 8 bit correction (if requested; this is default)
- rotation.
It is that simple :)
UPD: so, yes, use it after dcraw_process()
Pages