Fine-tuning Framing preview to speed it up

[dpjpandone]

This part of code:

Code: [Select]

    /* be gentle with the CPU, save it for recording (especially if the buffer is almost full) */
    msleep(
        (need_for_speed)
            ? ((queued_frames > valid_slot_count / 2) ? 1000 : 500)
            : 50
    );
Controls when it's okay to refresh Framing preview depending on RAW recording state, this part of code add delays while recording for Framing preview to slow down refresh rate.
If you removed this part of code you will have semi real-time preview in B&W during RAW recording, of course this will make CPU usage 100% all time and there is high chance you will have corrupted frames.

But we can probably fine-tune the delay (reduce it), play with 1000 and 500 values (decrease them).
1000 and 500 are in milliseconds.

I am playing with this now. I think the only way to test for stability is to record in a resolution that is higher than continuous because the slot error happens when the buffer is full, any thoughts?

also:

I noticed Danne modified these values in Raw.c:

Code: [Select]

     /* scale useful range (black...white) to 0...1023 or less */
+    /* changing from 1024 to 700 for speed reasons */
     int black = raw_info.black_level;
     int white = raw_info.white_level;
     int div = 0;
-    while (((white-black) >> div) >= 1024)
+    while (((white-black) >> div) >= 700)
     {
         div++;
     }
 
-    uint8_t gamma[1024];
+    uint8_t gamma[700];
     
-    for (int i = 0; i < 1024; i++)
+    for (int i = 0; i < 700; i++)
Does this reduce CPU overhead?

[dpjpandone]

Very stable with the following values:

Code: [Select]

(need_for_speed)
            ? ((queued_frames > valid_slot_count / 2) ? 416 : 208)
            : 20
(I chose multiples of 24/1000) .0416

Pushing it much harder produces slot error when buffer is full and recording stops (5d3.123)

I would like to discuss cleanest way to implement as a menu option, (and what to call it) I like the behavior when Gray Ultrafast is used full time, but pressing halfshutter switches to realtime (5x) almost like a magic zoom) I honestly think the color half-res preview is useless.

[Danne]

Let´s test this out:
https://www.magiclantern.fm/forum/index.php?topic=23041.msg241997#msg241997

[ciutadellla]

Hi, just tested the latest build and the canon and ml menu stoped working. They get stuck, i can go into the menu in photo mode.

[dpjpandone]

You need to deletew your settings folder

[dpjpandone]

Danne, bilal,

Can we talk about implementing an option under preview menu for full-time ultrafast gray? I was hoping we could all agree on menu structure/name/behavior so that it's consistent across bodies. Are you guys interested? first thing to discuss I think is behavior

[Danne]

On eos m? It's already on always. Why bother with a menu here? The same goes for 5diii. If not you can present some idea of what ypu want.

[dpjpandone]

I'm not asking you to incorporate this into your builds danne, I'm doing my own thing on 5D3.

I already added it as a menu option on mine. The way I have it set up is:

-realtime
-framing (same as it always was, automatically switches to Gray when buffer is almost full)
-gray ultrafast (full time)
-Frozen LV (liveview is frozen if kill global draw is set to enable in raw menu)

 I have not worked out what the behavior should be on auto. That's what i wanted to talk about. It's fine if there is no interest.

[Danne]

I see.
I recall auto as real-time and when halfshutter pressed framing. Could remember wrong   .
I enable ultrafast always as switching between color and ultrafast while recording takes a hit in length of recordings sometimes.