Windows installer

[dmitrys]

CHIMP - Canon Hack Installation and Management Platform.

[dmitrys]

Magic Lantern support added.

[nikfreak]

gave it a quick try with the sdcard of 100D.
First it didn't find any images, although CR2 files were present. Then I shot a JPG and got:

Code: [Select]

No value exists for tag firmware revision
Probably your software does only support "unified" models and 100D/70D are left out. How about adding an option to manually provide a "zip" package and therefore skip autodetection?

[dmitrys]

Thank you for your reply.

gave it a quick try with the sdcard of 100D.

The version you're looking at is still very much a "CHDK Utility"; the one with the ML support isn't public yet (both since I haven't gotten any replies and since it's pretty much a hack at this point).

Sorry about the misunderstanding.

First it didn't find any images, although CR2 files were present.

The only raw files I've seen so far were CHDK CRWs, which proved useless for camera detection. May I have a look at one of your CR2s please?

Then I shot a JPG and got:

Code: [Select]

No value exists for tag firmware revision

I'm assuming you got a fatal exception.

That's because the version you checked out relies on the Firmware Revision (10H) being present. Since EOS cameras seem to omit it, newer versions will also check for Canon Firmware Version (07H); see https://github.com/CHDKUtil/Net.Chdk.Detectors.Camera/blob/master/src/Net.Chdk.Detectors.Camera/FileCameraDetector.cs

Probably your software does only support "unified" models and 100D/70D are left out.

If by "unified" you mean those listed under Magic Lantern's Main Builds, you are correct.

How about adding an option to manually provide a "zip" package and therefore skip autodetection?

Installing from a local ZIP is a planned feature, although I believe it should still be preceded by the Detect Camera step so the installed package could be matched against the detected model/firmware.

[dmitrys]

Added verbose Version, Changeset and Created by.

Magic Lantern update scenario:















Edit 2017-05-29: Updated Detect Software screenshot.
Edit 2017-06-01: Updated Summary screenshot.

[dmitrys]

Added initial modules support; see updated first screenshot in the previous post.

[dmitrys]

The utility has been rebranded as CHIMP and updated with Magic Lantern support.

[eduperez]

Do you have any intentions to support 400plus, too? Card preparation and software installation is quite similar to ML, and the (three, at most) people who still own a 400D but have not installed 400plus will be very grateful...

[dmitrys]

Do you have any intentions to support 400plus, too?

Thank you for your interest.

I have looked into 400plus, and found the following issues/concerns that seem to be in the way:

• No uninstaller:
  

  The first step of the installation procedure cannot be undone (at least for now), and the camera will always try to execute 400plus if it is in the CF card

  
  I can see why this hasn't been a priority so far. However, now that a user may get the hack running on their camera in a couple of mouse clicks (without reading any of the warnings, of course), I believe the change has to be reversible.
• Package structure:
  
  • 400plus-testfir-1.bin.zip contains testfir.fir under 400plus-testfir-1\bin, which must be copied to A\, while
  • 400plus-20160404-07.bin.zip (version-dependent) contains
    • AUTOEXEC.BIN under 400plus-20160404-07\bin (version-dependent), which must also be copied to A\, and
    • languages.ini under 400plus-20160404-07\bin (version-dependent), which must be copied to A\400PLUS.
  
  I can deal with multiple downloads and even with non-root source directories (thanks to SDM), but could you at least place languages.ini under 400PLUS please?
• Missing license.
  I believe at least some portion of the code was taken from Magic Lantern, so it has to be GPLv2 or later (not recommended). However, I'm not sure about the copyright notice.
• Difficult detection.
  CHIMP uses string matching to gather detailed version data from CHDK, ML and (most of) SDM binaries. The latest 400plus AUTOEXEC.BIN contains little more than a standalone

  VER-20160404-07

  
  Please consider adding metadata in future releases.

Thanks!

[eduperez]

So far, the major roadblock for most users who find trouble installing 400plus seems to be the process of preparing the card (which is similar to the process of preparing a card for CHDK or ML, by the way); if we could have just a tool capable of preparing the cards, we would have won an important battle.

Thank you for your interest.

Thank you, too!

No uninstaller:
I can see why this hasn't been a priority so far. However, now that a user may get the hack running on their camera in a couple of mouse clicks (without reading any of the warnings, of course), I believe the change has to be reversible.

Enabling a camera to use 400plus is the same as enabling a camera to use ML; and as far as I know, it is also a permanent change on ML, too (see http://wiki.magiclantern.fm/faq#does_ml_do_any_persistent_changes_to_my_camera). We know how to revert that change, but it is considered a dangerous procedure.

Package structure:

• 400plus-testfir-1.bin.zip contains testfir.fir under 400plus-testfir-1\bin, which must be copied to A\, while
• 400plus-20160404-07.bin.zip (version-dependent) contains
  • AUTOEXEC.BIN under 400plus-20160404-07\bin (version-dependent), which must also be copied to A\, and
  • languages.ini under 400plus-20160404-07\bin (version-dependent), which must be copied to A\400PLUS.

I can deal with multiple downloads and even with non-root source directories (thanks to SDM), but could you at least place languages.ini under 400PLUS please?[/li][/list]

Yes, I think we can do that; we could also maintain an "auto-installer" ZIP file with the latest version, and a structure carved to the needs of your software.

Missing license.
I believe at least some portion of the code was taken from Magic Lantern, so it has to be GPLv2 or later (not recommended). However, I'm not sure about the copyright notice.

Yes, there is code grabbed from ML in 400plus (and there is code in ML grabbed from 400plus!). Code is licensed as GPL v2, but I am surprised to realize that I cannot find any mention to license of copyright in the site... will have a look at that issue later and fix it.

Difficult detection.
CHIMP uses string matching to gather detailed version data from CHDK, ML and (most of) SDM binaries. The latest 400plus AUTOEXEC.BIN contains little more than a standalone
Please consider adding metadata in future releases.

Looks reasonable, too.

[dmitrys]

if we could have just a tool capable of preparing the cards, we would have won an important battle.

Regardless of 400plus support, the next version should allow you to prepare a card once AUTOEXEC.BIN is in its root directory.

Enabling a camera to use 400plus is the same as enabling a camera to use ML; and as far as I know, it is also a permanent change on ML, too

According to http://wiki.magiclantern.fm/install:

Uninstalling ML from the camera

• With a Magic Lantern card, launch the Firmware Update process and follow the instructions on-screen.
• Re-installing Canon firmware will not remove Magic Lantern.

In the meantime, the upcoming version should be able to do the following (assuming 400plus only works with Firmware Version 1.1.1):

[DeafEyeJedi]

Even though I'm not a Windows user but this is really nice work done by @dmitrys -- Thanks for sharing!

[reddeercity]

A question , why do we need a installer for windows ?
I can't see the benefits of this ( I'm a PC & MAC User) or maybe I missed something .
making the card bootable & installing ML is simple & easy already , explain please .

