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.

Here's something I find interesting.

I have been revising my routine to save Amiga Icons. Initially it was one big function with about 2,000 lines of code which was very difficult to edit. It was completely unreadable and it wasn't easy to understand what was going on so I decided to break it up into one small main function to direct traffic and several sub-functions much like I did with ILBM Datatype. The save function was Save_,ILBM which used bit depth to directed traffic to SaveBitmapPic or SaveRGBPic.

So I broke out both Write_DiskObject and Write_DrawerData into sub-functions. Write_OS35Data was already stand alone. When I finally got it to compile after fixing several errors I noticed something odd. The output file was only half the size I expected because all the Old Icon Data was missing. It only had OS35 IFF Icon Data. I thought my offsets were wrong for Seek and Write. But after testing it for a couple hours with the same result I found my mistake.

For Write_Diskobject and Write_DrawerData I was opening the output file to write them closing it for each function. But I was using MODE_NEWFILE for the sub-functions so the file was being renewed each time. Only Write_OS35Data was using MODE_OLDFILE and it worked correctly. After I fixed the mistake everything works as expected. It was a rookie mistake. I should have known. :-)

miker in your screenshot I noticed the slightly rounded window, how did you create the transparency in the cut corner ? if I leave the corner transparent Wanderer adds a small black background ?

For example on the many Pointers I have created, the transparencies work perfectly both on AROS Native Video Card and in VESA mode.

However, unintentionally when testing VMWare in "Native Mode" the transparency in the Pointer was replaced by a black or White background.

Strangely, however, I noticed that the native AROS Pointers (those included in the Build) did not have this problem in "VMware Native Mode".

I tried to understand the difference without finding anything, the AROS Native Pointer loaded on any Paint including Photoshop once saved even without making any changes became like my Pointers with the same black shadow problem.

After much testing I finally managed to eliminate the problem by using the IconEditor program which allowed me to save a Pointer image with compatible transparency.

Question, do you know what software they use on AROS to create Pointers ?

AMIGASYSTEM

That's the yet unfinished Mahogany Window Theme. The rounded corners are an illusion. It's the shape of the window Titlebar Image itself that provides that. It isn't transparency but rather the corner pixels are missing in the Titlebar. But I could be wrong. Maybe it is transparent. I'll send you the Mahogany Theme to compare. Maybe some day I will finish the Mahogany and Hickory Window Themes. :-)

As far as how to produce Mouse Pointers on AROS I would think ZunePaint or LunaPaint would work. I haven't made Pointers before but it would depend if the Pointer Image is 24bit or 32bit and the image format. Is it PNG? Judging by the window theme layout which is PNG I would guess it is the same format - 32bit ? That should allow for transparency on 15/16bit, 24bit and 32bit screens. But it may not work on less.

As for the black areas of your Pointers that should be transparent if it expects 32bit images and it is only a 24bit image that would account for that happening. Try a 32bit image instead.

I'll look at some AROS Pointers to see if I can give a better answer. Maybe you can post an archive of a few of your good Pointers and the others with black or white background issues so I can compare?

My Pointers are PNG images with transparency, but even if I restore them from Zune Paint nothing changes.

But mind you, as I said on PC Native and on VMware VESA no problem the pointers are perfect and the transparency is perfect, the white shadow instead of transparency happens "only" if I use the native mode on VMVare.

Another strange thing, I can only get rid of the problem if I use Icon Editor OS3 version, but it doesn't work if I use Icon Editor on AROS, it's the same program.

I'll make an exhaustive video to show you what happens!

Send me an archive of a pointer with transparency issues on VMWare and one that you fixed with OS3 Icon Editor. I will find the difference.

I enclose a video to see the differences on WMware Native Vs VESA, I also enclose the two Images of the Pointers, one No Transparent and the other Fixed

AMIGASYSTEM

I watched the video about the non-transparent pointer. It was interesting and informative.

I tested the pointer images you provided. It seems to be a PNG file format issue. I will explain more in a bit. I converted them using Datatypes and re-saved as PNG images.

I will post the files in about an hour.

AMIGASYSTEM

Here are the files. I used my PixieView Picture Viewer to open both test images Azure-Not Transparent.png and Azure-Ok Transparent.png then I used from the Picture menu Save Picture which uses picture Datatypes to save as PNG.

For both images this puts them through the Datatypes system and it removes any extra chunks and corrects any errors in the files.

Azure-Not Transparent.png originally had 619 bytes. After saving it with PixieView it had 710 bytes. Azure-Ok Transparent.png had 672 bytes and after saving it still had 672 bytes.

The IHDR data in both files were identical. They are both 32bit PNG images. The Non-transparent image (619 bytes) had an extra pHYs chunk. The images saved from it had only the IHDR, IDAT & IEND chunks. It seems the Transparent image (672 bytes) was previously saved using picture Datatypes or PNG library with the same compression scheme and degree of compression. The before and after files are the same.

I also included PixieView for AROS x86 so you can try it for yourself to open and save problem pointer images. Again, open the pointer file then use the Picture Menu, Save Picture to save a new PNG file. Have fun!

Where did the Azure-Not Transparent.png image come from? Which application saved the file?

Thanks miker, this is getting more and more interesting!
Even the Pointer saved by your pixieview program shows the white shadow when used with VMware "Native Mode".

I create my Pointers with PhotoFiltre, but I have the same result if I create them in PhotoShop and other PC Paints

And also the Pointer saved with pixieview I can remove the white shadow with Icon Editor on my AfA One (only on OS3), basically IconEditor allows me to save a part of the image see screenshot !

The curiosity remains to find out with which programme they create the Pointers on the AROS Build!

I like your pixieview, I will insert it on AROS One if you like!

Probably VMware's Native mode has some graphical problems, but it helped me to discover the difference between my Pointers and those of the Builder

I have not tested Native mode on VirtualBox !

On Native PC no problem, Azure-No trasparent.png works perfectly, no White shadows, and no user has ever complained as all AROS One Pointers were like that (Now all corrected on AROS One 2.7)

AMIGASYSTEM

Maybe there is a glitch in the VMWare Graphics display driver. But you do more testing if that helps. I wonder what Icon Editor for OS3 does to the PNG images that makes them correct?

Feel free to include PixieView if you want to. It's a simple and easy to use image viewer using picture Datatypes. Test out PixieView and let me know if there are any issues that I need to correct.

I should probably remove the first two messages when opening a picture file "success" & the picture dimensions. That could be annoying. It was just for testing purposes on my end. Let me make a few changes then I will post a new version of PixieView tomorrow that you can include.

AMIGASYSTEM

The PixieView program has been updated. But I need to add the HAM conversion code to save 24bit images as HAM6 or HAM8. The code is working I just need to add it to the new version.