Messages

Thanks! It does sound that a simple photodiode circuit will not do the trick. I have a few Arduino Nano lying around, will be playing with different lags and logics (if I recall correctly there is more than one LED flash per shot).

Here is a new interesting application for the FRSP feature: 3D scanning of real objects, via the method of photogrammetry (https://en.wikipedia.org/wiki/Comparison_of_photogrammetry_software). Basically, one has to take hundreds of pictures of the object from different angles, and use a smart software which would find and match features across the photos, and fit a model to it (3D model of the object + the camera positions + the model of the camera and lens).

Here is my simple setup for taking pictures (of small objects; the purpose is to reproduce objects using my 3D printer):

- a rotating platform driven by a stepper motor (1600 steps per full rotation);
- home photostudio lighting (two large softboxes and reflectors) using speedlights triggered by a single RF controller;
- camera (Canon 6D) on a tripod pointing at a small object sitting in the middle of the rotating platform, taking photos of the object at regular intervals (say every 2s - using the intervalometer feature of ML).

It all works pretty well, except that I don't wont to burn the shutter of my 6D for this stuff. It takes at least ~50 shots per object to build a model, and likely a few times more to also incorporate focus stacking into this (so probably ~250 shots per scan). FRSP would fit nicely here - if I could make it work with my setup.

At the very least, I need to have my flashes go off every time the intervalometer takes a FRSP photo. I saw reading the light from the camera LED suggested in this thread as the solution for this problem - can anyone give a reference to a page where this is discussed in detail? I couldn't find details in this thread. Specifically, I need to know if there is a lag between the LED flash and the actual FRSP exposure. If there is no lag, I can use a simple photodiode circuitry to do the trick, but with a lag I'll likely resort to using a microcontroller.

The first post in this thread mentions that when FRSP is used with  intervalometer, the shortest possible time interval is ~10 seconds. Is it still the case, specifically for 6D? Ideally, I'd like to use a 2s interval.

Has anyone tried Advanced Intervalometer module with FRSP? Will it work? My idea is to take continuous photos of the rotating object over the course of a few full rotations, while slowly shifting the focus from the foreground to the background of the object. My hope is that one doesn't need to do a bunch of focus stacking before running the photogrammetry software (this will significantly complicate the process); instead, one would just slowly vary the focal point while taking hundreds photos of the rotating object, and let the photogrammetry software find and match all the sharp features of the photos, which at the end should recover the whole extent of the object.

I just spent some time trying to make it work on my new camera (Canon 6D) with my new lens (Tamron 24-70 f2.8 VC). Two points:

- I couldn't make it work (the camera would continue beeping on all the points tried - no bad points at all), until I followed the advice I found online: to switch the camera (using Canon's menu) to "All lenses by same amount" option, in the AF microadjustment menu option.
- Despite the almost perfect setup, the dot-tune method produced very inconsistent, and mostly wrong results, in particular for the tele-end (70mm) of the lens. My setup: high quality target printed on a large piece of paper (12x18"); direct sunlight on the target; 5m distance from the target; initial focusing done using a remote control (smartphone connected to the camera via USB cable or WiFi), to prevent camera shaking when focusing; sturdy tripod for the camera; multiple tries (refocusing every time). I was getting MFA mostly around -2 ... -5, and around -8 for the wide end (24 mm). When testing these values directly, by taking shots of the target I discovered that the -3...-4 value for the tele-end were consistently producing images which were obviously less sharp than contrast detection shots. When I switched to constant MFA=-7, both tele and wide end shots became as sharp as contrast detection shots.

I've been using dot-tune for years, but unfortunately it looks like dot-tune results should be taken with a grain of salt. I will be re-testing my other lenses, as I don't have confidence in dot-tune results anymore.

Sorry, it was my fault - I think I tried to run dot-tune in Av mode (which seems to work with other lenses, but probably not with the new 50mm  lens). I tried the test again, this time in Manual mode, and it worked as expected - giving me the MFA = -6, -6 -5 at distances 8, 3, and 1m. (BTW it looks like MFA changes a lot near MFD ~0.3m: it became +13 in my test).

Anyone had issues with the new Canon's prime, 50mm f1.8 STM?  This is the first lens where dot-tune on ML doesn't seem to work - it shows perfect focus for the entire range of MFA. Perhaps it has something to do with the fact that this lens uses "focus by wire" (focusing is not mechanical, it's electric; e.g. it doesn't work when the camera is powered down or the lens is disconnected from the body)? For other lenses dot-tune works just fine.

josepvm: Thanks for the info. My modded silent.c is exactly like yours, but I do get the RAW write error at 30s exposure. There must be some difference in either the compiling environment, or camera settings. I wonder if the ML version makes a difference? Which version are you using - is it the Greg's branch, or one of nightlies (which one?) with the silent.c replaced by the Greg's version?

EDIT: I just notice that you are using the Greg's branch. It kills my camera for some reason - it must be the compiling environment difference. Which gcc version are you using? What about the arm cross-compiler? Mine are:

gcc: 5.1.1
arm-linux-gnu-gcc: 5.3.1

I think I saw recommendation to use 4.8.x (for both?).

No, it doesn't work for me. Summary:

a) When I simply copied the Greg's silent.c to official magic lantern nightly source, added my fix for 50D, and then compiled, everything worked fine (e.f. FRSP at 15s), but when I use FRSP at 30s, it does the 30s exposure, then I get error message "RAW error, falling back to YUV overlays", and them my display dies (I have to remove battery to bring it back to life).