[dmitrys]

0.9.1 - 2017-06-05

• Added exFAT support
• Added CRW and CR2 support
• Added 400plus binary detection
• Added ML module binary detection
• Various bugfixes and code improvements

[eduperez]

0.9.1 - 2017-06-05

• Added exFAT support
• Added CRW and CR2 support
• Added 400plus binary detection
• Added ML module binary detection
• Various bugfixes and code improvements

Thank you very much!

[dmitrys]

Thank you very much!

You're welcome.

I'm almost done implementing a software metadata generator for CHDK, which should be trivial to adapt.

As for package structure, I believe the simplest solution would be to keep the separate packages. If you could put the .BIN and .FIR in root and LANGUAGES.INI under 400PLUS, that would be perfect.

Edit 2017-06-07: Patch submitted to CHDK.

[dmitrys]

0.9.2 - 2017-06-19

• Fixed multi-partition card handling
• Fixed crash on empty drives
• Added CHDK compiler detection
• Increased small partition size to 2MB on dual-partition cards (matches CHDK implementation)
• Updated modules metadata format

[dmitrys]

@eduperez Any progress?

[dmitrys]

0.9.3 - 2017-06-22

• Improved multi-partition card handling
• Improved CHDK module handling
• Added support for DIGIC VI cameras: G7 X, SX60HS, SX280HS, SX275HS and SX270HS
• Added Russian translation
• Downgraded support for SDM
• Various bugfixes and code improvements

[eduperez]

@eduperez Any progress?

I will be away from my main computer for a week or two, so there is not much I can do right now; will get on this as soon as I am back.

[dmitrys]

0.9.4 - 2017-07-05

• Restored full SDM support
• Added SDM precise binary detection
• Added SDM tips and User Manual option
• Added CHDK camera-specific notes option
• Added 400plus version formatting
• Added SDHC/SDXC/microSD card check
• Fixed SDM IXUS/SD/ELPH model names
• Fixed Summary product name/version display
• Various bugfixes and code improvements

[eduperez]

I have added a license file to 400plus' repository, and prepared a test distribution file; could you please check if the attached file meets your needs? Thanks!

[dmitrys]

I have added a license file to 400plus' repository

I can't seem to find it.

could you please check if the attached file meets your needs? Thanks!

• SOFTWARE.JSN has the following errors:
  
  
  • product
    
    • version - string, product version (2-4 integers separated by periods) - should be 2016.4.4.7
  • camera
    
    • revision - string, firmware revision (e.g. 101a) - should be 111
  • build
    
    • creator - string, build creator (e.g. jenkins@nightly) - should be null
  • source
    
    • channel - string, distribution type (release or trunk for CHDK, empty string for others) - should be empty string
  • encoding
    
    • data - string, hexadecimal encoding key (lowercase, N/A if name is empty) - should be null
  
  Did you manually create the file? How about gen_meta?
• The directory structure is off. Could you put AUTOEXEC.BIN, 400PLUS and _HDKMETA under root (or at least under the same directory with a version-independent name)?

Thanks!

Edit: Added revision.

[dmitrys]

0.9.5 - 2017-07-30

* [ALL] Migrated to .NET Framework 4.6
* [ALL] Published full source
* [ALL] Added French translation (merci à Michel2e)
* [ALL] Added mutli-partition support check
* [CHDK] Added ALT button summary tip
* [CHDK] Added EOS M3 120f support
* [ALL] Various bugfixes and code improvements

Downloadable directly from Releases.

[eduperez]

I can't seem to find it.

Neither do I... promise I was convinced I had uploaded it... It is there now, I hope it does not vanishes again.

product

• version - string, product version (2-4 integers separated by periods) - should be 2016.4.4.7

Changed to 20160404.07, is that ok?

camera

• revision - string, firmware revision (e.g. 101a) - should be 111

Fixed.

build

• creator - string, build creator (e.g. jenkins@nightly) - should be null

Fixed.

source

• channel - string, distribution type (release or trunk for CHDK, empty string for others) - should be empty string

Fixed.

encoding

• data - string, hexadecimal encoding key (lowercase, N/A if name is empty) - should be null

Fixed.

The directory structure is off. Could you put AUTOEXEC.BIN, 400PLUS and _HDKMETA under root (or at least under the same directory with a version-independent name)?

I'm trying to follow the tradition of using "product_name-product_version.zip" for the file and "product_name-product_version" for the root folder, without mixing source code and binaries (that are distributed in different files); I have simplified a bit the scheme. Could you please review the attached file? Many thanks!