![]() ![]() Maybe even smaller raw files (because we don't really need 4000 levels per f-stop).The benefits in post-production which follow that.No need for ETTR because we will have the same number of levels for any f-stop.What I am talking about is not to look for a way to HDR but to use the actual DR of the sensor but instead of having it convert the light to linearly encoded data, to have the raw data in a logarithmic way. The two links don't mention anything about logarithmic raw data. I am not sure if we are talking about the same thing. Quote The closest approximation I can come up, besides dual ISO, would be this: For FWC and read noise, I have a feeling finding them from the SNR curve may be an ill-conditioned problem. Rather, I prefer to read it from the SNR curve - detailed answer: Īlso, how are you computing the noise stdev? There are many choices: from OB areas (not reliable, just an extremely rough approximation), from one dark frame (includes both fixed and random components), from the difference of two dark frames (you'll get the random noise component * sqrt(2), assuming it's Gaussian), or from the difference of two regular images (so you can estimate the noise at various signal levels - enough information for plotting the SNR curve).įor DR measurements, I have some confidence in raw_diag's 2-frame SNR analysis (a method inspired from Roger Clark's method) however, white level is still detected using heuristics (that may fail if the clipping is not harsh). It is my understanding that log2(max/stdev) is only a rough approximation, especially at high ISOs. So, feel free to grab adtg_gui and understand/document what some of these registers do. There are some CMOS registers that appear to adjust the black sun protection, but didn't look much into them. I'm not saying there isn't - I'm just saying I'm not familiar with sensor electronics, so maybe I don't know where to look. However, besides tweaking some gains at various amplifier stages, and overriding LiveView resolution to get 3K/4K/fullres LV, I wasn't able to find anything useful for controlling the clipping point beyond what's already documented in the ISO research thread. If you can understand the sensor internals, you can probably change all its registers from adtg_gui. There are routines for doing arithmetic on raw buffers on Canon's image processor - documented here: The closest approximation I can come up, besides dual ISO, would be this:Īlternating short/long exposures is doable, but not trivial. For aperture, I know how to find the digital gain and do the math, and I also know how to override it (see iso-regs.mo from the ISO research thread), but it's not implemented in the mainline. That didn't happen, so I may need to re-think the white level heuristic.Ĭurrently I don't know why the clipping point decreases at longer exposures (back then, when the white level was hardcoded, there was a bug about zebras no longer showing overexposure on long exposures - IIRC on 5D3). In tricky cases like this, I would have expected the white level to be assumed close to the brightest pixel, therefore the overlays showing very little overexposure (if any). In theory, the autodetected white level should be exact iff there are overexposed pixels in the image, or underestimated by about 0.3 stops in the worst case, if there is no overexposure. The code is generic I was hoping to cover all ~15 (soon ~20) camera models with the autodetection. The findings from the ISO research thread are not yet included in ML, sorry about that.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |