Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Totte

Pages: [1] 2
Scripting Corner / Re: Lua Scripting (
« on: January 25, 2016, 11:46:24 PM »
Here's another script that is oh-so close. The idea is to switch between two series of settings while shooting and toggle this 'mode' with the joystick. The logic seems sound and it all works perfectly when the camera.shoot() statements are commented out and I just watch the camera settings change. When the camera.shoot() statements are included, it still works in principle but several shots are fired off before the key event is handled. This is very frustrating, as I would guess that the ability to handle key inputs would increase with longer task.yield() periods, yet this is not what I see for reasonable values of task.yield(). Any ideas?

For those of you who are LUA experts: Apologies for my mistreatment of the LUA language :P

  name = "MultiSeq",
  select = function() task.create(multiseq) end,
  depends_on = DEPENDS_ON.M_MODE,

multiseq = function()

  shutters0  = {   1/4 ,    1/8,   1/16 }
  apertures0 = {   8.0 ,    5.6,    4.0 }
  isos0      = {   100 ,    100,    100 }

  shutters1  = {  1/32 ,   1/64,  1/128 }
  apertures1 = {  16.0 ,   11.0,    8.0 }
  isos1      = {   200 ,    200,    200 }

  elementsin0 = 3
  elementsin1 = 3

  seq = 0
  k = nil
  i = 1


  while true do
    if seq == 0 then
      camera.shutter.value  = shutters0
      camera.aperture.value = apertures0
      --camera.iso.value      = isos0
      i = i+1
      if i>elementsin0 then
        i = 1
    elseif seq == 1 then
      camera.shutter.value  = shutters1
      camera.aperture.value = apertures1
      --camera.iso.value      = isos1
      i = i+1
      if i>elementsin1 then
        i = 1
    k = keys:getkey()

    if k==KEY.LEFT or k==KEY.RIGHT then
      if (seq == 0) then
        seq = 1
        seq = 0
      i = 1
    elseif k==KEY.SET or k==KEY.UP or k==KEY.DOWN then
      seq = 2
      beep(1, 1000)


Scripting Corner / Re: Lua Scripting (
« on: January 25, 2016, 02:11:44 PM »
It's nice to finally have an official build with LUA included. Now I no longer have to wonder if the errors I encounter are from my own sketchy build and can instead concentrate on the LUA part.

I've experimented with camera.bulb(duration). The documentation says that duration is in seconds, but I soon discovered that it must indeed be in ms.

Even if I put a single camera.bulb(5000) statement inside a while loop there's still about 3 seconds before the next pic is taken with my 5D2. It is possible to fire off manual bulb exposures with at least 2s less delay between exposures with the same camera settings. Is this something that can be optimized in the camera.bulb() implementation or does the problem run deeper?


Scripting Corner / Re: LUA Scripting (
« on: June 10, 2015, 12:42:22 PM »
Thanks to both of you, I can confirm that I see the other scripts now.

In the console I get a bunch of 404's at startup before "Modules loaded":

There could be more, I just see it slowly printing auto_ettr_intervalometer_wait, then quickly overwriting it with the next two function names. Any idea where this comes from?

In the editor I am simply stuck as the Picture style button (which is supposed to be Q on the 5D2) does not open the menu. Key translation missing?

Scripting Corner / Re: LUA Scripting (
« on: June 09, 2015, 08:48:43 PM »
That makes sense, except that I don't see any trace of copy2m. Only Games is added to the top menu, with Sokoban as a sub-item. I guess I can make a copy of Sokoban and see how that goes. Thanks for the warning about the naming!

Does anyone have another precompiled LUA-compatible binary for the 5D2 that behaves better? If so I would gladly jump to learning and running LUA scripts ASAP.

Scripting Corner / Re: LUA Scripting (
« on: June 09, 2015, 06:11:32 PM »
Yes I was missing the /scripts/lib folder but like I said I copied it manually and then got to the point where I can play Sokoban ;D

Now trying to figure out where/how to run the rest of the LUA scripts in the scripts folder. Being all new to LUA I wouldn't be able to tell how this is supposed to work.

Scripting Corner / Re: LUA Scripting (
« on: June 09, 2015, 01:52:01 PM »
OK, finally time to play with this: I've checked out the LUA branch and compiled it for the 5D2 on my Linux machine. I end up with an empty doc folder but I've assumed that I can ignore that for now.

I copy everything from the zip file to my ML card and after enabling the LUA module I find the LUA Menu Test under Debug, but I don't see a separate LUA menu. After copying the scripts/lib folder from the source to the CF card I also see the Sokoban game with its own menu. I guess the make file will eventually be updated to include this folder in the zip target?

So where am I supposed to select which of the other scripts in the scripts folder to run, like how to invoke editor.lua? Is it just me being stupid, or am I still missing some vital LUA component on the CF card, or should I be investigating my build environment and make output?

Thanks for any help!

Scripting Corner / Re: LUA Scripting (
« on: May 11, 2015, 02:26:19 PM »
Just to clarify, I'm not asking for a re-implementation of the advanced intervalometer in LUA just because it can be done (although that is usually reason good enough ;)). For me, writing a script will be much simpler than to generate a complex exposure sequence in the AI. And the scripts can also easily be saved and loaded again from the camera.

I'm looking at taking pictures with sub-second timing resolution. What worries me is whether the length of while-loops or msleep(ms) could possibly be unpredictable because other system tasks have priority when scripts are running? No processing involved for me, just set new exposure values, wait and fire again.

Scripting Corner / Re: LUA Scripting (
« on: May 10, 2015, 11:03:32 AM »
How is the program control in modules in general and in this LUA implementation in particular? Is the LUA script in full control when it is running or are there system tasks that can mess up the timing of simple LUA while loops and/or timer interrupts? I can see this replacing the advanced intervalometer module completely for my kind of use, if timing can be trusted.

Scripting Q&A / Re: Scripting - ways forward?
« on: October 21, 2014, 04:45:04 PM »
Fantastic! That's what I get for thinking out loud without the camera in front of me.

Scripting Q&A / Re: Scripting - ways forward?
« on: October 21, 2014, 02:39:22 PM »
This got  me thinking: Would it be possible to modify the interval to the next shot/burst from your module? Apart from my special case where I'd like to squeeze in as many pictures as possible, this would also open up for ramping of the intervals as well, effectively accelerating/decelerating the speed of time-lapses. Could be a cool effect, no?

Scripting Q&A / Re: Scripting - ways forward?
« on: October 21, 2014, 12:52:47 PM »
OK, I can live with that.

Too bad there isn't a way to use the "like crazy" mode with your module, and that the intervalometer has 1 second as the shortest interval. I guess it will be possible to get a higher effective picture rate with the combination of intervalometer and bracketing though. Will have to experiment a bit to see if the behavior is predictable if the bracketing causes the combined time too exceed the 1s timing interval; I mean, in my example above, would one burst exceeding 1s cause skipping of the next burst, and if so will the sequence be 10 bursts (and hence taking 1s longer in total) or will it still terminate after 10 timer ticks (and only 9 bursts)?

Scripting Q&A / Re: Scripting - ways forward?
« on: October 20, 2014, 11:03:08 PM »
OK, I've had a proper go with the advanced intervalometer now, and it's a powerful tool. However, I encountered a behaviour that I would consider a small bug:

I intended to create an exposure sequence as follows: 0.5", 1/4", 1/8", 1/15", 1/30", 0.5", 1/4", 1/8", 1/15", 1/30" (ISO and f/ held constant)
So I created keyframe 1 with 0.5" and keyframe 5 with 1/30", and set the sequence to repeat after frame 5. The camera was left with the settings from keyframe 5 and the intervalometer set to start at half-pressed shutter. I pressed the shutter button very gently to avoid taking a picture 'manually', yet the resulting sequence was: 1/30", 0.5", 1/4", 1/8", 1/15", 1/30", 0.5", 1/4", 1/8", 1/15"
In other words, it started with the current camera settings, not the first key frame, and then it continued to be off by one.

Oh, and if I set the interval to 'take pictures like crazy' there is no ramping at all, all 10 pictures are taken with TV=1/30" with the same keyframes. Sorry if this is old news, just thought I'd mention my observations in case it can help improve the tool even further.

Thanks again!

Scripting Q&A / Re: Scripting - ways forward?
« on: October 20, 2014, 07:17:25 PM »
Ah, got it. The keyframes concept wasn't all clear to me, but I see now that this will work out very nicely. Setting up a couple of hundred or thousand identical exposures should also be very easy by 'ramping' between two identical frames, right?

I will try to get the .mo working and experiment a little before bothering you further. Thanks a lot!

Scripting Q&A / Re: Scripting - ways forward?
« on: October 20, 2014, 06:07:48 PM »
Thanks, I will have a look at I have actually already tried it very briefly, but I couldn't enter the 'Advanced intervalometer' menu, nothing happens when I press the Set button. Surely a user error on my part, if it is compatible with the current nightly build at all. I'll try again with a fresh .mo file, I can't remember where I got it from and it may not be the latest version.

When you say 'custom exposure sequence', are you talking about ramped-something, or is there actually an option to specify arbitrary sequences directly?

ETTR seems like a wonderful tool for normal photography, but it seems almost counter-productive for the diamond ring phases and the totality, where dynamic range is enormous (think HDR). Am I missing something?

Before and after totality the exposures are constant, so in an ideal world I'd like to have the exposure sequences set in advance, and just flip off the solar filter and change from one sequence to another with the press of a button (or time the whole ting as precisely as possible in advance and just concentrate on removing the solar filter when I hear the change in exposure times).

Scripting Q&A / Scripting - ways forward?
« on: October 20, 2014, 03:14:00 PM »
I took an interest in ML a couple of years back, when I wanted to automate the process of shooting solar eclipses. At the time it looked like ML with PicoC scripting was going to provide everything I could wish for, but my 5Dc wasn't supported because of a lack of memory, if I remember correctly. So instead I hard-coded an exposure sequence to work along with the intervalometer and compiled it for the 5Dc.

Now that I've decided to with 5D mkIIs it looks like both PicoC and TCC have been abandoned completely(?). Any hope of a resurrection of this feature, or is the module approach the only way forward? Has anyone made a simple example module based on a timer and a preset or calculated exposure sequence?

Or if there are still pre-compiled versions of ML with PicoC support out there, could someone point me in the right direction, please?

Any ideas or pointers appreciated!

And thanks for all the effort that has went into ML!


(PS! I am able to compile the current Unified code (except for some documentation issues) and I am prepared to hard-code my exposure sequence again if I have to, but although it gets the job done it doesn't exactly seem like the right way to go about it.)

General Development / Re: 5Dc in Unified doesn't compile
« on: May 09, 2013, 10:10:19 PM »
I played around with your autoexec.bin and compiled my own with picoc just to confirm. The LED stays blue forever even with an empty SCRIPTS folder, so I guess the loading of picoc is just too much for 5Dc.

I now see why I was so confused about the Quick erase option earlier: It works only when deleting via the Play menu. If the erase button is pressed just after taking a pic, Cancel is selected as default regardless of the Quick erase setting. Perhaps this is obvious to some, and even how it is supposed to work, but it was certainly enough to confuse me :-\

General Development / Re: 5Dc in Unified doesn't compile
« on: May 06, 2013, 09:27:06 PM »
My camera reports 2524k free memory right after start-up. Sounds like alot, is there anything that will really dig into those 2.4M during use?

BTW, would it be possible to hijack the shutter button full press and start the bulb timer that way instead of the awkward 1s half-press? When mode is set to B *and* bulb timer is set to on I think it's fair to assume that the user wants to use bulb timer.

General Development / Re: 5Dc in Unified doesn't compile
« on: May 05, 2013, 03:54:45 PM »
You are absolutely right, I rechecked the Quick erase now and it works! I could've sworn that there was absolutely no difference between the on/off settings last night  :-[

General Development / Re: 5Dc in Unified doesn't compile
« on: May 05, 2013, 01:00:11 AM »
In addition to the Bulb timer, I've found that the Quick erase, Sticky half-pressed shutter button and Sticky DOF button don't do anything.
Those are all features that I personally would find useful, but I haven't checked if the sticky button features where even meant to be included for 5Dc or in beta4.

I haven't really tried all the ins and out the zebras and spot thingies, as I don't really see what they would be useful for, but they seem to be there and doing something. Very happy to see that the bracketing, intervalometer and MLU functions are all working like a charm.

Any pointers to what other scripting options could become available?

General Development / Re: 5Dc in Unified doesn't compile
« on: May 02, 2013, 12:40:50 PM »
Thanks, guys! I was able to compile a working autoexec.bin from yesterday. (Still had to modify the makefile to "PICOC = n" though)
Is there any hope at all that PICOC could be made to work with 5Dc, or is the hardware just too limited, as was implied earlier in this thread?

Oh, and I also played with the camera for a little bit. The intervalometer works but I couldn't get the bulb timer to work, with or without the intervalometer. Is that perhaps because the Bulb mode is only detected correctly on the cameras that have B at the end of the T range, and not B as a separate choice on the mode dial?

General Development / Re: 5Dc in Unified doesn't compile
« on: April 26, 2013, 09:29:17 AM »
OK, but I'm still having the same problem as reported by scrax above.

Any idea what prevents ML from starting? Otherwise it seems I have to go back to the Unified version that had a working 5Dc port and try to see where it all went wrong. Can anyone confirm that the working beta4 was indeed compiled from Unified?

General Development / Re: 5Dc in Unified doesn't compile
« on: April 24, 2013, 02:17:58 PM »
So, is there a way that a mere mortal like myself could help find the correct address for SetGUIRequestMode()?

General Development / Re: 5Dc in Unified doesn't compile
« on: April 18, 2013, 04:08:57 PM »
CONFIG_PICOC = n in Makefile.user.default and the following declarations in dummy.c did indeed produce an autoexec.bin file.

int was_sound_recording_disabled_by_fps_override() { return 1; }
int fps_should_record_wav() { return 0; }
void movie_tweak_menu_init() {}
int hdr_video_enabled() { return 0; }
int get_digic_iso_gain_movie() { return 0; }
void SetGUIRequestMode(int name) {}

I'm going away for a few days, but I'll see if I can brick my camera with this next week :P  Thanks!

General Development / Re: 5Dc in Unified doesn't compile
« on: April 11, 2013, 10:14:39 PM »
Thanks for the clarification.

General Development / Re: 5Dc in Unified doesn't compile
« on: April 11, 2013, 02:43:39 PM »
Nobody touched the 5Dc port since months.

How should I read this message? Are the compile errors to be expected because nobody has completed the port, or should it (still) compile because nobody has messed with it?

I was under the impression that the 5Dc had now been integrated in Unified, but I've reverted to the pre-compiled toolchain that should work with the unmodified make files (gcc-arm-none-eabi-4_7-2012q4-20121208-linux.tar.bz2), and I still get the same errors. The ones already listed under SUPPORTED_MODELS compile fine, though.

So, is the announcement "EDIT The 5dc will work on the unified tree! Big thanks to A1ex for the help in making this happen." found at a bit misleading or am I missing something?

Thanks again!

Pages: [1] 2