Messages

* vertical lines (could be solved with 0xc619 or 0xc61b )

This is black level for each column, but for the banding issue we need EV correction for each column (mod 8 ). Do you know any tag for that?

Try the constant exposure option - it will not extend the shutter speed range, but will adjust ISO to compensate for that.

You focused it better?

I guess Canon squishes it to scan the sensor faster. No idea how to change it, so ML just tells you how to correct it in post.

Actually I find the increase from 1280 to 1920 quite significant, but I have yet to see anyone putting this to good use...

I thought you already knew that ML is just dumping the LiveView buffer on the card...

?! Q works fine here, it goes back by default (unless you override it when creating menu entries).

The problem is that I don't know how to redirect the display buffer (on most cameras, it's just YUV422_LV_BUFFER_DISPLAY_ADDR = new_buffer; you can even move it around and see a memory map with this).

Now that we know how to redirect the edmacs, it may be worth trying to save Canon buffers at YUV422_LV_BUFFER_1 + 720*480*2, YUV422_LV_BUFFER_2 + 720*480*2 and YUV422_LV_BUFFER_3 + 720*480*2. That space should be unused as long as a HDMI is not connected (that's why filters get disabled on HDMI).

After you do that, dst_buffer will be the original address and src_buffer will be just above it.

This is the theory... and you already know that in theory there is no difference between theory and practice

Until Coutts finds the stub, just comment out the playback part.

For grayscale preview, you need display filters. I don't know how to do it for 50D; the 5D2 method is really hacked and took me days of trial and error to figure it out (and it's just halfway working).

Maybe it's worth investigating it again, now that we understand the EDMAC a bit better. It's not easy.

You already asked in another thread, received the same answer, and you are still insisting. This is a warning.

No, and please don't flood the forum with unnecessary posts.

You mean, the one from hudson doesn't work?!

I have a strong green cast though

The black level is too high; it's probably hardcoded at 2048, which is usually right for 5D3, but too big for 5D2. The one from exif should be a good starting point.

Another possible speed boost from 50D: https://bitbucket.org/hudson/magic-lantern/commits/6de809655da4

Too slow... a USB 3 card reader is faster

We don't consider it ready for production, so the debug info will stay there for now.

See raw_to_ev and raw_preview_fast, these will answer your questions.

Good catch, gradient in source image was the problem here.

Got a few solutions that seem a bit better at first sight:

1) raw2dng_noweight.exe - it addresses the gradient issue and uses the old weighting method (constant weights for all pixels that are -9 EV under white level or brighter, the others are discarded). It is able to undo most of the banding from sample 2 (not quite exact, 1.000  1.000  0.999  1.000  0.991  0.992  0.987  0.987). According to your log, they should be 1 1 1 1 0.994 0.992 0.990 0.988.

2) raw2dng_weight.exe This addresses the gradient issue and uses variable weight for pixels brighter than -12 EV under white level; the weight is equal to EV value relative to black level, so a bright pixel can be ~10x more important than a dark one. Undo coefficients: 1.000  1.000  1.000  1.001  0.994  0.994  0.991  0.990.

3) raw2dng_weight_hilight.exe Same as 2, but ignores very bright areas when estimating the coefficients. It only makes a difference when the image contains overexposed areas.

Can you run some tests and see which one seems closest to reality?

Note: these are debug versions, and they will always do some correction, no matter what.

Here you go:

https://bitbucket.org/hudson/magic-lantern/src/tip/modules/raw_rec/speedsim.py

You may need to allocate the buffers with alloc_dma_memory / free_dma_memory, this should fix it. Make them larger too.

I had global draw turned off all the time. Thought that would take a hit on performance.

Just turned it on (Live view) and guess what, recording speed goes up! Getting stable 1592x896 now, recording at 57MB/s. Without GD i get like 52 and drops to 50. great!

Great find!!!

(and it makes sense, since the 50D ML kills all Canon drawing code)

Tip: turn it off and call canon_gui_disable_front_buffer() from somewhere.

FPS override

Can you upload some samples? (the first DNG from the sequence is enough, along with the conversion log).

Modules were designed to be portable, so... better just add it back?

Half-shutter

Look in power saving menu