Here is the AROS version, the Amiga version including the binaries and source code for each.

Thanks miker, IconSplitter works fine on AROS One, is there a GUI planned for IconSplitter in the future?

AMIGASYSTEM

The AROS version in the next update will have a GUI to make it easier for users to save images. There may be a simple menu system to choose which images to display, two at a time.

The planned GUI will look similar to this mockup. It has two image display areas and two buttons. The buttons at the bottom will say "Save Image" for both images to save them independently. Drop an icon on either display area and it will be split into images which are then displayed. It will make more sense when the GUI is working.

For the AROS version the user can choose to use the GUI or use the commandline instead. There will be a few switches such as -o, -n, -t. The first switch opens the GUI but messages are printed to the shell, the second one forces to split new icon images if present, the third requests to save Targa instead of PNG images.

The Amiga version will remain a CLI version with a few planned improvements. Hopefully by then Amiga Datatypes support will be working and maybe support for zlib to compress or uncompress image data.

Thanks miker, in the meantime I have integrated it into Dopus4, where you can split and save images with one click.

On Dopus4 I couldn't decide to save in the path of the second window because you set RAM as the destination.

To split and save images the temp images are saved to Ram Disk but they are saved in a specific way. OS35 icon images are saved as img1.iff & img2.iff. New Icon Images are saved as img3.iff & img4.iff. PNG images are saved as img1.png & img2.png. OS4 & AROS ARGB Images are saved as img3.png & img4.png.

Depending on the style of icon that we are splitting you know what the resulting filenames will be. You can just copy the temp images to the selected filenames. That's for the current version. For the next update it may be better to save to the same directory as the icon using the Icon name + _1.iff etc. to make things easier. :-)


As for practical uses, if you have several OS4 icons that look really nice and you want to use them for AROS then use the Icon Splitter to split them into PNG images. Then use IconDrop or some other app to make New Dual PNG Icons.

For that purpose I'm planning another icon tool "ConvertIcon" that will convert from one icon style directly to another icon style. Such as convert an OS4 icon directly to a Dual PNG Icon, or PNG Icon to OS4 Icon. It will be very useful.

I'm currently working on Icon Press to revise the code for saving icons. There is much work to do. I will probably spend the next six weeks on this project then I will release a new version of it.

As you can see in the screenshot for Icon Press the coords for EraseRect are off so it erases part of the user interface. But Icon Drop uses the same GUI and I solved the display issue there. So I will compare the code between to two.

There's another more important issue that I have to address. I'm using a function called createrle that encodes the image data for the IMAG chunks. It's a placeholder until I can finish my own EncodeBytes function that does the same. The createrle function is used in Ilbmtoicon & AROS Icon Library. But it has some issues.

For my test os35 icon "Calculator.info" createrle returns the first IMAG image size 704 but it's supposed to be 704 bytes. It returns the second IMAG image size as 940 but it's supposed to be 956 bytes. Several bytes of data are missing!

So I need to do a test to identify the problem. I will print all the byte values for the index values using DecodeBytes to decode the original icon & the new icon produced by Icon Press to see if any index values are missing. I will need to compare log files to find the problem if there is one.

After doing a lot of testing with printing all the values from DecodeBytes to log files, writing the image data to .bin files, examining the icon images with a paint program to compare colors for the original icon & the one saved to file using the createrle function I have come to a conclusion.

Although the encoded IMAG chunks were of slightly different sizes the binary image data & the icon images themselves were exactly the same. Createrle & the algorithm that encoded the original Glow Icon Data actually encoded the icons differently. But the encoded data still followed the rules of run length encoding by depth. So my DecodeBytes algorithm had no problems.

My first task for Icon Press will be to test several different icons to encode the Color Palettes using EncodeRLE that I wrote for the 8bit data. Then I will rewrite EncodeRLE with an upper loop & lower loop to facilitate adding bit shifting to make a new function called EncodeBytes to take the place of createrle.

Progress on IconPress is coming along nicely. The encoder for the IMAG chunks is working. For the next two weeks I will focus on moving all seven sub-functions out of the main function Save_Amiga_Icon so I can test everything to make sure it works to save classic icons aka Glow Icons. When that is complete I may write an IconPress CLI version for Amiga 68k.

When saving classic icons is working in IconPress then I will include the new code in IconDrop so I can update it for AROS x86. So then IconDrop will be able to save Dual PNG Icons or Amiga Glow Icons based on the input images.

I wanted to work on IconBuilder after that but I may work on the PictureConverter program so I can post an initial release of it to AROS Archives.