600D, Photo-mode M, no crop, silent pictures simple, Quality raw
TL2.0 compiled 22.9.2013
If I take some single silent pictures, I get a lot of pink pictures.
If I take silent pictures, pressing the shutter release continuously, I get no pink pictures and all is fine.
Why this different behavior?
Edgar
Additional Info, just tested:
Shooting in burst mode: no pink pictures, all is ok.
Shooting in simple mode: distorted pink pictures.
I do not understand, why there are so many distorted pink pictures in simple mode. And just this simple-mode is needed for focus-stacking...
Edgar
Does it help if you enable the raw histogram, for example? If you do that, LiveView will stay in raw mode.
After enabling raw mode, silent pic code probably needs waiting until the next LV frame, as ETTR already does: auto_ettr_wait_lv_frames should probably be moved in the core and used here too.
The raw histogram was enabled when shooting
Edgar
Try disabling the RAW video module.
iv noticed too many modules sometimes can cause pink frames.
Update: On silent shutter simple mode, pink frames , intervalometer no pink frames. Global draw on, raw histogram on, raw video module disabled and enabled.
Update 2: if you press shutter button then wait a second or so and take another no pink frames, if you press straight after taking a pic, pink frames.
I´m sorry, but I cannot avoid these pink pics. With intervalometer, I get some pink pics too. With TL2.0 it is better than with ML (just compiled ML from the latest sources). Now I´m waiting for 1% updating the sources of his TL2.0 repo to shoot some more tests.
Edgar
with the very latest today i found that button bashing the shutter button i got pink frames BUT i did forget to put the lens on to M/focus so i think i tricked it out... as for intervalometer i got none.
Hi Doyle, thanks for help
Here a new try with ML compiled from sources 20min ago.
Intervalometer on, 100 shoots, 1frame/s
MF: 4 of 100 frames are pink
AF: 5 of 100 frames are pink
Intervalometer off, Fokusstack on for 100 steps
6 of 100 frames are pink
Intervalometer on, shoot like crazy, 100 shoots
MF: 5 of 100 frames are pink
silent.mo was the only module loaded, camera set to RAW and M
I guess, I cannot use my 600D for focusstacking with silent pictures :'(
Edgar
Can you post some of them? Pink has a lot of meanings, especially in the context of Canon raw images ;)
looks like there is the same behavior on a 550D. Also the rate ~ 6/100
(http://i.imgur.com/Ccxs3hZl.jpg) (http://imgur.com/Ccxs3hZ)
edit:
tried it in and photo and movie and without global draw. The camera was also triggered remotely without the intervalometer.
All cameras with shitty vsync.
Quote from: 1% on October 02, 2013, 04:07:18 AM
All cameras with shitty vsync.
Do you think there is no way for stable silent pics with these cams?
The first thing needed is a consistent way to reproduce them.
on 600D you are guaranteed to reproduce, for me i get none using Intervalometer though..
my test on all nightlys for pink frames is, Load the silent module, set to simple, button bash for a few photos, then i take a photo every second (these two always produce pinks for me) i move onto Intervalometer, every 4seconds, 2second delay, but like i say i dont get them in Intervalometer for some reason like others.
@wolf,
Was the camera moving in the scene where pink frames occurred? iv noticed most of my pink frames occur when the image on the cameras screen is moving.. when camera is still and screen image is still no pink frames.
Yes the cam was rotating 20 degree while shooting 100 frames, but if you shot clouds the image is also changing while the camera stands still.
I have no clue how to force pink frames.
Just tested with intervalometer. 100% OK for 200 pics.
Would it be possible to trigger silent pics like the intervalometer does it set to "Stop after 1 shot" ; "Take 1 shot"?
QuoteI have no clue how to force pink frames.
Turn on MZ or do something else cpu intensive. I can't reproduce on like 7D or 6D but on 600D its fairly easy.
The camera triggered remotely or with half shutter causes pink frames, with the intervalometer triggered "silent pic" is working fine.
I took a look in the source code (silent.c) and found this.
static unsigned int
silent_pic_take(unsigned int interactive) // for remote release, set interactive=0
{
if (!silent_pic_enabled) return CBR_RET_CONTINUE;
if (!lv) force_liveview();
silent_pic_take_raw(interactive);
return CBR_RET_STOP;
}
Should I set a "0" there?
"// for remote release" - that's what I like do :-)
ill try with my lcd flipped other way tomorrow but to be honest i cant see that changing anything really could it?
@wolf
Iv tested with pressing the back focus button next to af points and that produces pink frames still.
Quoteill try with my lcd flipped other way tomorrow but to be honest i cant see that changing anything really could it?
:-)
I did try to understand, where is the difference between taking a single pic with half-shutter and taking it with intervalometer.
The code is too complex for me to understand, but the only difference I found is that the intervalometer does runs a
lens_wait_readytotakepic(64);
function before shooting, but due to the complexity of the code I'm not really sure.
I tried to put this function inside silent.c
lens_wait_readytotakepic(64);
int raw_flag = 1;
raw_lv_request();
Doesn't change anything :-(
(http://i.imgur.com/QMqwnsj.gif)
I switched back to TL2.0 for testing.
Using TragicLantern with focustacking and silent picture, I got much more pink frames (20%), than with magiclantern.
but
If I disable global draw: No more pink frames.
Edgar
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
MagicLantern Silent Pictures
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
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.
Maybe it solves the 600D problem too.
http://www.magiclantern.fm/forum/index.php?topic=8008.msg81865;topicseen#msg81865
Quote from: wolf on October 09, 2013, 08:22:06 PM
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
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.
Much better with only very few corrupted pics in simple mode, if I allocate more RAM like this:
original silent.c
/* 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
/* 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
I think the only difference is a delay (trying to allocate the entire memory is slower).
I did another try:
/* 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
i wouldnt mind the slowness, be nice to see this in the nightly for 600D if possible?
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
Try the workaround from wolf (much cleaner and without memory leaks).
Quote from: a1ex on October 27, 2013, 06:37:47 PM
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
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.
Quote from: escho on October 27, 2013, 05:56:09 PM
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 :)
Quote from: Doyle4 on October 27, 2013, 11:48:28 PM
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