b) When I cloned the whole Greg's branch and compiled for 50D, it kills my camera instantly, the moment I turn the power on  - camera shows no signs of life until I switch the card and remove battery.

So something is screwy here. I think I better wait until the Greg's long exposure fix makes it to nightlies.

A question: can RAW video FPS be made to go below 0.125? (That's what my 50D currently have.) Because another way to shoot these long exposure FRSP shots would be to record RAW video at very low FPS.

josepvm : Thanks! That did the trick!

dmilligan: Thanks. I wasn't sure how to provide the "cam directory" (/media/EOS_DIGITAL), but after some tinkering I simply added it to the Makefile.user.default file, and ran

make install -C platform/50D.109

without issues.

Greg: I did "hg clone -r unified https://bitbucket.org/Gr3g01/magic-lantern-frsp-long-expo", and it compiles okay for 50D (make 50D and make all_modules work okay), without the error messages I saw with the official version, but running "make" or  "make install" fails because of some issues with 7D and 1100D branches.

Is it possible to run make install for a specific model (50D)? I guess I can just run "make 50D; make all_modules" and then collect the files I need by hand, but perhaps there is an easier way?

The only changes shown by hg diff are the Makefile customizations, and a bunch of changes in silent.c . I just replaced the official silent.c with the Greg's version - I guess that wasn't the appropriate way, and I should have checked out his branch? How can I do that (I am not familiar with hg; I know svn and git).

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]
         PauseLiveView();
         ^
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]
             display_off();
             ^
silent.c: In function 'silent_pic_take_fullres':
silent.c:1228:9: error: implicit declaration of function 'display_on' [-Werror=implicit-function-declaration]
         display_on();
         ^
cc1: some warnings being treated as errors


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

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?

Thanks, will look into this.

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?

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...

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...

dmilligan: It's all down to pretty simple math (probabilty theory), no need to do too much experimenting. For exposures up to ~1min pixel noise is more or less constant, and it's well known that averaging measurements contaminated with gaussian noise improves signal to noise ratio as a square root of the number of measurements, so when you fix your total exposure (sum of individual stacks), the SNR will scale inversely proportionally to the number of shots. Say, 4x 60s will have two times better SNR than 16x 15s, with the same total exposure (4 min). But at exposures >1min thermal noise becomes important, and thermal noise scales with exposure time, so increasing exposure to >> 1min will no longer improve SNR, as both the signal and noise will grow at the same rate. (Actually, things are likely more complicated than that, this is just a simplistic outline.)

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.

Well, I already provided one experimental proof: in my astrophotography tests, going from 20x to 100x 15s stacks doesn't improve sensitivity even a tiny bit (for Canon 50D at ISO 3200). Apparently ISO 3200 is a particularly bad choice (in terms of read noise; see http://sensorgen.info/CanonEOS-50D.html). I plan to redo my tests with other ISO, specifically ISO 1600 where the read noise is 6x lower. I am also testing different stacking algorithms (my original test results used the default Mean algorithm; I will test Median, Kappa-Sigma etc.)

That's what I'm doing right now, but apparently there is much more to astrophotography with DSLRs than the simple idea of "combine shots to increase S/N ratio". I discovered that effect myself, when I ran two stacking sequences of deep sky, one with 20 shots x 15s, the other one 100 shots x 15s, both at ISO 3200. I was puzzled to discover that both stacked photos had the same sensitivity (the same limiting magnitude), whereas I expected ~2.2x better S/N in the longer stack. Apparently this has to do with counting individual photons for these extremely faint objects, and averaging stacks no longer helps; one has to go for longer exposures to go deeper.

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

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.

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

I thought I was reading somewhere in this thread that this (taking a "normal" picture when FRSP is on) can lock your camera, and at the very least it wasn't recommended.

My understanding is that when FRSP is enabled the shutter control (full-pressed shutter trigger) serves no useful purpose, and in fact is harmful (if you accidentally trigger it it will mess up with FRSP picture taking) - correct?

Is it possible then to disable the shutter control in Live View when FRSP is enabled? Only half-press (AF control) would be left operational.