Of course the Amiga CLI versions of Icon Split and Icon Press is not the end of the AROS/Amiga icon conversion adventure!

Simply converting PNG icon images to ILBM isn't enough to make Amiga Glow Icons. The PNG icons have ARGB (32bit) Glow borders and the ILBM icon images have RGB (24bit) Glow borders with a slightly different pattern. So I will need to update my Icon Builder Tool to use ChainCode to generate new Glow borders. For Amiga icons the ChainCode generates a 24bit Glow mask which will also be the glow border.

The Icon Builder Tool is where I left off several months ago so it seems likely I'll do more work on that AROS application as well. :-)

Grazie miker, felice di risentirti

As you can see in the screenshot the Amiga 68k version of Icon Split works on AROS 68k as well.

Why is such a small CLI application important? It's important because it's one of the two main methods for the Icon Maker application which can assemble or disassemble PNG or IFF icons. This application will hopefully be available for both AROS and Amiga 68k.

I'm currently working on the decoder portion using Icon Split CLI for testing. The application only needs DecodeRLE to decode the pallet data & DecodeBytes to decode the bitstream data for IMAG chunks. But for testing purposes immediately after decoding I then use EncodeRLE to re-encode the color palette & EncodeBytes to re-encode the image data in a bitstream. Hopefully, the decoded data & the re-encoded data are the same ! ;-)

Currently the encoder portion isn't working perfectly but the decoder portion works. Based on my work for the decoder I posted some documents on AROS Archives regarding the IMAG chunk bitstream data as far as decoding.

It took 6 weeks of work last time to complete the decoder portion of Icon Split CLI. But much of that was long hours of experimenting to determine the exact composition of the IMAG chunk. Only the last two weeks of that six week period were spent on fine tuning the decoder portion. So hopefully I can complete the encoder in less than three weeks. That's my goal at this time.

This is the concept for the Icon Maker for AROS and Amiga 68k.

Using the Icon Maker application it should also be possible to load an icon by drag-n-drop on the large display area. The images will be displayed. Then you can change the icon type and save a new icon file. That could be very convenient.

This is the current status for EncodeRLE that I'm testing in Icon Split CLI version. It's only needed for Icon Press to save a new Amiga Glow Icon.

EncodeRLE is working correctly for RLE compression (run length encoding) for the 8bit pallete data. However, there's a small problem.

There is an additional rule for the RLE algorithm for encoding. If there are two identical bytes immediately after & adjacent to a run of single bytes that are not identical, or if the two bytes are in the middle of two runs of single bytes, then it is added to the previous run of single bytes, or if in the middle of two runs of single bytes, it is added to the first run of single bytes and the new run & two new bytes and any immediately following run of single bytes are added to the total.

For example a run of single bytes is immediately followed by the bytes AD AD F0. Instead of the two AD values being treated as a run of identical bytes it instead gets added to the previous run. Likewise, F0 is a single byte that is different from AD so it also gets added to the previous run of single bytes. So AD AD isn't a separate run.

Being aware of the problem and solving it are different matters. If I use idx (index) & pdx (previous index) to keep track of the location in the input byte sream I can maybe deal with these two conditions when they happen.

Targa & PCX datatypes use slightly different versions of RLE compression. The image data & palette data in the IMAG chunks of Glow Icons use ILBM RLE.

The best way to learn about RLE compression is to write my own RLE encoder & decoder. The encoder & decoder for the bitstream of data for the IMAG chunks are very similar to EncodeRLE and DecodeRLE. For the bitstream it does the same but there is a lot of bit shifting involved. Instead of 8bits for regular RLE the bitstream encodes & decodes data by bit depth which is <=8.

When I have a better understanding of RLE compression then I can finish updating Targa & PCX datatypes. Also, AROS ILBM & Picture Datatypes don't use RLE compression. When I updated the save functions for those the output images are uncompressed because I didn't understand ILBM RLE.

After testing it seems that the idx & pdx solution works for the condition where the two byte run adjacent to a run of single bytes happens at the end of a palette.

Further testing will be needed to verify if it works for other Glow Icons. Hmmm. I suppose a good test for EncodeRLE will be to include it in AROS picture.datatype to see if it can compress Ilbm. Actually , I can test it by using Icon Split before saving the ILBM images they can use RLE. :-)

The next few steps are to clean up EncodeRLE & to make the variables to match what is being used in DecodeRLE to be consistent. Icon Split CLI itself needs to be able to split Dual PNG icons & then DecodeArgb is needed using zlib. Need to test for zlib first before using DecodeArgb. Amiga 68k may not have it.

EncodeRLE seems to be working but I still need to test with more Glow Icons from OS3.5 to ensure compatibility.

It will still take some time to finalize a working version of EncodeBytes to encode the image data in a bitstream for the IMAG chunk. There is much bit shifting ( far more than I'd like :-) ).

The bit shifting is needed to encode the image data with a modified version of PackBits which is run length encoding but at the bits level where the RLE control bytes are 8bits & the intervening image bits are by bit depth (bitplanes).

Here is a sample log file that I use for testing. It's far too much information to print in the shell. I redirect the output with '>' to a text file to read later. I can then verify if it's encoding/decoding data correctly. Everything has to be precise.

This log file has 12,184 lines of text.

The PDF Document that I uploaded to AROS Archives called "IFF Icons Data Decoded" seems incomplete. It only discusses the decoder.

Now that I'm working on the encoder portion I plan to update the documentation. I could do better than the current document. I've been using it for reference and it seems incomplete.

It's almost as if developing a working encoder for the bitstream data is at the limits of my programming ability. It involves a lot of bit shifting and masking of bits that I barely understand. It's an iterative process and I have a good, reliable hex editor. Eventually the encoder portion will be finished. It still amazes me that the decoder portion for the IMAG chunk actually works! :-)

So far so good. I'm making some progress.

I have the framework for an encoder for the IMAG chunk data. Doing binary bit shifting by hand is not much fun. Now I have to combine the bit shifting portion with the EncodeRLE.

It works with an upper bit buffer and a lower bit buffer with changing bit index values. The upper one loads and processes the 8bit RLE bytes. The lower one loads and processes the bytes for loop bytes and copy bytes.

miker thank you you are doing a great job, your tools are invaluable!

Thanks. Writing this IMAG chunk encoder reminds me of when I was writing the ILBM save functions. Lots of research and experimenting.

Here is the basis for the encoder for the IMAG chunk data. I included my calculations to help explain what is happening in the bit buffers.

Now that Icon Split CLI version is working to split OS 3.5 Glow Icons into 2 ILBM images I will finalize that version. Before that I will add a method to detect New Icon Data in the tool types and a -n switch which will force extracting the new icon images to save as ILBM images. Being able to split the new icon images means we can easily convert New Icons to Glow Icons.

In addition it will be able to split Dual PNG Icons into PNG images. That will mostly be useful for AROS users but Amikit for Pi uses PNG icons. So it may be useful for Amiga 68k users as well.

I will post the AROS versions of Icon Split on AROS Archives and the Amiga 68k version will be posted on Aminet for Amiga users to use.

most Aros users today are on 68k