Tragic Lantern for EOS M

Started by coutts, April 17, 2013, 01:43:28 AM

Previous topic - Next topic

0 Members and 3 Guests are viewing this topic.

1%

I think if you take some CR2 there is a temp in there, the scale from photos has to match, maybe it doesn't. Temp was always ridiculous on EoSm. There should be a warning like a temp icon from canon on the screen if its really overheating.

stephen_west_usa

Thanks 1%, ya it is the EOS-M I have. No sweat then.

jerrykil


lonelyspeck

Hey guys,

I've been following this thread since the beginning and I've been using the Tragic Lantern nightlies on http://tl.bot-fly.com/
As of this post, I'm using the Nov 07 Build. My interest in ML for the EOSM is almost exclusively for enabling time lapse creation. In particular, I'm interested in using the EOSM for day to night time lapse using the the "Flicker Free ETTR Timelapse Workflow" here: (http://www.magiclantern.fm/forum/index.php?topic=5705.0). It's not written for the EOSM but in theory it should work the same.

Auto ETTR works OK for the most part on the EOSM but it hunts for the proper exposure a lot. Tweaking the minimum shutter speed or SNR limits will usually allow you to get it to hit the right exposure but it's usually by trial and error. It's also much slower to converge than Auto ETTR on my 6D (1%'s Oct 14 1.1.3 Build) Once the exposure converges, ETTR on the EOSM seems to do what it is supposed to do for non time lapse shooting (e.g. pressing the shutter button manually with your finger).

The Problem: The bigger issue comes up when I try to use Auto ETTR in combination with the ML intervalometer (Tested with 10-30 second intervals). Once the intervalometer is enabled, Auto ETTR no longer functions. The exposure will remain the same (at whatever it started with) throughout the time lapse sequence, regardless of any changes in light. For example, if Auto ETTR picks ISO 100, 1/125 @ f/16 for the first exposure in bright sunlight, it will remain at that exposure throughout sunset and into night. I've also tried testing this using a variable ND filter to simulate the ambient light change.

I have tested this problem extensively and on various builds and the behavior is always the same when the intervalometer is enabled. I've also tried the other Auto ETTR settings other than Always On such as Auto Snap and even Half S DblClck and manually double pressing the shutter half-way between intervals to try to get it to start ETTRing but it doesn't do anything; it's as if Auto ETTR is disabled.

Any thoughts?

If Auto ETTR worked with the intervalometer, the EOSM would be the ultimate compact timelapse machine.

1%

Quoteprobably a mac related thing...

Its funny because I almost get the exact same error on windows using fseeko.. I think there is another one, iseek or something like that, will have to try it.

Ok so I have a few to choose from:
fseeko - didn't work on windows
fseeko64 -works on windows, linux but not mac?
_fseeki64 - works on windows, didn't try on linux yet.
lseek64 - worrks for windows, no clue on others

Think I fixed raw_rec or more precisely raw2dng.exe... still have to deal with MLV_Dump

jerrykil

heya 1%,

i had problems with preprocessing script. could you change it to
    #if ($OS == Windows_NT)
    #define fseeki _fseeki64
    #else
    #define fseeki fseeki
     #endif

that seems to compile, but i haven't tested it out on the EOSM yet..

1%

Is it compiling with the latest commits? And does fseeki work with large files on linux/etc?

jerrykil

linux: sorry, your highness, i don't have a VM set up to compile ATM. i'm sure someone else could confirm this quicker

../lv_rec/raw2dng.c:66:103: warning: format specifies type 'int' but the argument has type 'unsigned long' [-Wformat]
    if (sizeof(lv_rec_file_footer_t) != 192) FAIL("sizeof(lv_rec_file_footer_t) = %d, should be 192", sizeof(lv_rec_file_footer_t));
                                                                                  ~~                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                                                                  %lu
../lv_rec/raw2dng.c:38:77: note: expanded from macro 'FAIL'
#define FAIL(fmt,...) { fprintf(stderr, "Error: "); fprintf(stderr, fmt, ## __VA_ARGS__); fprintf(stderr, "\n"); exit(1); }
                                                                            ^
../lv_rec/raw2dng.c:68:5: warning: implicit declaration of function '_fseeki64' is invalid in C99 [-Wimplicit-function-declaration]
    _fseeki64(fi, -192, SEEK_END);
    ^
2 warnings generated.
[ GCC      ]   raw2dng
Undefined symbols for architecture i386:
  "__fseeki64", referenced from:
      _main in raw2dng.o
ld: symbol(s) not found for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [raw2dng] Error 1

i'm still getting that. i think its not comprehending the preprocessing like you think it would. maybe llvm problem?

1%

Yea, thats weird because it should be taking fseeko instead when the OS isn't winnt

Try now, then mlv_dump will be easy to fix if this works.

jerrykil

latest one works! thx 1%

i have some bad news. apart from the nightly site being moved to amsterdam and facing some downtime, just yesterday the GPU temperature sensor on my mac died. being out on the island, i can't get it fixed. it works for the time being, but i'm not sure how long it'll last. i get home on dec 17th, so i'll get the site back up then if my laptop doesn't survive :P i'm sure it will...or will it?

i had the shutterbug twice today, but it seems to be less frequent lately

1%

If its just the sensor you can either underclock or run the fan at full speed... if the fan died then bigger problems :(


jerrykil

i'll PM ya, its really strange...never had something like this happen

maxotics

Quote from: 1% on November 10, 2013, 11:42:00 PM
If its just the sensor you can either underclock or run the fan at full speed... if the fan died then bigger problems :(

1%, you have cameras on the brain.  I think you meant CPU, not sensor ;)

1%

Yea,  the sensor is the failure part tho, if the GPU failed there would be no video. I've reflowed tons of boards with failed GPU, usually it comes back. Not once has a temp sensor failed.

feureau

Quote from: 1% on November 11, 2013, 01:30:44 AM
Yea,  the sensor is the failure part tho, if the GPU failed there would be no video. I've reflowed tons of boards with failed GPU, usually it comes back. Not once has a temp sensor failed.

Do you mean with the putting the logic board in the oven method? I have an MBP with a dead logic board that I've been thinking to reflow.

maxotics

1%, he wrote " just yesterday the GPU temperature sensor on my mac died"  :) :) :)  I'm thinking he meant mac as in Macbook Pro.  EDIT: Oh, now I'm the dummy!!!! You meant the temperature sensor!  I hope... ;)

