All cameras, we're talking about all cameras, well at least the modern ones, or at the very least the ones that are supposed to have a known offset, like Canon and 2048. There must be a good reason why you chose one method over the other, right? On the 0.17 release notes you wrote "LibRaw do not rely on hardcoded black levels", well, why not? Is it because hardcoded black levels are unreliable or is it because they can't be found for all camera models? That's what I'm asking, why did you choose to do it this way and not the "it's close to 512 or 2048 so let's set it to 512 or 2048" way? I think that's a pretty fundamental question.
Right, but the question remains, which is closer to ideal, the fixed 2048 offset or the measured black levels? Seems to me like using the masked pixels makes it quite prone to noise mostly at high ISOs, and that they deviate from the fixed offset in statistically insignificant ways (while the ideal offset might well remain the same), which is why I'm thinking the measured black levels should probably be disregarded entirely, except maybe as a hint of what the true fixed offset should be.
But since you're using the measured black levels instead then you must think that logic is wrong, this is what I'm asking about.
LibRaw tries to extract as much as possible from RAW.
Other software (e.g. in-camera JPEG processor) may crop more or less (it also may depend on camera/raw processor settings, for example barrel distortion correction on/off).
So, pixel level RAW/JPEG match looks not possible in general case
LibRaw is internally 16-bit unsigned int, so float conversion looks useless.
For 16-bit output just use explicit type conversion to (ushort*) for libraw_processed_image_t->data.
From what you said, it seems like the "white balance" is necessary before normal demosaic. If a user want to supply her/his own white balance factors, it can still be done through "user_mul[i]", correct?
Also, when I use "output_color = 0" and "half_size = 1" together (regardless other parameter), the image seems to look strange. Can you take a look at it?
I would like to use the RAW data without calling "dcraw_mem_image()"; however, there is still a need for demosaic. Currently, I have to use "dcraw_mem_image()" with the parameters listed before to get it as close as possible.
If there is a function that I can call to get the image data that only goes through demosaic step (with no other adjustment), that would be great!
"Unaltered image" is something close to what I am interested. Given the parameters that I enlisted, do they look reasonable to get the "Unaltered image"?
Also, only if you have time, would you mind replicating my test by adding "half_size = 1" (see below) and see if the converted image looks correct?
I understand there are several steps if dcraw_process () is called. Since I am interested in getting the image data that is very close to the "demosaic RAW", I manually set some parameter to "avoid" unnecessary processing on the RGB code values. For example, I did the following:
I did not understand exactly what you want
Standard raw processing sequence is (for decoded/linearized data) in dcraw_process is
- black subtraction
- white balance
- demosaic
- data scaling to use full range
- conversion to output color space
Than, on output
- brightness correction
- gamma curve
What stages do you need and what is not?
BTW, besides demosaic, all other steps are trivial and very easy to implement.
I meant the "raw image data" that only has demosaic process. In this case, I may still need "dcraw_process", right? if it is, then when I use "output_color = 0" and "half_size = 1", the output seems like missing a channel.
To get fully unprocessed raw data you may
1) Access imgdata.rawimage.raw_data array which stores raw values read from sensor as is
2) set params.half_size=1 and call raw2image() after unpack (instead of dcraw_process).
raw2image will arrange raw_data to imgdata.image[][4] array
All cameras, we're talking about all cameras, well at least the modern ones, or at the very least the ones that are supposed to have a known offset, like Canon and 2048. There must be a good reason why you chose one method over the other, right? On the 0.17 release notes you wrote "LibRaw do not rely on hardcoded black levels", well, why not? Is it because hardcoded black levels are unreliable or is it because they can't be found for all camera models? That's what I'm asking, why did you choose to do it this way and not the "it's close to 512 or 2048 so let's set it to 512 or 2048" way? I think that's a pretty fundamental question.
Very hard to tell 'which is closed to ideal' while discussing abstract matters.
What camera we're talking about? Could you please provide dark frames shot at same shutter speed/temperature/camera settings?
Right, but the question remains, which is closer to ideal, the fixed 2048 offset or the measured black levels? Seems to me like using the masked pixels makes it quite prone to noise mostly at high ISOs, and that they deviate from the fixed offset in statistically insignificant ways (while the ideal offset might well remain the same), which is why I'm thinking the measured black levels should probably be disregarded entirely, except maybe as a hint of what the true fixed offset should be.
But since you're using the measured black levels instead then you must think that logic is wrong, this is what I'm asking about.
Please note, that imgdata.color.black is only 'base' value with offsets stored in imgdata.cblack[], so final black level may be different.
For Canon cameras, LibRaw calculates black levels based on masked pixels.
LibRaw tries to extract as much as possible from RAW.
Other software (e.g. in-camera JPEG processor) may crop more or less (it also may depend on camera/raw processor settings, for example barrel distortion correction on/off).
So, pixel level RAW/JPEG match looks not possible in general case
Hi Alex,
Thanks for replying!
I actually used the conversion to "ushort *" right after posting the question. It seemed to work fine.
Have a nice day!
Mio
LibRaw is internally 16-bit unsigned int, so float conversion looks useless.
For 16-bit output just use explicit type conversion to (ushort*) for libraw_processed_image_t->data.
Thanks for quick response, I will try that.
In last master snapshot (https://github.com/LibRaw/LibRaw) we've added open_bayer() call
Look into: https://github.com/LibRaw/LibRaw/blob/master/Changelog.txt for docs
and into https://github.com/LibRaw/LibRaw/blob/master/samples/openbayer_sample.cpp for usage sample
There are as-shot WB coefficients (so diagonal adaptation matrix)
Awesome, thank you very much!
Jan
From dcraw_emu, usage() call:
"-w Use camera white balance, if possible\n"
And, sure, it works.
There is no -d/-D keys in dcraw_emu
Use unprocessed_raw sample instead.
Yes, you can set custom WB via user_mul. But for wrong WB demosaic results may be not good as expected.
dcraw_emu -o 0 -h works for me
(-o 0 translates to output_color=0, -h translates to half_size-1)
Hi Alex,
From what you said, it seems like the "white balance" is necessary before normal demosaic. If a user want to supply her/his own white balance factors, it can still be done through "user_mul[i]", correct?
Also, when I use "output_color = 0" and "half_size = 1" together (regardless other parameter), the image seems to look strange. Can you take a look at it?
Thanks so much and have a nice day!
Normal demosaic (not 'half' or 'linear interpolation') is useless without white balance first.
Hi Alex,
I would like to use the RAW data without calling "dcraw_mem_image()"; however, there is still a need for demosaic. Currently, I have to use "dcraw_mem_image()" with the parameters listed before to get it as close as possible.
If there is a function that I can call to get the image data that only goes through demosaic step (with no other adjustment), that would be great!
Thanks,
I'm still cannot understand what kind of data you need. You wrote 'close to', but could you please describe what you really need?
What is 'converted image'? imgdata.image array, or result of dcraw_mem_image() call?
Hi Alex,
"Unaltered image" is something close to what I am interested. Given the parameters that I enlisted, do they look reasonable to get the "Unaltered image"?
Also, only if you have time, would you mind replicating my test by adding "half_size = 1" (see below) and see if the converted image looks correct?
-----------------------------------------
use_camera_matrix = 0;
highlight = 0;
use_camera_wb = 0;
output_color = 0;
gamm[0] = 1.0; gamm[1] = 1.0;
no_auto_bright = 1;
user_mul[0] = 1.0; user_mul[1] = 1.0; user_mul[2] = 1.0;
half_size = 1;
-----------------------------------------
Thanks a lot!
I can not understand what 'demosaic RAW' is.
If you just need 'source' (unaltered) values from sensor/raw file, it is much better to access imgdata.rawdata.raw_image directly.
dcraw_process() means multiple processing stages. Your parameters looks like you need unaltered image.
Hi Alex,
Thank you for the quick reply! Appreciate it!
I understand there are several steps if dcraw_process () is called. Since I am interested in getting the image data that is very close to the "demosaic RAW", I manually set some parameter to "avoid" unnecessary processing on the RGB code values. For example, I did the following:
-----------------------------------------
use_camera_matrix = 0;
highlight = 0;
use_camera_wb = 0;
output_color = 0;
gamm[0] = 1.0; gamm[1] = 1.0;
no_auto_bright = 1;
user_mul[0] = 1.0; user_mul[1] = 1.0; user_mul[2] = 1.0;
-----------------------------------------
If the setting sounds reasonable, when I add "half_size=1", the converted image looks like a channel is missing.
Thanks a lot!
I did not understand exactly what you want
Standard raw processing sequence is (for decoded/linearized data) in dcraw_process is
- black subtraction
- white balance
- demosaic
- data scaling to use full range
- conversion to output color space
Than, on output
- brightness correction
- gamma curve
What stages do you need and what is not?
BTW, besides demosaic, all other steps are trivial and very easy to implement.
Thanks a lot for the quick reply!
I meant the "raw image data" that only has demosaic process. In this case, I may still need "dcraw_process", right? if it is, then when I use "output_color = 0" and "half_size = 1", the output seems like missing a channel.
Have a great day!
To get fully unprocessed raw data you may
1) Access imgdata.rawimage.raw_data array which stores raw values read from sensor as is
2) set params.half_size=1 and call raw2image() after unpack (instead of dcraw_process).
raw2image will arrange raw_data to imgdata.image[][4] array
Pages