Messages

In 5x it records at the photo mode resolution of the sensor (1:1 crop). In 1x, the image is downsampled by 3, and the filter is designed for this downsampling factor. In 720p, the image is downsampled by 5 vertically and 3 horizontally, and that's why the filter might be a bit weak here.

I read somewhere on the site in the past few days that VAF filters are designed for the stock h.264 codec and that they are not suited to RAW.

LOL. They are designed for 1080p video sampled from the entire sensor; they may be too weak for 720p and they are way too strong for crop mode video.

It's the value that gives 1/60.000 shutter speed when Canon shutter is set to 1/60 (of course, in a NTSC video mode, e.g. 30p and 24p).

You should include the resolutions at 14-bits, because that google doc is being edited and numbers may change.

Sure. The problem with current metadata is that we can't extend it without breaking current converters, so the first step is to have something where we can add things easily.

I can also get microsecond-level timestamps for each frame, if it helps.

You need to tell it that you are OK with a bit of overexposure (for example, clip the green channel or clip 10% of pixels or whatever).

http://www.magiclantern.fm/forum/index.php?topic=6299

Or just adjust the exposure manually, based on the hint and overexposure warnings.

We can embed the camera model in the header, but it needs updating all the converters. So... at the next major file format upgrade.

I can see why one would want a faster shutter (to avoid motion blur), but in APEX this is measured in seconds (Tv = time value), so this is more of a maximum shutter (or, clearer, maximum exposure time?)

For the limit, I find the soft constraint quite nice (it adjusts some other parameter, then if you really insist, it breaks the limit).

What I'm missing (but I'm not sure how to implement) is to make sure it always follows the same path (for example, if you turn one wheel back and forth the same number of clicks, you should probably end up in the same position). But this again requires inverting the order that you chose from menu...

Maximum ISO is the one from auto ISO in the menu, but it's not really a limit (it only gives priority to the other setting).

Minimum shutter... I can't see why anyone would use that. If you want more motion blur, just dial a slower shutter.

The issue can't be fixed once the aliasing got in the digital domain; you just can't fix it in post. Well, maybe if you are Ken Rockwell so you can break some physics laws...

You can also record slightly out of focus. This will work.

Read some signal processing theory before blaming ML or conversion tools or whatever other software things.

Any idea about how to choose these thresholds? I can't imagine a formula that would cover most situations...

Cool, that's almost 2K.

Can you get a screenshot with the latest changeset? I've modified the speed calculation routine to include only the time used for writing to card (idle time is displayed separately, if any).

There's also a minor speed optimization, but it doesn't seem to make any difference on 5D3.

P.S. What's the point in quoting a huge image 5 times?

The only good fixes for aliasing are crop mode or the Mosaic filter (which afaik doesn't fit on the 50D).

To get rid of damping, you would have to build a histogram of the edge detect image and compute the threshold there (requiring two image passes for one frame). The current method computes the threshold iteratively, with very little CPU time, but it takes a bunch of iterations to converge. The damping is there to make the transition a bit nicer, instead of hunting back and forth.

Set ETTR to 30s and intervalometer to 10s, should do the trick. Didnt't try it though.

I guess pretty much all tools based on dcraw (e.g. ufraw, rawtherapee) recognize this file, right?

For me, running the sensor cleaning did the trick.

These are high priority tasks, because they refresh quickly. The priority was tweaked so they don't affect Canon's H.264 recording, but raw recording needs pretty much all the resources it can get.

On 5D3 I notice a 2-3 MB speed drop with raw zebra and peaking enabled, but the task scheduler on 50D/5D2/500D is quite a bit behind 550D and newer cameras.

The underlying problem is that I don't know any absolute measure for focus (everything I've tried is influenced heavily by light levels, contrast and so on). So my workaround was exactly this adaptive threshold, and the issue you posted is a side effect of it.

Raw histogram is a low-priority task, so it should be OK. Zoom is one of the most CPU-intensive overlays, try to avoid it.

It's not likely to get 1920 x 1080p because the sensor is sampled at a lower resolution (1880). It's also not likely to get any more speed improvements for continuous recording - it already records at pretty much the benchmark speed.

It's also not likely to see 12-bit anytime soon, because the CPU is very slow for any sort of postprocessing.

The table can be edited, but you need a mouse to click on the link.

Right, the threshold is variable, so only X% of the image is highlighted (and the X is the threshold from menu). There is some damping too when updating this threshold.

Just uploaded a new raw2dng.exe. If anybody is still having banding issues with it, please upload the first DNG from the video.

Regarding file format, starting from today, frame size might be a bit higher than w * h * 14/9 (it's rounded to 4096 bytes). If your third party converter uses the same file reading loop as raw2dng, it should be fine. If not... you'll have trouble at certain resolutions.

Most likely CPU or DMA is overloaded with something else; disabling certain stuff (Canon GUI, maybe LiveView display) helps.

On 50D only, to disable Canon GUI, enable Global Draw.

What changeset are you running? There should not be any drops in write speeds, unless you have enabled zebras or focus peaking or who knows what other CPU-intensive stuff.

Just look at CONFIG_KILL_FLICKER ifdefs and you'll see why it's getting enabled.

The question doesn't make sense; if the battery drains, it's because CPU got stuck (and it will no longer react to buttons).

Normal self-discharge should be quite small; if you want to write a battery diagnostic module, feel free to do so.