Full-resolution silent pictures (silent.mo)

Started by a1ex, July 01, 2014, 05:11:15 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.



First thing:
Thanks for the hard work that you have done on the FRSP!!! Very cool feature.
It looks like a great job and very interesting take on taking 500 images or so with a single shatter use.

I am new to ML, and might ask some stuff that was answered already, I spent about a day searching the forum in order to find some answers, but I still have some unresolved issues...

I do have one question, I want to try and see the image on my pc, that is connected to my camera. Until now I used the canon sdk in order to save the image directly to the pc. Can I do that with this feature? Can I see "Live Video" of FRSP on my pc? Will the canon sdk will work with ML?

Thanks, Asi.


FA_CaptureTestImage hack - https://bitbucket.org/Gr3g01/frsp-research/commits/0f35a12e5218da431ad901608d54b9c5fcf4315c

without hack - 329ms
with hack - 321ms

550D, mk11174
without hack - 281ms
with hack - 261ms

700D, mk11174
without hack - 250ms
with hack - 232ms


If I set the Intervalometer to the lowest interval possible I do not get one MLV file. The camera is writing one MLV file per image.
Is that behavior intended?
My camera is the 650D


My first test using FRSP (on Canon 50D) with my robotic Celestron 6" telescope. I did twenty 15-seconds exposures, and then stacked them using DeepSkyStacker software.

I wish there was a way to go beyond the 16s limit of FRSP; one could get much more spectacular deep sky photos with exposures 1-2 minutes.

Space fluorescent bulb by SyamAstro (500,000 views - thank you!), on Flickr


It's easy to patch Canon code to get 32 seconds, but not so easy to enable bulb mode.

I don't see much point in researching this though, since those very long exposures are unlikely to be shutter killers IMO.


Thanks Alex - do you mind providing a reference for the 32s patch? That already would be quite helpful.

In astrophotography, the main advantage of electronic shutter is not shutter life saving, but reducing camera vibrations. (It takes a long time for vibrations to taper off for a camera attached to a telescope.) Basically, you can do 2x more targets per night when you don't have to wait for the vibrations to die off after each shot in a stack.


If vibrations are a problem at these long exposures, then yes, it's a valid reason.

There is a semaphore in FA_CaptureTestImage that times out after 20 seconds. Just change the value with cache_fake (or patch_memory on patchmgr branch), similar to the dialog refresh timer hack used in raw_rec.

Maybe fiddling around with bulb mode and the SCS state object routines could give some clues.


I've never looked closely at the code yet, but hopefully I will figure it out. Thanks for the info.


How exactly would a silent picture cause mechanical vibrations? :P

Topic split to here.


Alex: I don't think you wanna deal with my raw data. It's 3GB, and needs lots of processing to become meaningful. (E.g. it needs registration - alignment; also dark frame subtraction - I shot 20 dark frames at the same time, same ISO and exposure.)

I just tried different fancy ways to do stacking inside DeepSkyStacker, and in terms of noise patterns Kappa-Sigma looks much nicer than the default Mean. (Mean produces ugly streaks in the noise floor.) But once you adjusted black/white points and gamma to the point when the noise is not obvious (like in my original photo above), all of them look almost identical; no real advantage in terms of faint stars visibility. So it does look like longer exposures are the answer (and likely switching to ISO 1600 from 3200).

Greg: an interesting patch. It looks like my 50D is not supported? Does it work with intervalometer?

I really have to (re-)learn to compile the code myself. I think I did it long time ago, but forgot the details.


Quote from: pulsar124 on June 15, 2016, 03:06:49 AM
(and likely switching to ISO 1600 from 3200).

On a 50D?

ISO 3200 is useless unless you like brightened images on the LCD.  All it does is throw away one full stop of dynamic range.  You loose one full stop of highlights but gain nothing in the shadows.



Quote from: pulsar124 on June 15, 2016, 03:06:49 AM
It looks like my 50D is not supported?

Just find capture_err_time_addr and 50D will take 30 seconds of exposure.
Bulb mode, I don't know, without a camera (50D, 60D, 70D, 7D, 6D, 5D2, 5D3) finding a solution will not be possible.

I checked it two years ago so I could be wrong, but I think 4 x 15s will be like 1 x 30s.
4 frames = 1EV


I tinkered a bit with my own 5-years old instructions, and finally managed to compile the Unified ML on my Fedora 22 distro using the following commands:

