600D: pink silent pictures

[escho]

TL2.0

Using Intervalometer with global draw off and silent pics: No fink frames
Shooting single silent pics (simple): Some pink frames (not so important for me)

Isn´t it possible to force global draw to off automatically, if I start focusstack or intervalometer?

Will do some testing in magiclantern later

Edgar

[escho]

MagicLantern Silent Pictures

Code Select Expand

global draw: on pink frames in all modes, I´ve tested

global draw off, Intervalometer: like crazy no pink frames
global draw off, focusstacking no pink frames

global draw off, single shoots with 4s delay, AF pink frames (20%)
global draw off, single shoots with 4s delay, MF pink frames (15%)

That´s, what I found, more I cannot help.

Edgar

[wolf]

Can't figure out any way to avoid pink frames. 
I even tried to trigger the intervalometer set to 1s and 1 pic with half-shutter and got only 1 pink frame out of 100, but it is too much for a timelaps with camera motion.

Seems like a complicated sync problem that occurred even with the old 422 pics as far as I remember.

[wolf]

Maybe it solves the 600D problem too.
http://www.magiclantern.fm/forum/index.php?topic=8008.msg81865;topicseen#msg81865

[escho]

Maybe it solves the 600D problem too.
http://www.magiclantern.fm/forum/index.php?topic=8008.msg81865;topicseen#msg81865

I tested this on my 600d: Still pink frames here with single shots (globaldraw off).

Edgar

[wolf]

Be sure that you trigger with the pause after the Canon stuff disappears. Canon display settings are set to most less information. (I don't know the 600D).
You could try to set a longer pause.
Silent pic was set to "Simple" while trying.

[escho]

Much better with only very few corrupted pics in simple mode, if I allocate more RAM like this:

original silent.c

Code Select Expand

/* allocate RAM */
    struct memSuite * hSuite = 0;
    switch (silent_pic_mode)
    {
        /* allocate as much as we can in burst mode */
        case SILENT_PIC_MODE_BURST:
        case SILENT_PIC_MODE_BURST_END_TRIGGER:
        case SILENT_PIC_MODE_BEST_SHOTS:
            hSuite = shoot_malloc_suite(0);
            break;
       
        /* allocate only one frame in simple and slitscan modes */
        case SILENT_PIC_MODE_SIMPLE:
        case SILENT_PIC_MODE_SLITSCAN:
            hSuite = shoot_malloc_suite_contig(raw_info.frame_size * 33/32);
            break;
    }
   
modified silent.c
   

Code Select Expand

/* allocate RAM */
    struct memSuite * hSuite = 0;
    switch (silent_pic_mode)
    {
        /* allocate as much as we can in burst and simple mode */
case SILENT_PIC_MODE_SIMPLE:
        case SILENT_PIC_MODE_BURST:
        case SILENT_PIC_MODE_BURST_END_TRIGGER:
        case SILENT_PIC_MODE_BEST_SHOTS:
            hSuite = shoot_malloc_suite(0);
            break;
       
        /* allocate only one frame in slitscan modes */
        case SILENT_PIC_MODE_SLITSCAN:
            hSuite = shoot_malloc_suite_contig(raw_info.frame_size * 33/32);
            break;
    }
   
Edgar

[a1ex]

I think the only difference is a delay (trying to allocate the entire memory is slower).

[escho]

I did another try:

Code Select Expand

    /* allocate RAM */
    struct memSuite * hSuite = 0;
    switch (silent_pic_mode)
    {
        /* allocate as much as we can in burst mode */
        case SILENT_PIC_MODE_BURST:
        case SILENT_PIC_MODE_BURST_END_TRIGGER:
        case SILENT_PIC_MODE_BEST_SHOTS:
            hSuite = shoot_malloc_suite(0);
            break;
       
        /* allocate only one frame in simple and slitscan modes */
        case SILENT_PIC_MODE_SIMPLE:
        case SILENT_PIC_MODE_SLITSCAN:
//            hSuite = shoot_malloc_suite_contig(raw_info.frame_size * 33/32);
      hSuite = shoot_malloc_suite_contig(0);
            break;
    }
   
Seems to be a little bit slow, but I get no more corrupted frames (LV normal and LV 5x-crop) for the moment. It´s working for me and I can live with the delay. I´m playing on...

Edgar

[Doyle4]

i wouldnt mind the slowness, be nice to see this in the nightly for 600D if possible?

[escho]

This is not very well tested by me. An it would affect all other cameras too. So I don´t want to create a pull request for this change yet, that would go into the nightlys

Edgar

[a1ex]

Try the workaround from wolf (much cleaner and without memory leaks).

[escho]

Try the workaround from wolf (much cleaner and without memory leaks).

I tried it some days ago, but with no success. And I took a longer delay, as wolf suggested, too. No success. Still many corrupted frames.
With my workaround I still get no corrupted frame till now ( even with GD enabled)

I´ll stay with this solution, till I find a better way.

Thanks for responding

Edgar

[a1ex]

In this case, measure how much time the new allocation method requires (with get_ms_clock_value), and use that number for msleep. Allocating a larger chunk of RAM doesn't explain the different behavior.

[Doyle4]

This is not very well tested by me. An it would affect all other cameras too. So I don´t want to create a pull request for this change yet, that would go into the nightlys

Edgar

Ah ok no worries, wish i could code to test this

[escho]

Ah ok no worries, wish i could code to test this

You only must compile this whole stuff. And that is not so difficult in Linux (in Windows I don´t know). The "coding" before compiling is only copy and paste for a "non-coder".

I tried the method of wolf once more and set msleep to 1100.: no more corrupted frames at the moment. Great!

I mesured the time with "get_ms_clock_value", but I must have done something wrong, because it told me about 8000ms. And that´s not true.

Thanks to you all for helping

Edgar