CHIMP - Canon Hack Installation and Management Platform - page 3 - General Discussion and Assistance - CHDK Forum
supplierdeeply
« previous next »
Pages: 1 2 [3] 4 5 6 7 8 ... 14   Go Down

CHIMP - Canon Hack Installation and Management Platform

  • 136 Replies
  • 64673 Views
*

Offline dmitrys

  • ****
  • 267
Re: CHDK for non-hackers
« Reply #20 on: 17 / April / 2017, 16:50:34 »
Advertisements
P.S. I just noticed date/time and compiler are shown in Build Info. I suppose those could be added as well.

Edit 2017-04-18: Added.
« Last Edit: 18 / April / 2017, 06:23:55 by dmitrys »
Logged
Author of CHIMP, Canon Hack Installation and Management Platform
*

Offline waterwingz

  • ******
  • 12132
    • Waterwingz
Re: CHDK for non-hackers
« Reply #21 on: 17 / April / 2017, 18:11:33 »
Quote from: dmitrys on 17 / April / 2017, 12:21:17
Seriously, have you seen the size of this page? ;)
I have.  Take a look at the edit history.  :)

FWIW, most of that page was written up prior to the release of STICK.   At that time, there was no single source of correct information about ways to install CHDK and all the permutations.   But there were a lot of incomplete or incorrect explanations.

As your utility will apparently only work for Windows users, much of that page will still be relevant.  But I'm looking forward to what you release - STICK probably reduced the number of forum postings from people having installation problems by 95%.  Now we mostly see people having java or permission problems with STICK.  If you can eliminate those for Windows users that will be great!
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline dmitrys

  • ****
  • 267
Re: CHDK for non-hackers
« Reply #22 on: 18 / April / 2017, 05:44:50 »
Since forum posts are a pain to update (and keep track of), I created a GitHub repo and moved bits over there, namely:
Newer screenshots will also be posted over there.

Free free to continue the discussion here (perhaps the proposal belongs in a separate thread?).
Logged
Author of CHIMP, Canon Hack Installation and Management Platform
*

Offline reyalp

  • ******
  • 13880
Re: CHDK for non-hackers
« Reply #23 on: 18 / April / 2017, 17:43:54 »
Quote from: dmitrys link=topic=13091.msg132390#msg132390 [url=https://github.com/CHDKUtil/ChdkUtility/wiki/Software-metadata-proposal
Software metadata proposal[/url]
Anyone else have an opinion on this? @msl @zeno?

Most of it should be readily available in the build process. JSON data like this could also be used for a nice modern autobuild download page.

@dmitrys

Is the "METADATA" directory assumed to be under CHDK? In general, we try to keep everything in the CHDK directory, except for things like DISKBOOT.BIN which are dictated by camera requirements.
Logged
Don't forget what the H stands for.
*

Offline zeno

  • *****
  • 891
Re: CHDK for non-hackers
« Reply #24 on: 18 / April / 2017, 18:26:45 »
The metadata proposal seems a very good idea to me. With at least 4 cameras capable of running CHDK, the attempt to identify which camera a card supports by writing on it with a Magic Marker quickly becomes problematic.
Logged
A570, S100, Ixus 127
Author of ASSIST, STICK, WASP, ACID, SDMInst, LICKS, WICKS, MacBoot, UBDB, CFGEdit
*

Offline dmitrys

  • ****
  • 267
Re: CHDK for non-hackers
« Reply #25 on: 19 / April / 2017, 07:34:14 »
I consolidated the metadata proposals (there are now separate proposals for camera metadata and manifest).

Quote from: reyalp on 18 / April / 2017, 17:43:54
Most of it should be readily available in the build process. JSON data like this could also be used for a nice modern autobuild download page.

I was hoping all of it would be readily available (and thus moved the camera metadata to a separate proposal). Please let me know if I'm wrong.

Quote
Is the "METADATA" directory assumed to be under CHDK? In general, we try to keep everything in the CHDK directory, except for things like DISKBOOT.BIN which are dictated by camera requirements.

I believe it should be directly under the root directory to allow interoperability with other hacks (e.g. SDM). Dual-partition cards are another consideration.

As detailed here, CANONMSC seems to be a decent alternative, albeit not a perfect one.

In the meantime, client implementations of the software and camera metadata proposals are published under CHDKUtil org.

Edit: Added Detect Software step screenshots.
Edit 2: Updated proposals and added link to org.
« Last Edit: 19 / April / 2017, 18:31:52 by dmitrys »
Logged
Author of CHIMP, Canon Hack Installation and Management Platform
*

Offline dmitrys

  • ****
  • 267
Re: CHDK for non-hackers
« Reply #26 on: 21 / April / 2017, 18:18:20 »
I updated some code and posted an architecture page with links to all repositories.
Logged
Author of CHIMP, Canon Hack Installation and Management Platform
*

Offline reyalp

  • ******
  • 13880
Re: CHDK for non-hackers
« Reply #27 on: 22 / April / 2017, 19:52:06 »
Sorry for the slow response.
Quote from: dmitrys on 19 / April / 2017, 07:34:14
I believe it should be directly under the root directory to allow interoperability with other hacks (e.g. SDM).
If it's going be at the root level, I'd prefer to have the name be less generic. It could be CHDKMETA or HDKMETA even if it's shared with with other CHDK derived hacks. Or if it's just one file, just put CHDKMETA.JSN in the root or something.

