Quote from: names_are_hard on March 20, 2024, 05:44:54 PMScreenshots: 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 :)
Not sure what you mean. Like this?
(https://i.ibb.co/MRJJC3Z/overlays.png)
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.
Well, another feature not working with those builds.
Guess who has to do something about it? ;-)
QuoteYes! 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:
take_screenshot(SCREENSHOT_FILENAME_AUTO, SCREENSHOT_BMP | SCREENSHOT_YUV);
Bench module code does this:
take_screenshot("bench%d.bmp", SCREENSHOT_BMP);
The screenshot code can capture both. Benchmark code is asking it to not copy LV data.
Quote from: gabriielangel on March 20, 2024, 08:04:37 PMRaw 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:
Quote from: ArcziPL on March 06, 2019, 10:24:51 AMBTW: 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.
(https://i.postimg.cc/RqdRD9Py/70d-mem-err-screenshot-video-mode.png) (https://postimg.cc/RqdRD9Py)
Quote from: a1ex on March 06, 2019, 10:48:59 AMWith 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:
Quote from: gabriielangel on March 20, 2024, 08:04:37 PMRaw 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.
I turn off RAW video momentarily in code and turning it back on just before the screenshot is taken in my builds :P
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:
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.
I took the liberty to splitt topic. Change topic title as needed.