Skip to content

Add image/x-amiga-icon format#2547

Open
bitplane wants to merge 7 commits intoMediaArea:masterfrom
bitplane:format/amiga-info
Open

Add image/x-amiga-icon format#2547
bitplane wants to merge 7 commits intoMediaArea:masterfrom
bitplane:format/amiga-info

Conversation

@bitplane
Copy link
Contributor

@bitplane bitplane commented Mar 7, 2026

This PR adds support for 4 (of 5) different Amiga .info formats, as documented here:

http://www.evillabs.net/index.php/Amiga_Icon_Formats

The 5th type are concatenated PNG files with icon metadata inside the first image, they aren't included as part of this patch.

The code was tested first with basic icons here:

https://github.com/steffest/Amiga-Icon-converter/tree/master/test-icons

Then against 300k files extracted from Aminet's archives. MediaInfoLib is pretty robust, bad files detect in the latest version even if they're truncated. The command line doesn't like some of the file names though, which is a separate bug. The full suite of test data is available here:

https://github.com/bitplane/amiga-info-test-files

This was done as part of writing this Python conversion library; I wanted mediainfo to help me identify files for coverage purposes, and wrote this patch to help me.

@JeromeMartinez
Copy link
Member

Thank you for this PR.

185 files remain

Does it mean that I should wait before reviewing deeply this PR?

@bitplane
Copy link
Contributor Author

bitplane commented Mar 9, 2026

Does it mean that I should wait before reviewing deeply this PR?

I managed to get it down to 185 actual errors after fixing my test harness to use MediaInfoLib rather than mediainfo.

It turned out that these are all bad data:

  • about half were truncated files, which I think is an extraction issue (non-ascii file names sometimes have unrelated data in them and are sometimes a bit shorter than expected - bugs to report elsewhere)
  • about half of them having fields containing what looks like memory addresses rather than sizes. Probably made using custom tools back in the 90s, that wrote uninitialized data into unused fields, and nobody noticed because it used the highest quality images on current systems.
  • some impossible situations like palette sizes larger than the number of planes. Likely the same as above, or users messing about in a hex editor.

I think an 0.06% failure rate is to be expected in the wild, so good to go for review :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants