Messages

I've ported some of the 5D4 stubs from 1.0.4 to 1.1.2 but I won't have a chance to look at it further for another week or so. If anyone wants to carry on in the meantime my changes are here:

https://bitbucket.org/chris_miller/ml-fork/commits/fcae3481c3610d6920652dd84cc5e5d00ed48d98

So... it looks like we need to update all our stubs to 1.1.2 - who's going to help? I've started by updating the emulation - it goes as far as the 80D, including file I/O on the virtual SD card.

I've started on this but my time is quite limited over the next week so it may take me a little while to get it done.

There's something of a suggestion here that the cr3 compression might be lossy: https://www.dpreview.com/articles/0483301097/quick-look-canons-new-compressed-raw-format

It looks like Visual Studio now has support for building using MinGW-64 and Cygwin:

https://blogs.msdn.microsoft.com/vcblog/2017/07/19/using-mingw-and-cygwin-with-visual-cpp-and-open-folder/

It might be worth looking at IntelliJ IDEA Community edition (https://www.jetbrains.com/idea/download/) combined with the Lua plugin (https://plugins.jetbrains.com/plugin/5055-lua - don't download this, just install it through IDEA by choosing File->Settings->Plugins->Browse Repositories and search for "Lua"). Note that I haven't tried the Lua plugin myself (and given it is written by the 3rd party, it's quality is uncertain), but it does appear to have some debugging support and a host of other useful features. IDEA itself is superb for the other languages I use (Java, Kotlin, Python) and I can't imagine using any other IDE for those. I also dabble in a bit of C/C++ for Arduino using CLion which is a C++ IDE based on the same codebase as IDEA, so the Lua plugin should work with CLion too.

If anyone does try the above, I'd be interested to hear how it goes.

do you know if will it be visible in italy please?

https://www.timeanddate.com/eclipse/solar/2017-august-21

I took a look at the 1.0.4 firmware and managed to find a few stubs. Not much, but it's a start.

https://bitbucket.org/chris_miller/ml-fork/commits/035db3446e9092bc5b3be89af9d4b378690ad7cc

What happens if you use %%f instead of just %f? This is just a guess and I don't know Lua, but based on your output it seems like there's an escape issue of some sort.

It sounds like a physical issue of some sort - have you checked to see if there is some dirt/obstruction (or possibly some damage) in the memory card slot?

That's the nature of dual-ISO, you need to lift the shadows in post to obtain your end result. Normally lifting shadows this deep results in a lot of noise, but a dual-ISO image has increased dynamic range and hence the shadows are much cleaner. Here's what I get with after dragging a couple of sliders in Lightroom for your image - note the relatively clean shadows combined with retention of highlight detail:

Thanks Chris -- I could use some help on figuring out how to find those register values. In the meantime it looks like your 1.3.3 code might just work for 1.3.4.

Those dual ISO addresses were obtained by looking at cmos[0] from the adtg_gui module (enabled via CONFIG_GDB=y, http://www.magiclantern.fm/forum/index.php?topic=6751.msg71720#msg71720). So eg for FRAME_CMOS_ISO_START, make sure you're in movie mode ISO 100 and check the cmos[0] value. Similarly for PHOTO_CMOS_ISO_START but make sure you're in photo mode liveview instead.

Are there any other specific addresses you're stuck on? I'm not sure I can help much as my knowledge is limited, but will do my best. I'm also not sure when I'll get a chance to switch to 1.3.4 to try your build, though by the sounds of it you're about at the point where I got stuck with 1.3.3 (flickering menus - I don't know how to solve that one unfortunately).

I'll also check into the dual_iso.

This might be a good place to start looking: https://bitbucket.org/chris_miller/magic-lantern/commits/33bd0eb41eee1bf51c0e51c14082f330e3db1679?at=unified

This looks promising! Does my old repo containing a 1.3.3 port help with this at all? Last I tried it, the port was running OK though it needed more extensive testing, and there were some flickering menus that I didn't know how to solve:

https://bitbucket.org/chris_miller/magic-lantern/branch/5D3-133
https://bitbucket.org/hudson/magic-lantern/pull-requests/605/support-for-5d3-firmware-133/diff

Relevant article: https://www.wired.com/2016/12/200-filmmakers-ask-nikon-canon-sell-encrypted-cameras/

Edit: Hacker News discussion here: https://news.ycombinator.com/item?id=13175810

I started work on a 1.3.3 port some time ago. It works, but there are some bugs (eg flickering menus) and it hasn't been thoroughly tested. I made a pull request here:

https://bitbucket.org/hudson/magic-lantern/pull-requests/605/support-for-5d3-firmware-133/diff

Unfortunately I also managed to break the link between the pull request and my repo (sorry all!), but the original code can still be found here:

https://bitbucket.org/chris_miller/magic-lantern/branch/5D3-133

There hasn't been any activity on this for a long time now, partly because I am short of time and skills to take the port much further, partly because I regularly need my camera in the real world and constantly changing firmware versions for testing gets in the way of that, also because 1.3.3 isn't that different to 1.2.3 so there hasn't been much incentive for anyone to finish getting it stable and merged in to its own branch. Ideally I'd like to see the 5D3-113-and-123 branch merged in to unified as a default (so we get regular nightlies for 123), then the 133 support added to that (with the eventual goal of it superceding the 123 support) but there's still quite a lot of work required for that to happen.

If you're able to build, test and provide detailed feedback the 1.3.3 code, it would be a very good step in the right direction.

Understood and quite appreciated, but why is there no 5D3-133 branch on bitbucket?

I'm new to magic lantern, but I'd like to contribute if I can.

The link for 1.1.6 gives a 404: http://pel.hu/down/eos6d-v116-win.zip

Sorry? http://pel.hu/eoscard/

It's hard to imagine this is anything other than a hardware failure of some sort I'm afraid. Your best bet is to take it in to Canon for repair (you'd probably want to uninstall ML first, just in case they take issue with it for whatever reason).

ML doesn't come with any warranty or support, so using it for professional purposes is entirely at your own risk. There are many people using it very successfully for paid work, but there have been others who have hit problems with eg corrupted RAW video due to bugs in ML, or have run in to trouble because they didn't fully understand the behaviour of some of the settings. My advice is to try it for yourself, get thoroughly familiar with the relevant features and wait until you're comfortable with how ML fits in to your workflow before considering using it commercially.

• It will work fine to have ML on the SD card while recording photos and/or video to CF, in fact I personally think that's the best setup for the 5D3 (i.e. have a small SD card purely for ML and save all images/video to the much faster CF card).
  
• You still have all the Canon menus and functionality available as normal.
• Should be fine, but you probably need to try for yourself. I barely use video or focus peaking myself but haven't seen any problems with it personally.

Interesting article talking about the use of dual pixel RAW for AF Microadjustment finetuning in an upcoming version of FoCal:

https://www.reikan.co.uk/focalweb/index.php/2016/09/bringing-dual-pixel-raw-to-reikan-focal/

As far as increasing the bit depth of the gamma curves, increasing the file length shouldn't be an issue (esp once chris adds that to the decoder, for now you can do it by hand)

I added support for that yesterday. Just redownload the jar and it should then update the data length entry seamlessly during the encoding step, same as it does for the checksum. I didn't test it very thoroughly though so any problems with it, let me know!

For hex editing on Windows I can recommend HxD (https://mh-nexus.de/en/hxd/).

You can not change the names of those folders

Don't try things like this. Anything that potentially writes to the card is only going to make your life worse.

- To make an Image of the SD card... it does not work.

How did you try to make the image? A tool like Linux dd would hopefully succeed at this, at which point you can try recovering data from the image rather than the card itself.

- To deinstal and instal again ML, still nothing.

(De)install ML on the SD card itself? This is a very bad idea (same as point one - writes to the card will likely cause further damage).

So, does anyone have an idea what could save the files on the card?

PhotoRec (http://www.cgsecurity.org/wiki/PhotoRec) is your best bet, and possibly TestDisk (http://www.cgsecurity.org/wiki/TestDisk). Failing that, you probably need to take it to a specialist data recovery company.

Thank you! I'm on my phone so I haven't checked it out yet, but does it also modify the file length value at the beginning of the file?

It doesn't yet, but I'll add that later today.

Edit: I've now updated Pf3Decoder.jar so it updates the header with the correct data length when re-encoding files.

I've updated the Pf3Decoder app so it now automatically corrects the checksum when processing a pf2/pf3 file with the ".decoded" extension. This means you should be able to decode a pf2/pf3 file, make any changes you wish with a hex editor, then re-encode it without worrying about the checksum being invalidated.

https://www.dropbox.com/s/4x8x9epalybm6aw/Pf3Decoder.jar?dl=0

This hasn't had very thorough testing so please let me know if you hit any problems.

Hey, @chmee, I'm trying to translate your php script into python, but I seem to have a bug somewhere as the file output doesn't match chris_overseas's java script. Would you be able to take a look and tell me if I'm doing the byteArray wrong or something?

If I can get it to work I can probably whip up a better OSX app for decoding/encoding, then we'll have a good start later on for quick and easy LUT->Picture Style conversion.

http://pastebin.com/ft2LkvYB

Take a look at my Java source (rename Pf3Decoder.jar to Pf3Decoder.zip and have a look at Pf3Decoder.java within), it should be very easy to port to any other language of your choice. Note that it uses two key arrays (one 512 bytes, one 513 bytes) so you don't need the full 260KB array.