icon splitter

[miker1264]

The streamlined AROS Icon Splitter is almost finished.

It can now save ILBM images with chunky to planar conversion & bitplane reduction.

Whereas before we were just saving 8bitplanes now it converts & saves the correct no. bitplanes & numcolors by depth.

[miker1264]

Just when you thought the Icon Splitter Project was completed...

The first image decoder was DecodeOS35. The second one will be DecodeArgb for AROS Argb Icons & OS41 icons with ARGB data chunks. Unfortunately they use zlib compression.

[magorium]

It can now save ILBM images with chunky to planar conversion & bitplane reduction.

Whereas before we were just saving 8bitplanes now it converts & saves the correct no. bitplanes & numcolors by depth.

Congratulations on your progress. I am still working on some abstraction so i can add the ILBM saving parts (which is a still a long way to go for me).

Just when you thought the Icon Splitter Project was completed...

The first image decoder was DecodeOS35. The second one will be DecodeArgb for AROS Argb Icons & OS41 icons with ARGB data chunks. Unfortunately they use zlib compression.

Yeah. I had to use the zlib uncompress function for that. Other then that it is pretty straighforward:

DWORD which always seems to be 1.
DWORD compressed size - 1
WORD  always seems to be zero
followed by array of compressed size bytes which can be fed to uncompress. Size of the destination buffer is FACE chunk fields Width (+1) * Height (+1) * 4 (ARGB bytes per pixel: note the order of ARGB)

edit: in the end i'll have a look at the deflate algorithm to see if it can be implemented without depending on zlib. see also here.

edit2:  In case interested in the layout of the zlib compressed data see here

[miker1264]

@magorium

Thank you for the information.

At least the data format of the ARGB chunk is better documented than the data format of the IMAG chunk. Although IMAG is better understood now.

There is some additional information provided by PeterK about the flags in the FACE chunk where bit 0 means frameless & bit 1 means ARGB data is present. Although searching for the 'ARGB' chunkID works just as well.

We have to be able to decode the ARGB chunk data for AROS ARGB Icons which are Classic Icons with IFF data with IMAG chunks & ARGB data chunks. Also for OS41 which are Classic Icons with IFF data with a FACE chunk but no IMAG chunks followed by ARGB data chunks.

The ARGB data can be exported as PNG images.

[miker1264]

The command line version of the icon splitter for AROS that I'm working on is the basis for the IconSplit GUI (GadTools).

All valid images will be available to save after loading. The command line version will simply save all. The GUI version will give a choice. To accomplish that I'm using 3 structs to store the icon data:

struct IconPalette,

struct IconImage (contains ImageData & IconPalette),

struct IconImageCollection (contains string IconStyle & 2 sets of IcoImages [ OS35Image, ARGBImage].

All ImageData is either 8bit or 32bit chunky bytes.

I still have to make sure it all works correctly. I'm not so sure about how the structs will work as a group.

Along with aiix icon splitter I'm starting a nice Windows-Amiga-Aros Apps collection.  (Windows Apps for Amiga)

[magorium]

At least the data format of the ARGB chunk is better documented than the data format of the IMAG chunk. Although IMAG is better understood now.

True.

There is some additional information provided by PeterK about the flags in the FACE chunk where bit 0 means frameless & bit 1 means ARGB data is present. Although searching for the 'ARGB' chunkID works just as well.

Yeah, I knew. Sorry for that. I should have linked to the post of PeterK at EAB 

We have to be able to decode the ARGB chunk data for AROS ARGB Icons which are Classic Icons with IFF data with IMAG chunks & ARGB data chunks. Also for OS41 which are Classic Icons with IFF data with a FACE chunk but no IMAG chunks followed by ARGB data chunks.

The picture posted in my reply #45 is such ARGB icon.

The ARGB data can be exported as PNG images.

I'm still thinking about adding support for (optional) saving them as 32-bit ILBM as well.

Although I can fire up AROS and/or classic to verify a few things I had (perhaps still have?) a difficult time finding a viewer for Linux that is capable of viewing particular ILBM files. For now I settled with XNView but initially resorted to an online ILBM viewer. Most viewers do not support bitmap depth schemes other than 1,2,4 or 8 planes, not to mention crashing completely when not supplying a full CMAP (the IFF standard does allow it).

So I had to waste a few days figuring out whether or not my code was doing things wrong or the used viewer was in error 

Next on the list is adding (RLE) compression but it is not the most important feature to me to add right now, I rather focus on something you wrote in your post that you wrote right below the one I quoted, namely being able to access all icon related image data in a way that makes the code a bit more bearable to read as it is currently a giant mess 

[miker1264]

I'm starting the process of compiling the icon splitter for Amiga OS 3 as well as for AROS. It only uses standard methods to read Classic Amiga Glow Icons to split them.

One question though. Is zlib available for Amiga OS 3.x ?

[AMIGASYSTEM]

One question though. Is zlib available for Amiga OS 3.x ?

If you are referring to the zlib.library you will find 2 versions of it here:

https://amiga.foul.fr/index.php

[miker1264]

One question though. Is zlib available for Amiga OS 3.x ?

If you are referring to the zlib.library you will find 2 versions of it here:

https://amiga.foul.fr/index.php

Thank you. That helps immensely.

I can use standard methods (simple C code) to split an Amiga Glow Icon into images.

That should also work on Amiga OS 3.x and AROS. The difficulty was that ARGB data chunks such as used with
Amiga OS4.1 icons requires zlib on AROS to decompress the ARGB data before writing PNG images from that data
or any further processing such as converting Amiga OS4.1 icon to AROS Dual PNG icon.

The missing part for using the IconSplit code on Amiga was the use of zlib. This makes things much easier. 

The IconSplit cli version written for AROS has been compiled for Amiga 68k and it is working in Amiga OS 3.5.

But I believe it is getting the wrong offset to the IFF data. So there's still much work to do now that I feel better. 

[miker1264]

Actually, after doing some research and testing I found that it is reading the offsets correctly.

Notice at the end it says number of OS 3.5 icon images is 0. That's because the orange icon only has newicon images in the Tooltypes. That's why the end of the Tooltypes + 6 bytes is the end of the file ( offset 1965 ).

I suppose I should try the icon splitter with an icon that really has IFF icon data. Maybe then it will save the ILBM images.

This is only my second Amiga 68k program. The first one of course was "Hello Amiga World" using an EasyRequester. 

[miker1264]

I can confirm that the Amiga 68k version of the Icon Splitter is working!

See screenshot...

[miker1264]

And best of all...

The Amiga 68k binary that runs on Amiga OS 3.5 also runs just fine on AROS 68k.

So now I can comfortably switch to test the splitting of ARGB icons with AROS 68k since it can display these icons.

[AMIGASYSTEM]

As always great work miker !

[miker1264]

As always great work miker !

This is only my second Amiga 68k program after Hello World. 

I was quite surprised it compiled easily and it worked as expected. It only uses native methods (standard C code) with no libraries, datatypes or OS methods.

I was also quite surprised that the Amiga 68k binary also works unmodified on AROS 68k. That means it's hopeful that the GadTools user interfaces for the other Icon Tools will also work with Amiga 68k as well as for AROS with the same sources.

[NinjaCowboy]

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!