Messages

You might want to check out photo acute:
http://www.photoacute.com

It relies upon involuntary camera movement (shake between snaps) and may therefore need more images than a structured approach, but they seem to get some good results.

In private correspondence, they confirmed that an AA-less camera would perform better with their approach.

-h

I just installed ML nightly build (march 26) for my 7D. Overall, it seems like a great improvement over the alpha that I tried a long time ago.

I did experience what seemed like occasional gui glitches (everything but the selected text item disappeared, pressing "Q" brought me back.) Is this a known issue, or would you like a reproducable case/screenshot?

-h

hjulenissen: you seem to know your stuff, but from your question, I bet you did not read my paper and you did not download any DNG samples.

Correct. I have now read your paper and see that you answer my question (and then some). Excellent work!

Would have been cool if some Canon models applied ISO gain per color channel, but I guess that is inefficient from a low-level hw perspective. "white-balancing ISO" where weak color channels gets the benefit of higher ISO than hotter color channels.

It seems from your figures that you use MATLAB to some degree. Is this your personal stuff, or does the ML repository contain MATLAB models?

-h

Canon DSLRs are getting a beating because the DR as a function of ISO measured at DxOMark starts to flatten asymptotically towards 11-12Ev at ISO1600 and below, while recent Nikon DSLRs (and everything based on Sony sensors) appears to improve their DR all the way to ISO 100 (14+ Ev):
http://www.dxomark.com/index.php/Cameras/Compare-Camera-Sensors/Compare-cameras-side-by-side/(appareil1)/795|0/(brand)/Canon/(appareil2)/792|0/(brand2)/Nikon

The difference appears to be Canon using off-sensor ADC (but perhaps on-sensor analog gain). Therefore, a significant amount of noise is added to the signal subsequent to analog amplification and prior to ADC. By raising the amplifier gain "just enough", the signal will be hot enough to travel this path without being affected that much by noise. DSLRs based on Sonys on-sensor ADC are not affected in the same way, and many are described as "ISO-less", i.e. raw shooters might just as well shoot in ISO 100 all the time, under-exposing when necessary and raising the brightness in their raw developer instead of worrying about ISO in camera.

The potential of using "dual ISO" ought to be to have the highlight capability of ISO100, but improving the shadow noise by increasing the gain.

The downside is that ISO cannot be applied as a function of regional signal level: having alternate line(pairs) having different ISO is a kind of "interlacing" that will amplify some sensels that should have been amplified, and not amplify some sensels that should have been.

I think that the image examples shown in this thread have been somewhat misleading in that they appear to compare a regular "flat" image with a tone-mapped dual ISO image. Just like when comparing HDR photography to LDR photography, I think that that is only 50% of the story. In order to really visualize the differences, we might want 4 images:
1. Regular captured, Regular processed image
2. Regular captured, Tonemapped image
3. DualISO captured, Regular processed image
4. DualISO captured, Tonemapped image

For most, the difference between image 2 and image 4 might be most telling, as the tonal range should be similar, but DualISO ought to have less visible shadow noise and some artifacting/loss of resolution.

Is it possible/feasible to pre-process dualISO images into something that appears like regular 7D images (only with less shadow noise) suitable for any raw converter?

-h

What is YUV 4:2:2 uncompressed.

YUV defines the color space. While the camera Sensor gives out RGB Signal, it is being converted to YUV.

Y = luminance which we get by adding 0,299R + 0,587G + 0,114B
U = Cr which contains R-Y
V = Cb which contains B-Y

Cr & Cb are the digital Forms of U & V and later only called Cr & Cb

"YUV" is actually an error. There was an analog format back in the days called YUV, but YCbCr is not based on it. Possibly engineers and software developers thought that YUV was simpler to type than YCbCr. This is described in "Digital video for HDTV..." By C. Poynton

So you can see that our RGB Signal is splitted up and G (Green) is completely left out, but because Y Contains part of the green signal we are able to convert YCrCb back to our RGB Signal (this happens in your TV, monitor or any other playout device).

We can get back to rgb using the inverse mixing matrix, but if YCbCr and RGB are both limited to 8 bits, the conversion will be lossy (you need 9-10 bits for the YCbCr representation).

However, what is 4:2:2?
4:2:2 defines the Chroma subsampling and is defined the following

