Messages

I agree, PicoC seems the simplest solution to start with, now we only need a volunteer 

@g3gg0
Is A1lex say right that you have some aces in the hole for TCC software floating point?

@dmilligan

Like Marsu42 the Lua Scripting never worked on my 60D, and the old PicoC version it's now too old, too many big feature are missing..RAW video for first.



@engardeknave

I check the Bitbucket committs daily and compile it almost everytime something newer is added, so I agree with you that 3 months can be an ethernity in the ML world

I would be pleased to hear good or simply WIP news about that but unfurtunately, in this case, from the last words wrote from A1lex (no further message about script engine porting later), we can't hope in any happy-end for the TCC port.

Pleased to hear something different from everyone...(A1lex included of course)

@Marsu42,
You hit the mark

I think for example with my knowledge I can try to write some simple scripts but writing modules is more complicated...
Creation of module is a little too difficult for me, but with my idea of a module template script and some APIs I can start to try something.
The APIs migration from PicoC can be also a step in the right direction to port it for a (maybe) future TCC module.

@engardeknave

The last message by A1lex is dated 16 August 2013, is not so old.
Maybe I forgot something in the forum but after that message I didn't read anything about TCC progress and message itself seems a almost a stop of effort to port TCC for insuperable (at the moment) difficulty.

From what I read in the last A1lex post here:
http://www.magiclantern.fm/forum/index.php?topic=4877.0

I'm not optimist at all,
TCC for scripts seems to be a dead rail. 

The idea is basically to encapsulate scripts in a blank template module, so that you can directly run it (instead of the pure script) in-camera.
It will also have some advantages over a PicoC port ... for example it will not affected from PicoC slowness http://www.magiclantern.fm/forum/index.php?topic=5014.0 because is already compiled.

Hello,

What about the possibility to have some APIs to create scripts and compile it "like a module" so that we can circumvent the big problem of the impossibility of TCC in-camera compiling?
The basic ideas is that it can be a sort of template module where you only need to call the APIs and then compile it like other modules.
After that they can be simply runs as a modules.
In order to maintain a simple one-click run maybe at the start of that script-modules it ask immediately to confirm (with "SET") or edit (with another button) the built-in script parameters (like intervals, etc).
I don't remember if still they are problems to unload modules but probably for not very complex scripts the memory used it isn't a real problem. (I hope)
Maybe it's not so flexible as real scripts (ex. you can't edit it on camera, except for the parameters) but it would be a big step forward.

I was already using the latest version (downloaded some minutes before posting)

Select multiple file with CTRL play selected files at full speed, not stop the animation 

Also have the ability to enlarge a little the animation windows it can became a great feature

Hello,

I think a useful feature it's the ability to delete files from within the MLV Browser.
Often there are some files that you recognize as bad/wrong from the beginning.
Now the mouse right click open the context menu but when you try to delete a file, Windows recognize the file as in use and it's not possible.
Be able to stop "rendering" some files (so you can delete them) maybe will also speed up other files.

Set as last mk11174 post and now it works!!
Thank you.

Thank you TakeTheShot for your perfect analysis.

I understood the doubts but I often was in a situation where it can be very useful have it.
I agree with you it can be a good idea to have some simple sanity check to have the interval time not smaller than exposition time.
Also the problem of having a lot of shutter actuation is true only with long interval, but you encounter the writing speed problem as soon the memory buffer is full and write speed on SD in not enough not even for 1 full frame/sec in RAW (at least on my 60D)
In my case I just plan to use for a small shoots of only some seconds.
I agree with Joachim Buambeki to have a finer granularity for the interval for over one second intervals (like 1.5 or 2.5 sec)

I hope you can help us, I already tried before but unfortunately it's over my knowledge.
Thank you in advance.

Thank you mk11174.

A huge step ahead.
Now I can compile it without error.
The only remaining problem is that when try to run the .exe file on Win7 64bit I receive the error:

The version of this file is not compatible with the version of Windows you're running
....