Quote
Dual-partition cards are another consideration.
Indeed so, but this is true whether the directory goes in the root or not. Any software that relies on this would need to be prepared to find the directory in either or both partitions, possibly with different versions or not matching the actual binary.

Keeping it on the boot partition is a good argument for not having it in CHDK

Quote
As detailed here, CANONMSC seems to be a decent alternative, albeit not a perfect one.
I would be strongly against using a directory used/managed by the Canon firmware.

I have couple of reservations about the original proposal:

* Implementing all this all this for one utility that may not be maintained in the long term. Zeno's endorsement helps with this one ;)
* It's easy for the meta information to get out of sync with whats actually installed. Is it actually helpful if it's not reliable?

An possible alternative:
We could probably append minimal version info unencrypted to the end of DISKBOOT.BIN. It would be loaded and turned to garbage by the diskboot process, but this should be harmless, and wouldn't take memory at runtime. It would ensure that you can get the actual version of the binary, rather than an external file which can get out of sync.

I'm not sure if this would work or be safe with FIR/FI2 files. It would also be at the mercy of any future changes to the Canon file formats.

I'm just offering this for consideration, not advocating it over the original idea.
Logged
Don't forget what the H stands for.
*

Offline dmitrys

  • ****
  • 267
Re: CHDK for non-hackers
« Reply #28 on: 23 / April / 2017, 09:15:02 »
Quote from: reyalp on 22 / April / 2017, 19:52:06
If it's going be at the root level, I'd prefer to have the name be less generic. It could be CHDKMETA or HDKMETA even if it's shared with with other CHDK derived hacks.

I'm OK with CHDKMETA (or _HDKMETA perhaps?), although I'm not sure DSLR hack guys would be very happy about it.

Quote
Or if it's just one file, just put CHDKMETA.JSN in the root or something.

You're out of date :) There are currently proposals for three files, namely:

SOFTWARE.JSN to indicate the installed software
CAMERA.JSN to indicate the detected camera (cannot be reliably produced during CHDK build)
MODEL.JSN to indicate the selected camera (applies to the N/N Facebook case)

There is one additional proposal that's too high level to discuss ATM.

Quote
Indeed so, but this is true whether the directory goes in the root or not. Any software that relies on this would need to be prepared to find the directory in either or both partitions, possibly with different versions or not matching the actual binary.

My current code:

Quote
        private void CopyPrimaryFiles(string srcPath, string destPath)
        {
            CopyFiles(srcPath, destPath);

            var srcMetadataPath = Path.Combine(srcPath, "METADATA");
            CopyDirectory(srcMetadataPath, destPath);

        }

        private void CopySecondaryFiles(string srcPath, string destPath)
        {
            foreach (var dir in Directory.EnumerateDirectories(srcPath))
            {
                var dirName = Path.GetFileName(dir);
                if (!"METADATA".Equals(dirName, StringComparison.InvariantCultureIgnoreCase))
                {
                    CopyDirectory(dir, destPath);
                }
            }
        }

I believe metadata belongs with the binary, so if present, it must be on the primary partition (at least).

Quote
I would be strongly against using a directory used/managed by the Canon firmware.

I can see why, although I can also relate to the notion of keeping a memory card as tidy as possible (did I mention OCD already?). I just found out about the MISC directory, which seems to be created by newer DSLRs, and I find it even more compelling (since it's top-level).

Quote
* Implementing all this all this for one utility that may not be maintained in the long term. Zeno's endorsement helps with this one ;)

As far as client software is concerned, software metadata is of little use beyond the update scenario. I believe STICK and ASSIST are pretty much feature-complete, although I might be mistaken here.

Quote
* It's easy for the meta information to get out of sync with whats actually installed. Is it actually helpful if it's not reliable?

If the metadata is bundled, it requires a special effort on the user's part to mess it up.
If it's generated by a client software, that has to be really bad to either mess it up programmatically or cause the user to do that at a later stage :)

In any case, I think the worst-case scenario is the latest version being needlessly reinstalled (unless of course someone installs SDM onto a card while leaving the metadata intact).

Quote
We could probably append minimal version info unencrypted to the end of DISKBOOT.BIN. It would be loaded and turned to garbage by the diskboot process, but this should be harmless, and wouldn't take memory at runtime. It would ensure that you can get the actual version of the binary, rather than an external file which can get out of sync.

Here's a list of ideas upon deciphering dancingbits, in ascending order of insanity:
  • De-dance the binary after matching a magic bit sequence
  • De-dance the binary in all flavors (up to VITALY times)
  • Match a known binary hash (obtained from every binary ever built)
Compared to that, the idea of an unencrypted metadata block sounds great, although I'm not sure why it should be favored over the JSON proposal, other than the latter's being significantly harder to implement (although I am biased).

Edit 2017-04-24: Redacted.
« Last Edit: 24 / April / 2017, 08:50:55 by dmitrys »
Logged
Author of CHIMP, Canon Hack Installation and Management Platform
*

Offline waterwingz

  • ******
  • 12132
    • Waterwingz
Re: CHDK for non-hackers
« Reply #29 on: 23 / April / 2017, 09:25:26 »
Quote from: dmitrys on 23 / April / 2017, 09:15:02
You're out of date :) There are currently proposals for three files, namely:
Is this discussion is also happening in other forums?  Would you please provide links if so?
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
Pages: 1 2 [3] 4 5 6 7 8 ... 14   Go Up
« previous next »
 

Related Topics