Messages

Works fine on 5D3. Can't help with 50D since we don't have one.

A video showing the problem may help.

I've added a 2x magnification option for the input signal, should be easier to see now, especially with flat picture styles.

The bitmaps and all those sizes are overkill IMO. The native size is 256 pixels, because that's the range of the U-V signal; doubling the entire thing will make it bigger than the screen. And making it smaller... it's already small enough.

When the screen is mirrored, ML text is mirrored too, right?

There's not much you can do here, maybe just disable the info when the screen is mirrored.

There is a degree indicator, look at the sign.

Technically possible, but it's something that should be supported by both the remote app and ML.

For this case, try metering for highlights (the 90th percentile should do the trick).

Make sure you use the nightly, it should flicker less. You can also try the LRT method if you use LRTimelapse.

I'd say you should implement the firmware checksum to avoid bricking the cameras in situations like this

Seems to work, shutter speed can be adjusted in 20-microsecond steps. Please check the math:

https://bitbucket.org/hudson/magic-lantern/commits/8750db7afe91

(the same feature can be used for very fast shutter speeds, if you fine-tune from 1/4000).

Compiling the current source code will give you that version to get started. The menu works, but other than that I have no idea what else works.

Maybe jplxpto can publish the devkit (the FIR for enabling the bootflag and dumping the firmware)?

Well... since the modules don't support any camera-specific code, and the button codes are camera-specific, this won't work.

With PicoC I've tried to implement a platform-independent key handler (will work as long as you use the constants and not the raw numbers).

At this point, anyone with a 40D and some C skills can grab the source code and improve it. So... what are you waiting for?

Technically possible only for 60D, 5D3, maybe also 600D and digic V cameras (via FRAME_SHUTTER_OVERRIDE). Maybe integrate it with the extreme shutter speed menu? (it uses the same mechanism).

For other cameras, FPS override is the only hope.

I've found it very sensitive to timing - issuing focus commands too early can lockup the camera or give focus errors.

No, it's camera-specific.

They are not working in 5D3, it has a gazillion of AF points, so the old code won't work.

Nobody touched the 5Dc port since months.

They are not related, see http://en.wikipedia.org/wiki/Aliasing

Canon engineers have the source code and docs; we don't.

To get rid of that warning, put some dummy prop handlers in property.c at the bottom.

ML already dumps the healthy ROM (executable code, properties etc) in ROM0.BIN and ROM1.BIN (the same files that you use for QEMU), but we didn't try to restore the data from these files yet. G3gg0 knows how to call the reflash routines, but we didn't try.

When changing some property for which you are not sure about the value, you can use the C mode - in this mode, Canon settings are not saved, so it's less likely to cause permanent damage.

Before changing things, I first check the values used by Canon firmware and try not to go too far from there. It's just guesswork, there's no known method that it's 100% safe (that's why I put this kind of test code under Don't click me). In many cases, Canon firmware will do some sanity checks, but not always.

See also http://www.reikan.co.uk/photography/blog/?p=1550 - using Canon SDK is just as (un)safe.

The prop handlers are just hooks, you can define them wherever you need them (they should be unique in a single source file though). Maybe the restriction of uniqueness can be removed?

Small reminder: in reboot.c it should compute a checksum of Canon firmware and refuse to boot with the wrong firmware version. This is a safeguard, so people don't screw up their cameras when Canon releases a new update.

No, it will just refuse to boot.

You can try to set PROP_PIC_QUALITY back to some valid value, e.g. from debug_init_stuff (it's already commented out).

If not, you can disable the assert handler (boot-hack:c, in my_assert_handler, return 0 instead of old_assert_handler). Once you do that, you should be able to get in the menu and clear the settings. Don't forget the assert handler disabled, as it will cause errors to be silently ignored - which can be dangerous.

I've added some backend support to detect what settings were changed (compared to ML defaults). Maybe it helps here too.