The IFF Icon Image Data Decoder files have been uploaded to AROS Archives for reference.

Here is the DecodeRLE & DecodeBytes algorithms that I wrote recently to decode the image data for IMAG chunks for Glow Icon Format. I have included the code snippets as well as a documentation in PDF format to help explain it. Hopefully I can do the same for the Encoder part when I have finished it. The image data decoder and RLE decoder are working as written in my test program. So these are working samples. Just for your information the original inventor of NewIcon format was Phil Vedovatti. And the one responsible for designing the Glow Icons used with Amiga OS 3.5/3.9 was Mat Chaput. I'm not sure if he was involved in the programming as far as the storage format for the image data. From his blog site he seems more of an artist than a programmer though he could be both. Although the developers working on Amiga OS 3.5/3.9 including Olaf Barthel and others surely knew and understood the IFF Icon Image Data Storage Format they didn't provide documents. Maybe there were NDA's preventing that also. But now you have the documentation. Enjoy!

The change for the while statement fixed it so that now it reads all the input byte array and there are no extra bytes in the output array. So for the test icon with the first image size of 1932 bytes now out matches bytes. Nice!

After thinking about it I believe the error that writes extra bytes at the end of the output buffer is caused by programmer error. The main while loop conditional statement is: while ( out <= bytes ) which causes an error. In this case out is the index counter for the output buffer and bytes is the total size of unpacked data in bytes which is equal to width * height. If you consider while ( out < bytes ) the first time the condition is NOT true is when out is exactly equal to bytes which is exactly when we want to drop out of the while loop. But for while ( out <= bytes ) the first time it is false is when out is at least one more than bytes. That is the problem. It forces to read an extra byte from the input buffer that isn't really there. So it should be while ( out < bytes ). I'll try that tomorrow to see what effect it has on the output

In the sample code provided DecodeBytes is my decoder algorithm that I wrote yesterday based on my DecodeRLE that I wrote at the same time. It's astonishing to me that it works beautifully. It decodes every byte in the image data correctly. The IFF Icon Image Data in the IMAG chunks are stored as a "bitstream" of data not a bytestream. It's just that it currently writes 2 extra bytes to the output buffer. For one of my test icons the first image has 1932 bytes but DecodeBytes writes 1934 bytes. It has an index/offset issue. It's not a serious issue though for saving ILBM images. The chunky buffer size is still only 1932 bytes. The extra bytes are unused. But it's bothersome that it writes extra data. I will fix that. Other than that it works great.

AMIGASYSTEM This is iconsplit_cli and it only works with Glow Icons such as ones from Amiga OS 3.5/OS 3.9. NewIcons stored in tool types aren't supported. I was using Calculator.info from OS 3.9 to test. At some point I may add support for the NewIcons. Also, unless you redirect the shell output to a file you will get about 2000 lines printed as debug. This code is only for testing and so you can look at the EncodeRLE, DecodeRLE & DecodeBytes. The syntax is such as: iconsplit Calculator.info >"Ram Disk:log.txt" Such as the ColorIcons in "test-icons" here: https://github.com/steffest/Amiga-Icon-converter

I tried to compile, if I run iconsplit I get this message? see screenshot How do I use it? If I send the command: IconSplit nomeicon.info I get the size of the icon and then a Guru I tried an old icon and a newicons

Recently I had a chance to test the DecodeRLE (unpack byterun) function that I wrote yesterday to decode RLE encoded data. It works well for the encoded palette byte arrays in the icon files. Also, I tested my new DecodeBytes icon image data decoder based on DecodeRLE. It works ok. But you can see from the screenshot that it's missing half the image probably due to user error. That happens. LOL But the fact that it is decoding anything is much better than I expected. Yesterday I was thinking "usually the new code doesn't work the first time. I can expect it to fail horribly and produce images that are garbage. But then again it may surprise me. It could compile correctly the first time and it could just work beautifully!" Well, neither of those happened. It's somewhere in between. It works somewhat.

