icon splitter

[AMIGASYSTEM]

The 68k version of AROS aims to be binary compatible with 68k Amiga applications, so that's a good sign if it works on both!

Yes AROS is compatible with 3.0/3.1 binaries but it is not compatible with 3.2/3.5/3.9 binaries.

Also, AROS 68k "native" (ELF) binaries are not compatible with Amiga systems (all of them)

[miker1264]

The 68k version of AROS aims to be binary compatible with 68k Amiga applications, so that's a good sign if it works on both!

Yes AROS is compatible with 3.0/3.1 binaries but it is not compatible with 3.2/3.5/3.9 binaries.

Also, AROS 68k "native" (ELF) binaries are not compatible with Amiga systems (all of them)

That depends on the 68k binary.

I used DevCpp to compile IconSplit as an Amiga 68k binary. I used Amiga OS 3.5 in WinUAE and AROS 68k Vanilla to test. It works well in both. I assume it works for any Amiga OS 3.x since it works with OS 3.5.

[AMIGASYSTEM]

I used DevCpp to compile IconSplit as an Amiga 68k binary. I used Amiga OS 3.5 in WinUAE and AROS 68k Vanilla to test. It works well in both. I assume it works for any Amiga OS 3.x since it works with OS 3.5.

Yes I was referring to the opposite, Binary AROS 68k cannot run on Amiga (All)

Regarding App 3.2/3.5/3.9, do they use "Reaction" not supported by AROS 68k ?

[miker1264]

I used DevCpp to compile IconSplit as an Amiga 68k binary. I used Amiga OS 3.5 in WinUAE and AROS 68k Vanilla to test. It works well in both. I assume it works for any Amiga OS 3.x since it works with OS 3.5.

Yes I was referring to the opposite, Binary AROS 68k cannot run on Amiga (All)

Regarding App 3.2/3.5/3.9, do they use "Reaction" not supported by AROS 68k ?

That depends on the app. Mine is a cli app with no user interface. My other Icon Tools use GadTools user interface. You can choose to use Reaction GUI Toolkit or MUI or something else for Amiga but to be AROS compatible it should be cli only, GadTools or MUI. I'm still experimenting.

[AMIGASYSTEM]

Usually OS3 based MUI or GadTools Apps are better supported by AROS 68k, then maybe the incompatibility may also depend on the libraries used, maybe OS 3.9 and 3.2 use more up-to-date libraries.

[NinjaCowboy]

IIRC, classic Amiga 68k uses the Hunk format for executables, while AROS, MorphOS and AmigaOS 4 prefer ELF. So, an AROS ELF file won't run on a 68k Amiga.

[AMIGASYSTEM]

Yes correct, although AROS, MorphOS and AmigaOS 4 use ELF incompatible with each other !

[NinjaCowboy]

Yes correct, although AROS, MorphOS and AmigaOS 4 use ELF incompatible with each other !

That's a shame.

[miker1264]

So what do we do with the ILBM images once they have been split from the icon & saved to files?

We could easily convert them using datatypes to 32bit ARGB then save as PNG. After that we can use a paint program to edit the image or we could use HSL color rotation to change colors.

After modifying the image how do we convert it back to ILBM that can be used to make a new GlowIcon? I wrote a small command line app called DT2GIF. It converts 24bit or 32bit images using Neuquant into 8bit GIF with 256 colors.

In this case the output of Neuquant is determined by Max Colors which in this case is 256. If we modify the program to make it DT2OS35 for example we set the number of Max Colors to 32. Neuquant will quantize the colormap to 32. But the index values are still 8bit chunky values. Luckily IconSplit has provided some useful functions for the conversion process.

I can re-use SaveImage to use native methods to save an ILBM. I can also use the functions MakePlanar & ChunkyBytesToBitplanes to reduce the number of planes to 5 to correspond to 32 colors. It also outputs planar data. The colormap & planar data are then sent to SaveImage. We can specify the max colors (planes) at the command line. So it doesn't need to be 5. That's just an example.

Of course, if this process works ( DT2OS35 ) then we could in theory quantize any 32bit icon image to save an ILBM. The ILBM images could then be used to make a new GlowIcon. Maybe not all 32bit icon images are suitable to convert but it would be interesting to try.

I believe this could work to quantize a 32bit image and save it as ILBM with the specified number of biplanes. ;-)

[miker1264]

@magorium

I was just wondering if you had completed aiix icon splitter?

I will send you a PM regarding the Pascal sources.

I'm working on the Encoder part to save Amiga Icons. Maybe if I understand the Decoder part better it will be easier to write a working encoder.

In the meantime I wrote an RLE encoder algorithm from scratch that works well to encode the 8 bit palette data.

That's a good starting point for the image encoder part.

[magorium]

I was just wondering if you had completed aiix icon splitter?

Unfortunately I did not finish the project. I stopped at my 3th re-write for some reason (the reason why eludes me atm, probably some distraction).

The previous two rewrites were necessary for me in order to grasp/detail the saving routines and detecting the re-use of the same coding/decoding routines. That led me to a smart-ass solution for the 3th rewrite but one which I never seem to have finished (no saving routines implemented at all). Things become rather complicated when you want to be able to convert from every available storage type to another one, including reducing colors (in case necessary).

I will send you a PM regarding the Pascal sources.

That is ok. I already noticed your PM but allow me a little time to clean things up 

I'm working on the Encoder part to save Amiga Icons. Maybe if I understand the Decoder part better it will be easier to write a working encoder.

Understood. It is complicated enough as it is.

Funny/Ironic part is I used c-code for reference 

In the meantime I wrote an RLE encoder algorithm from scratch that works well to encode the 8 bit palette data.

Nice !. at least that means you'll have something that you can check against.

[miker1264]

I have made some progress understanding the encoding and decoding process for the IFF Icon Data as far as the encoded image data. It is a "bitstream" of data. The bytes we see in the encoded data are not real bytes. They are encoded bytes. Even the RLE bytes are encoded also.