dnf install gcc-arm-linux-gnu.x86_64 gcc-c++-arm-linux-gnu.x86_64
dnf install arm-none-eabi-gcc-cs-c++.x86_64 arm-none-eabi-gcc-cs.x86_64 nacl-arm-gcc.x86_64
dnf install arm-none-eabi-newlib.noarch
hg clone -r unified https://bitbucket.org/hudson/magic-lantern
cd magic-lantern
make 50D

The last dnf install line was a tricky one - initially I was getting errors about stdint.h, and after some googling I learned that I needed the newlib package to fix that, and it worked.

Now I can try the longer FRSP mods...


Hmm, I'm not quite sure how to do the 32s mod.

Alex: I found a couple of "call("FA_CaptureTestImage", job)" lines in silent.c, long_exposure_fix, but I don't see the 20s timeout. I do see this line right before the function:

static uint32_t SLOWEST_SHUTTER = SHUTTER_15s;

which I guess I also have to modify?

Greg: I can't find any reference to capture_err_time_addr in the unified official ML source code...


Quote from: pulsar124 on June 15, 2016, 10:17:04 PM
Alex: I found a couple of "call("FA_CaptureTestImage", job)" lines in silent.c, long_exposure_fix, but I don't see the 20s timeout. I do see this line right before the function:

This is a fix for 500D/550D/600D - https://bitbucket.org/hudson/magic-lantern/commits/e5cc80ddd2f4304c1f6481955c83109ccd3bcada

Quote from: pulsar124 on June 15, 2016, 10:17:04 PM
Greg: I can't find any reference to capture_err_time_addr in the unified official ML source code...

Because it never been in official ML source code.


FA_CaptureTestImage is a function in Canon firmware.


capture_err_time_addr from Greg's code is the address of the 20s timeout I was talking about (in Canon firmware).


Thanks! Now the million dollar question is how to find the value of capture_err_time_addr for my Canon 50D. Unfortunately my friend google is helpless here (I was looking for an instruction on how to find the value, got zero hits.)

Greg, how did you get the addresses for the cameras you have (500D, 550D, 5D2)? Can I just put a printf statement somewhere to see it on my camera's screen? Or saved to the card as a text file?


Tutorial: finding stubs - will be helpful.

You need to find "FA_CaptureTestImage(hJob:%#lx)"
Then find the value of 0x4E20 (20000 ms).




Greg and Alex:  I disassembled the ROM1, found the line:

ff085a50:       e28f209c        add     r2, pc, #156    ; ff085af4: (435f4146)  *"FA_CaptureTestImage(hJob:%#lx)"

but I can't find 0x4E20 (or 0x4e20, 0x04e20, 0x004e20) anywhere. Does it mean my camera uses a different timing parameter (not 20000 ms)? What else can I do here?

EDIT: Okay, I think I have to search for 00004e20. Its first instance is found 20 lines below the above line (FA_CaptureTestImage(hJob:%#lx)):

ff085aa0:    e59f106c    ldr   r1, [pc, #108]   ; ff085b14: (00004e20)

and then 30 lines below the previous one:

ff085b14:    00004e20    andeq   r4, r0, r0, lsr #28

So which of the two addresses (if any) should be used for capture_err_time_addr - ff085aa0 or ff085b14?


0xff085b14  ;)

If this does not work, try 0xff885b14


Thanks Greg - I'll give it a try.

EDIT: Actually I didn't realize that "make 50D" doesn't compile modules. Now I did "make all_modules" after "make 50D"; some modules compiled fine, but for silent I got these errors:

silent.c: In function 'silent_pic_take_lv':
silent.c:969:9: error: implicit declaration of function 'PauseLiveView' [-Werror=implicit-function-declaration]
silent.c:1014:24: error: implicit declaration of function 'ResumeLiveView' [-Werror=implicit-function-declaration]
         if (LV_PAUSED) ResumeLiveView();
silent.c: In function 'display_off_if_qr_mode':
silent.c:1083:13: error: implicit declaration of function 'display_off' [-Werror=implicit-function-declaration]
silent.c: In function 'silent_pic_take_fullres':
silent.c:1228:9: error: implicit declaration of function 'display_on' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors

Should I just remove -Werror-implicit-function-declaration  and recompile? Or something is broken here?


Something is broken (try "hg diff" to see what changes you have done).