Thank you mk11174.

I've tried but I continue receiving this error:

root@magiclantern-VirtualBox:~/mylantern/modules/dual_iso# make cr2hdr.exe
make: *** No rule to make target `hgstamp', needed by `module_strings.h'.  Stop.

No one can help me ? please 

I also have compile problem for cr2hdr on the virtual machine.
Followed Audionut suggestion:

-Installed only "Development environment targetting 32- and 64-bit Windows"

copied the folders:
include
lib
libsrc

from /usr/i686-w64-mingw32 to match HOSTCC:
~/mingw-w32/bin/i686-w64-mingw32-gcc

- I have run "make cr2hdr.exe" an I received this error:

root@magiclantern-VirtualBox:~/mylantern/modules/dual_iso# make cr2hdr.exe
make: *** No rule to make target `hgstamp', needed by `module_strings.h'.  Stop.

Help

Hello Greg,

Have you made progress about this idea? It seems very promising, maybe why not try to port it to a module?

Hello Dunc101,

I have requested the same some times ago here:

http://www.magiclantern.fm/forum/index.php?topic=6724.msg54793#msg54793

As you can see in the old thread I tried some very basic changes but it seems a little too complicated for my none code skill abilities.
Maybe now a good soul can help us for moving intervalometer from second to millisecond word
From what I understood from A1lex response it not seems very hard
Anyone offering help?

P.S. Using raw_rec with FPS override isn't the same, you can't save full res photos

Excellent work Greg.
When a pull request?
I can't wait to test it on my 60D

Great simple (I hope) idea.

Better than the Transcend cards there are the PQI Air cards.
Same "hackability" (it seem that Flucard, Transcend and PQI share the same or very similar Linux-Busuybox inside.
Similar but the big difference is that PQI Aircard works like a microSD to SD converter.
You can put any microSDHC inside (up to 32Gb)
In theory it doesn't affect the microSD original speed.
So you can reach at least the class-10 speed, hopefully more (UHS-I card)


I was already thinking about some sort of PTP implementation to have a sort of "console", maybe in future when it will return to works also launch scripts.
I think your idea is good...go ahead
I can already test it on Flucard and PQI.

Perfect , This time  I hope this time I understood correctly
With an implementation of post-deflicker in the converter (without add any values other than frame exposed data used) we can obtain the SAME results of the post-deflicker correction value calculated on-camera in case of intervalometer still photo, right?

Ok, last thing.
For the median of green channel you mean the measured green channel value and not the green channel value of the taken photo, right?
So for an implementation of post deflicker in the converter you need to have (other than the frame exposed data used (aperture, iso and shutter value)) also the measured green channel value that normally you don't have, neither in exif of CR2's files right?

Thank you.

Thank you,

I was think that ML compute the XMP exposure number with the difference between the exposure calculated and the exposure that camera apply.
So what raw data use ML to calculate XMP?
Can you calculate it in post without any additional data other than the standard exif?

For sunset (especially for the last part) I use often RAW videos because I need to use values under 1 second not available in intervalometer like 2-5fps
but I really miss a lot the deflicker possibility.
It's very important to achieve a good results because the luminosity change a lot in small time.

Maybe is possible to write the raw exposure data and compute it after in the converter?
So we can lighten the CPU.
After all If I understood correctly the frame exposure data used (aperture, iso and shutter value) are already present in 2.0 format.


Thank you much.

It's possible to add the delta of exposure value (the value in XMP line crs:Exposure2012=) to 2.0 specs?
So that the converter can recreate other than DNG files also xmp file and you can obtain a perfect deflickered files.

I am often in similar situation of this: http://www.magiclantern.fm/forum/index.php?topic=7739.0 or with some little-than-normal-speed timelapse with sunset for example

but sorry I can't offer 100$ 

Great idea.
I think it can be similar to some of the last Sigma lens that you can customize after connect it to a Usb docking station.
You can program it choosing between various modes and if I remember correctly also limit the focus range to achieve faster focusing.