Ive been quiet lately because I've been busy. 🙂

Over the last 2 weeks I've been working on the icon tools that will eventually be included in Icon Toolkit. These icon apps will work independent or as a part of Icon Toolkit which is an app launcher with a button for each icon application.

Most recently I've been updating Icon Press Icon Maker.

So far it can load both ILBM & PNG images. It can only save DualPNG Icons though. So I needed more PNG Icons for testing. The floppy icons will be posted on AROS Archives as soon as I can assemble the finished .info files.

In addition I'm working on the many functions needed to save Amiga Glow Icons from 2 ILBM images. I've had some success but the Glow Icon Format is much more complex than PNG.

The various functionality I'm developing for these icon tools will in the near future be used with Icon Toolkit.

For a longer term goal they will be the basis of a tool that has been missing on AROS. For Amiga users the yellow pencil box icon is very familiar.

For the moment only the buttons and string gadget will be actual gadgets. All other elements are drawn in the rasterport using Graphics Library.

The various functionality that will be part of Icon Edit include assembling, disassembling and saving PNG Icons, Glow Icons, ARGB Icons and Amiga OS41 Icons. The palette will be shown for Glow Icons and ARGB Icons. The Extended Tools will include Duplicate, Darken, Add Glow, Glow Tint and Clear All to clear all the display areas. Being able to duplicate the 1st image, darken it and add a glow border is part of basic editing. The Glow Tint option allows changing a glow border tint from neon yellow to neon green or neon blue by using HSL values to shift colors .

Those are the plans so far.

Great Miker

Thank you Miker, these tools will be very important for AROS, I hope to include them in the next release of AROS One 2.3

IconPress is the current Icon App that I've been working on for about 2 weeks now updating it and adding more functionality.

It can load 2 PNG images & it can save a new PNG icon. It can also load 2 ILBM images. I'm still working on Save Amiga Icon. There are about 20 helper functions involved in loading the images using only native methods, converting the planar data to chunky data, loading image data, bmhd & cmap data into an IconImage struct, encoding the image data & palette data to write the IMAG chunks and the diskobject data.

It's very complex. For comparison MultiView has about 2500 lines of code, IconClone has about 4000 lines, and IconPress is approaching 6000 lines of code not including to save ARGB icons.

Saving Amiga Icons (Glow Icons) is almost working. Maybe another week to go then lots of code cleanup to make the sources look nice.

Excellent tool!

yes excellent Miker

miker, sorry for my request, could you enlarge the GUI of DTConvertGUI, as you can see from the screenshot the text "Destination" is at the edge of the GUI, maybe you could shorten the field and make it the same size as the SourceFile one (see screenshot).

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.

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.

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

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.

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.

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.

thanks for your effort

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.

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.

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

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.co...-converter