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. :-)
Edited by miker1264 on 12-10-2024 12:16,
22 days agoAs 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.
Edited by miker1264 on 14-10-2024 14:05,
20 days ago
miker1264 attached the following image:
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.
Edited by miker1264 on 14-10-2024 12:33,
20 days ago
miker1264 attached the following image:
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.
Edited by miker1264 on 15-10-2024 13:31,
19 days agoTarga & 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.
Edited by miker1264 on 15-10-2024 14:20,
19 days agoAfter 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.
Edited by miker1264 on 15-10-2024 20:49,
19 days agoEncodeRLE 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.
Edited by miker1264 on 16-10-2024 13:27,
18 days ago
miker1264 attached the following file:
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! :-)
Edited by miker1264 on 17-10-2024 09:55,
17 days agoSo 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.
Edited by miker1264 on 18-10-2024 17:04,
16 days agoAMIGASYSTEMDistro Maintainer Posted
16 days agomiker thank you you are doing a great job, your tools are invaluable!
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.
Edited by miker1264 on 21-10-2024 12:17,
13 days ago
miker1264 attached the following image:
Making some progress reading the New Icon Data that is stored in the classic icon's Tooltypes.
Once I can extract the New Icon Data from the Tooltypes and decode it to save ILBM images it's a simple matter to convert New Icons to Glow Icons. Though most AROS users are only interested in PNG Icons! I'll get to that part later. ;-)
Edited by miker1264 on 24-10-2024 21:20,
10 days ago
miker1264 attached the following image:
Save New Icon is working. Icon Split can now extract New Icon Images stored in the classic icon Tooltypes. You can see the ILBM images img3.iff & img4.iff. Notice that the background is green.
It probably has to do with transparency value. I will sort that out by looking at all the test data.
Once EncodeRLE & EncodeBytes are fully working then Icon Press CLI version can save classic icons aka OS3.5 Glow Icons. Currently using EncodeRLE it can save 8bit Glow Icons. ;-)
Based on the functionality I'm bringing together and developing for Icon Split and Icon Press I'll be writing another icon application called Convert Icon. It will convert Icon styles such as PNG to OS4 or New Icon to Glow Icon.
Edited by miker1264 on 25-10-2024 13:21,
9 days ago
miker1264 attached the following image:
I'm working on a release version. It can split PNG Icons, Glow Icons & New Icons into images saved to Ram Disk.
Edited by miker1264 on 26-10-2024 18:18,
8 days agoI've been doing some testing. I still have to add the code to split PNG icons and icons with ARGB chunks such as OS4 icons and AROS icons. The code is already written I will only need to add it.
Caffeine OS on my Amiga 1200 uses OS4 style icons that are Classic Icons with limited IFF Data. It only has 'FORM' 'ICON' & 'FACE'. Usually for a Glow Icon after FACE comes the IMAG chunks with image & palette data. But OS4 icons don't have that. The FACE chunk is followed by 2 ARGB chunks that contain the 32bit image data. DecodeARGB uses zlib to decode ARGB chunks.
Previously I tested the icon splitter for 68k in WinUAE. I wasn't sure it would work on Amiga computers. But it works very well on my A1200. But I've mostly been using AROS x86 for development & testing since the code is the same.
Although it is useful for splitting icons into images that can later be edited, the Icon Splitter was more of a proof of concept. Whether or not it's possible to share the same source code between AROS & Amiga 68k was the test. The answer is absolutely we can share the source code.
Edited by miker1264 on 30-10-2024 17:50,
4 days ago
miker1264 attached the following image:
I'm having some difficulty getting my zlib code for DecodeARGB to compile for Amiga 68k & AROS x86. But there is another way to do that.
Icon Library uses ICONTRLA_GetARGBImageData1 & the same for second image. Maybe using disk objects works.
I'm curious if Caffeine OS (Amiga OS 3.9+) uses AfA OS & whether that includes AROS Icon Lib?
Edited by miker1264 on 31-10-2024 14:45,
3 days ago