For the IconPress project I need to write a bitstream encoder for the image data for the IMAG chunks in the IFF Icon Data. I've made some progress understanding the encoding & decoding of image data. Maybe I will revise the IFF Icon Image Encoding text file so I can include it with the "Amiga IFF Icon Format" text file that will include more information about OS35 Extension IMAG chunks & ARGB chunks for AROS Icons & OS41 Icons. The text files will be posted as reference for anyone wanting to write an Encoder or Decoder to read/write Amiga Icon Files. Currently there is very little information available. The developers working on Amiga OS 3.5 or Amiga OS 3.9 were familiar with the image encoding format for the IMAG chunks but they didn't publish anything. It's almost like they assumed that IconEdit & Icon Library would handle all the Amiga Icon reading & writing so nothing else is needed.

yes the system is more pleasant with the new decorations

the software I added is vnc, I updated amifox and amitranslate

thanks for your effort:)

I'm writing the "Amiga IFF Icon Format" text file that is a supplement to "Amiga Icon Format" by Dirk Stoecker. I'll include the information about number of used colors vs total number of colors.

Sometimes the simplest things can seem complex. For 3 days I was chasing an error that didn't exist. My encoder function for IMAG chunks was returning lots of extra bytes for the colormaps. So I wrote an RLE encoder function from scratch. It worked beautifully in my test program. But when I inserted it in IconPress the same "extra bytes" appeared in the colormap. Why was it reading beyond the length of the colormap data? How was that even possible. The solution was very simple. The test program worked because it received the correct data. IconPress was sending the wrong information. The Glow Icon records the total number of used colors in the IMAG chunks. Whereas ILBM files use the total number of colors by depth which is ( 1<<depth). For depth of 5 numcolors is 32. But total used colors for my sample icon is only 17. So the colormap data was sending 96 not 52. Size in bytes of the colormap data is ( 17 * 3 ). I will need a new function to Find High Index. So that means ilbmtoicon also has an error.

the changes are the updating of some software that you find in the desktop icon panel and the addition of themes with background image [url=https://ibb.co/SyWB1bV][img]https://i.ibb.co/tKkDNgY/tiny.png[/img][/url]

This is the first real Amiga Icon (Glow Icon) produced by IconPress. The OS35 IFF data was written to a test file. I combined the IFF data by appending it to the end of the old icon data. My IFF Icon Data was missing a single padding byte at the end of IMAG one. 747 bytes should have been 747+1 to make it modulus 2. There was also an extra byte at the end of the Cmap for IMAG two. It was 0x58 in size but the extra byte made it 0x59. Those two issues are minor. My icon produced by IconPress is the second one called "Calc2.info". The "Calc.info" icon is one produced by another program I was comparing mine to. Calc.info has Transparency as 0xFF. Mine has 0x00 so my color 0 is transparent. The size of the colormap byte array is still not correct but it displays correctly anyhow. I may use a simple PackByteRun algorithm to encode the palette data instead of the image encoder. The colormap is an array of 8 bit chunky bytes compressed using RLE which is the same as for compressed ILBM images. Compressed IMAG image data however is encoded differently.

Thanks for your hard work, thanks to you it is now possible on Wanderer to manage Icons, which was impossible before!

Sometimes when one works very hard to find a solution to a perplexing problem maybe it's not actually a problem. Maybe the test method is wrong instead. For about a week I have spent many hours working on IconPress for the Save_Amiga_Icon functions. Everything was going well until I reached the point where I needed to encode the image data and palette data for the IFF IMAG chunks. I had setup a test where I could encode the data then write it to a file so that I could use a hex editor to compare my output to the original Glow Icon in this case It was the Calculator Icon. But each time the data that my program encoded seemed different than the original so I assumed the encoding method that I used was wrong. But after several days of trying everything I could to get better results I realized that the test was wrong. If the encoder uses the correct RLE encoding method the data in the output file may actually be different. So my image data is ok. But there's much more work to do for IconPress.

AMIGASYSTEM OK. I will fix the GUI for that one and post the binary again. It's been a while that I worked on it. Recently I've been working on IconPress and it has been taking a bunch of time away from other projects. I'm still trying to reconstruct my programming PC also. That's what I'm doing now. Thanks for your patience.

I published an new iso the changes are minimal and the release does not change enjoy!!