Also, if I use "user-black = 0", will there be no "black subtraction" before demosaic?
I printed out the "data_maximum" value from a RAW, why the "data_maximum" is 0 before processing and 4095 after processing. Should it be same before and after?
I take the opportunity of this comment to know what are the options to be used in command line (e.g. through dcraw_emu) to avoid any clipping. It seems that a clipping is done systematically whatever the different options...
By the way, I did not find an explanation of the 'gamma_curve' function which does different things depending on the 'mode' input...
The file appears to be clipped in the camera in the white patch on the bottom-left; however, the patch directly to the right of it isn’t. The conversion seems to clip both patches to the same or similar value. Can you look into this again?
Speaking of photographyblog samples and crazy histograms, I've tested my libraw code on samples from other cameras and I haven't seen anything crazier than a Sony RX100 V's histogram. It's coded on 14-bits (actually perhaps more since it says the maximum is 17220), but at the lower end it only needs 12-bits, and it goes down in steps as you go up in values! So there's a 11-bit section, then 10-bit, then 9-bit in the highlights! It probably helps with the compression? Anyway I thought you'd be interested to know about this in case you didn't already.
Auto-bright is performed on dcraw_make_mem_image() stage and changes the range of input data that mapped into output (gamma-corrected) image, based on image histogram (in linear space).
So, yes, it is done in linear space, but on output.
So for every 4 values in the histogram you have one with green (not sure which but it's one of the two), the next one has both blue and the other green, the next one has red only, and finally there's one with no values at all. This would make sense if they were all gathered in the same bins but instead they're spread differently, like they're being digitised differently maybe?
It might be worth noting that the G7 X Mark I (which preceded the related G9 X) only had 12-bit values, so maybe the bump to 14-bit was done with cutting a corner somewhere.
I'm planning to use Libraw in Photo Mate R3 (Android editing software), and switchting from dcraw for better mainability and better camera support.
Okay,
I will try, thank you for your reply!
Sorry, no such ability in dcraw_emu sample, output files names are always derived from source file.
BTW, full source code provided with LibRaw, so you may modify samples as you wish.
Yes, -U switch sets auto_bright_thr.
Most likely you do not want to turn off black subtraction.
data_maximum is calculated during processing.
Hi Alex,
Thanks for more information!
Is "-U 0.0" same as "auto_bright_thr = 0.0"?
Also, if I use "user-black = 0", will there be no "black subtraction" before demosaic?
I printed out the "data_maximum" value from a RAW, why the "data_maximum" is 0 before processing and 4095 after processing. Should it be same before and after?
Thanks,
Mio
-U float-number changes auto-brightness threshold (default value is 0.01 so 1% of pixels brightened to clipping), so -U 0.0 may be useful
-W option turns auto-brightness completely off
Hi all,
I take the opportunity of this comment to know what are the options to be used in command line (e.g. through dcraw_emu) to avoid any clipping. It seems that a clipping is done systematically whatever the different options...
By the way, I did not find an explanation of the 'gamma_curve' function which does different things depending on the 'mode' input...
Thanks for the help
Greg
2nd white patch is clipped in G channel too (after WB applied, all channels to be clipped to make color white).
RawDigger overexposed area display (red overlay): https://www.dropbox.com/s/975db7gahr7ba7c/Screenshot%202017-04-06%2007.1...
RAW histogram of area on 2nd patch: https://www.dropbox.com/s/2a52m2057c50fbo/Screenshot%202017-04-06%2007.1...
Hi, thanks for the quick reply!
The file appears to be clipped in the camera in the white patch on the bottom-left; however, the patch directly to the right of it isn’t. The conversion seems to clip both patches to the same or similar value. Can you look into this again?
Thanks so much!
This file is already clipped in RAW.
See histogram peaks in G and B channels: https://www.dropbox.com/s/9ny0sk5easwbo6s/Screenshot%202017-04-05%2021.3...
The last one (the bottom-left patch). Now the bottom-left patch has the similar code values as the ones of the patch next to it on the right.
Thanks a lot!
Is all three files are clipped or only latest one?
Yea - "Data range is 0 to 65535 for 16-bit output, the max is 65535". The RAW file for testing is 4 stops above. I can upload it tomorrow. Thanks!
Actually you can download the RAW from this link:
https://www.dropbox.com/sh/04lf95ywdbihec7/AAB4KAiDLdvhFIONl8yKOt5Za?dl=0
Thanks a lot!
Hi,
I print out the code values after "libraw" processing. They are all within the range of "0 - 65535".
The settings that I use before "dcraw_make_mem_image (...)" are:
"
output_color = 5;
output_bps = 16;
highlight = 0;
use_camera_matrix = 0;
gamm[0] = 1.0;
gamm[1] = 1.0;
auto_bright_thr = 0;
no_auto_bright = 1;
"
I tried to upload the RAW file, but the file size is big and the format cannot be recognized.
Thanks a lot!
Data range is 0...65535 for 16-bit output, what is '1.0' mean?
Also, could you please upload some clipped file to test with?
Hi,
I actually set "no_auto_bright" to 1, it actually clipped the white to 1.0.
Thanks a lot!
Try auto_bright_thr set to 0, or no_auto_bright set to 1
Yes, Sony ARW 2.3 uses 11-bit data (lossy compressed and highlights compressed): https://www.rawdigger.com/howtouse/sony-craw-arw2-posterization-detection (see 'inside Sony cRAW format' chapter)
Speaking of photographyblog samples and crazy histograms, I've tested my libraw code on samples from other cameras and I haven't seen anything crazier than a Sony RX100 V's histogram. It's coded on 14-bits (actually perhaps more since it says the maximum is 17220), but at the lower end it only needs 12-bits, and it goes down in steps as you go up in values! So there's a 11-bit section, then 10-bit, then 9-bit in the highlights! It probably helps with the compression? Anyway I thought you'd be interested to know about this in case you didn't already.
http://i.imgur.com/4GdKyxk.png
Auto-bright is performed on dcraw_make_mem_image() stage and changes the range of input data that mapped into output (gamma-corrected) image, based on image histogram (in linear space).
So, yes, it is done in linear space, but on output.
Okay I did some tests with a black frame by doing averages on various non-overlapping windows and the biases across channels are consistent.
Here's an histogram of a black frame at ISO 125, 1/2000 sec, it's also pretty weird: http://i.imgur.com/Q7kgaLU.png
line 6479, yep I see it, thanks!
Indeed, and look at what happens when you superimpose all 4: http://i.imgur.com/EovPwIF.png
So for every 4 values in the histogram you have one with green (not sure which but it's one of the two), the next one has both blue and the other green, the next one has red only, and finally there's one with no values at all. This would make sense if they were all gathered in the same bins but instead they're spread differently, like they're being digitised differently maybe?
It might be worth noting that the G7 X Mark I (which preceded the related G9 X) only had 12-bit values, so maybe the bump to 14-bit was done with cutting a corner somewhere.
Pages