1%

QuoteDo you mean with the putting the logic board in the oven method? I have an MBP with a dead logic board that I've been thinking to reflow.

I've thought about trying that (maybe temp controlled toaster oven) or getting an IR station.... but right now I have the SMD rework hot air gun so I go with that. Also makes it easier to take mosfets and multi pinned chips off.

feureau

Quote from: 1% on November 11, 2013, 01:52:00 AM
I've thought about trying that (maybe temp controlled toaster oven) or getting an IR station.... but right now I have the SMD rework hot air gun so I go with that. Also makes it easier to take mosfets and multi pinned chips off.

>SMD rework hot air gun

This guy: http://www.ebay.com/itm/SMD-Rework-Soldering-LCD-Digital-Station-Hot-Air-Gun-Solder-Iron-Welder-11-Tips-/370586123326 ?

That looks neat. So, you just blast hot hair all over the board? How long? Do you see the silvery thingy melt a bit? Do you know how hot it goes/the temperature you're melting the board at?

1%

Yea, similar to that. I go for a certain amount of time over the chip... ie 360C for 15 minutes, its usually enough to melt the balls a bit and get the video/xbox/etc back.

AnotherDave

When I attempt to get the latest version, it says "This Build Failed!".  What's up with that?

1%

Any messages, the 7D came out.

jerrykil

Quote from: AnotherDave on November 11, 2013, 07:24:13 PM
When I attempt to get the latest version, it says "This Build Failed!".  What's up with that?
which build is that?

maxotics, yeah its the temp sensor on the GPU. i no longer get a read from it. dynamic switching seems to be working but all things video as significanlty slower. 1%, i've taken your advice and i'm trying to disable the "discrete" ie high power ATI chipset. lets see if this is better running solely off of the intel 3000 HD onboard chipset. wish me luck! if this doesn't work i'm gunna try winows 8.1...or should i try 7? i want to be able to turn off gpu acceleration all together, so maybe i want windows XP (dread)

sudo mv /System/Library/Extensions/ATI* ~/DisabledKEXT/

makes no difference :( WTF?!

AnotherDave


maxotics

What is the most stable build for RAW shooting (assuming there is no shutter bug, or it wouldn't be noticed by anyone shooting only video)?

Users, please post any bugs you experience, or features you believe necessary for a stable VIDEO build.

1%, your thoughts?  For example, what features are on your to-do list?  I can add a page to the shooter's build that has your "release" notes, so to speak.  I'll maintain it for you, if you like.

I will be releasing a window PDR console app soon.  I'd like to update my download files from maxotics.  Does this make sense to everyone?

jerrykil

Quote from: AnotherDave on November 11, 2013, 08:43:35 PM
Built on: 2013-10-18 13:53:06 -0400

try a newer build: http://tl.bot-fly.com
site moves on Nov 19th so there is going to be about a week of downtime there. i'll have to use dropbox or something gross