Screenshot bug. Overlays not captured

[gabriielangel]

Screenshots: these now save in BMP format, not PPM.  This means...  you can view them just by opening the card.

It would be a good idea to eventually allow screenshots to also capture overlays. It would make taking examples in the field a lot easier, as holding a phone to take screenshots under the sun is not always convenient

[names_are_hard]

Not sure what you mean.  Like this?

[gabriielangel]

Yes! But on the EOS M, the screenshot fumction only works to capture the ML Menus. Raw video needs to be turned off, so False colors and other overlays are not recorded.

I tried with both Bilal's (Raw video needs to be turned off manually) and Danne's (Raw video is turned off automatically) variants.

[Walter Schulz]

Well, another feature not working with those builds.
Guess who has to do something about it? ;-)

[names_are_hard]

Yes! But on the EOS M, the screenshot fumction only works to capture the ML Menus. Raw video needs to be turned off, so False colors and other overlays are not recorded.

Are you only checking using screenshots from benchmark?  Have you tried screenshots from Debug menu?

Debug menu does this:

Code Select Expand

take_screenshot(SCREENSHOT_FILENAME_AUTO, SCREENSHOT_BMP | SCREENSHOT_YUV);

Bench module code does this:

Code Select Expand

take_screenshot("bench%d.bmp", SCREENSHOT_BMP);

The screenshot code can capture both.  Benchmark code is asking it to not copy LV data.

[theBilalFakhouri]

Raw video needs to be turned off,

It's a memory problem, RAW video (mlv_lite) allocate all available memory when it's active, iirc this break screenshots, this issue does exist in official builds, see:

BTW: no in-cam screenshots for the last case, as trying to take them in movie mode results in a memory error. Just checked on 700D and it's same.

With mlv_lite's RAW Video enabled, the entire memory is preallocated during stanby. I'm seriously thinking to revert this change, just haven't managed to code anything in this direction. Been focusing on new ports + QEMU lately (as my main camera is defective anyway).

There are many side effects because of mlv_lite and when "the entire memory is preallocated during stanby", broken screenshots is one of them.


Edit:

Raw video needs to be turned off, so False colors and other overlays are not recorded.

I think you are refering to x5 mode, because in x5 mode, ML global draw won't be active only in one case, when  RAW video is turned on (it works like this by ML design). In normal Canon video modes like 1080p and 720p, ML global draw will be active with or without RAW video.

When crop mood is active, all presets will use x5 mode and patch x5 mode to the selected preset.
So the main issue here is memory allocation actually, fixing it will make you take screenshot when RAW video is enabled.

[Danne]

I turn off RAW video momentarily in code and turning it back on just before the screenshot is taken in my builds

[names_are_hard]

Okay, good to learn about another major bug.  Well, you know, "good".

Obviously this is something that should be fixed.  Especially since on modern cams, trying to allocate all the SRM buffers triggers an OS assert and therefore crashes.

Looking here in exmem.c, this looks like a badly designed API by us:

Code Select Expand

283 struct memSuite *_shoot_malloc_suite(size_t size)
284 {
285     //qprintf("_shoot_malloc_suite(%x)\n", size);
286
287     if(size)
288     {
289         /* allocate exact memory size */
290         return shoot_malloc_suite_int(size);
291     }
292     else
293     {
294         /* allocate as much as we can */
295         size_t max_size = shoot_malloc_autodetect();
296         struct memSuite * hSuite = shoot_malloc_suite_int(max_size);
297         shoot_full_suite = hSuite;
298         return hSuite;
299     }
300 }

The max_size guessing code should probably be split out into its own function.  Then if you want to allocate a very large amount, you call that first, and pass the size to shoot_malloc_suite().  But now you can subtract some margin first, and avoid exhausting the pool.  I imagine it won't be that simple, but the current design doesn't even let you try!

This is an interesting topic, but it's also off topic for this thread.  Please create a new one if more discussion is useful.

[Walter Schulz]

I took the liberty to splitt topic. Change topic title as needed.