4 stands for full resolution while 2 stands for half resolution, but what does that mean for us?

There are (at least)
4:4:4
4:2:2
4:2:0
4:1:1
4:0:0

I don't know anyone that can explain the system to those number.

Y         :    4     =   1920x1080 pixels
Cr(U)  :    2     =    960x540 pixels
Cb(V)  :    2     =    960x540 pixels

This is wrong, you are describing 4:2:0. 4:2:2 has half the horizontal resolution, but full vertical resolution:
Y         :         =   1920x1080 pixels
Cr(U)  :         =    960x1080 pixels
Cb(V)  :         =    960x1080 pixels

We are currently shooting with our 7Ds at 4:2:0 which states that our movie clips look like this

Y = 1920x1080 pixels
Cr(U) = 480x270 pixels
Cb(V) = 480x270 pixels

No, 4:2:0 is:
Y         :         =   1920x1080 pixels
Cr(U)  :         =    960x540 pixels
Cb(V)  :         =    960x540 pixels

Now to RAW
RAW is simple, it is just data from the sensor completely untouched (in theory) in real life you will have some sort of compression in it.

My Canon 7D produce uncompressed raw data in real-life. There likely is some processing (correction of bad/hot pixels) going on behind the scenes, though.

-h

So.... Can someone please give me more info on YUV422  and RAW?  Is YUV422 the colour spacing, and RAW the record format.? Could you have something that is YUV422 recording as a non RAW video file?

Not knowing what the ML team thinks of, I will describe general understanding of the terms:
-Raw is something close to the image sensor raw data. Undeveloped, not applied demosaic, whitebalance, gamma, sharpening etc.
-YUV422 is a developed format, something resembling JPEG/h264, except that there is no lossy compression artifacts.

If compression artifacts is a problem to your application, then YUV422 may be the solution. If better highlight recovery, more accurate color correction, etc is what you need, then raw may be the solution.

-h

1080i @ 60 fps == 1080p @ 30 fps, fyi. Interlaced means that there are half as many rows.

In terms of raw bandwidth, yes. In terms of content and interpretation of the data, no.

-h

Any hope for changing the h.264 encoding profile on 7D? http://william-patin.de/blog/canon-and-the-h-264-profile/

There is more to video codec quality than the h.264 profile. Just ask the x264-people.

-h

...when I shoot HDR I tend to shoot in a 3rd of a stop increments as this tends to give less noise

If the DR of the sensor is 10-11 stops (at optimal ISO etc), then shifting exposure by 1/3 stop should give minimal improvements. If you see significant IQ improvements, I would guess that you are:
1. Running the camera at very high ISO
2. Use some strange, quirky HDR developer
3. Apply very nonlinear curves/tonemapping operators.

-h

It would be great if ML could use the dead pixel information and write the RAW file with the dead pixels corrected, interpolated from their neighbour pixels.

Seems to make more sense that Adobe enables the meta-data interpretation in ACR?

-h

I appreciate your work.

I cant wait to try this out in my 7D when alpha 3 arrives.

Are you guys aware of this application:
http://www.reikan.co.uk/focalweb/

They now can do calibration without flicking the mirror per shot.

They also publish statistics (based on automated user reports) on different lens/house combinations:
http://www.reikan.co.uk/focalweb/index.php/online-tools/lenscamera-information/

I have used it a lot, and I have come to the conclusion that AFMA is difficult. My 70-200 needs one AFMA setting at 120mm or so, another setting at the ends (meaning that even a 5Dmk3 would have to few parameters). The choice of defocusing method ("near" or "far") seems to have some significance sometimes, with some lenses. I have done extensive testing, saying to my self "now everything is as good as it can be", only to repeat under slightly different conditions and getting equally conclusive measurements pointing in another direction...

-h

Is it possible to have access to the PDAF sensor "raw" data? I imagine that this could give us some crude depth-map. Might also be pedagogic to see for yourself what the tracking focus engine has to work with (and why it fails in a certain situation).

-h

Hi all

Thanks to the devs for extending the possibilities of my 7D.

I have experienced one bug. When engaging the focus peaking feature in live view, the camera seems to reboot after one minute or so. Happened twice. Is this a known issue?

The focus peaking overlay also seems "noisy". Would it be an idea to apply median filtering or some other "clustering" of sharp pixels?

best regards
.h