Oh no! Where's the JavaScript?
Your Web browser does not have JavaScript enabled or does not support JavaScript. Please enable JavaScript on your Web browser to properly view this Web site, or upgrade to a Web browser that does support JavaScript.

Icon Tools

Last updated on 3 hours ago
M
miker1264Software Dev
Posted 3 days ago
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 13:16, 3 days ago
AMIGASYSTEMAMIGASYSTEMDistro Maintainer
Posted 3 days ago
Grazie miker, felice di risentirti Wink
M
miker1264Software Dev
Posted 1 day ago
As 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 15:05, 1 day ago
miker1264 attached the following image:
iconsplitter_68k_aros.jpg
M
miker1264Software Dev
Posted 1 day ago
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 13:33, 1 day ago
aha, Amiwell79, mmartinka, pixie
miker1264 attached the following image:
icon_maker2_10-14-24.png
M
miker1264Software Dev
Posted 6 hours ago
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 14:31, 6 hours ago
M
miker1264Software Dev
Posted 5 hours ago
Targa & 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 15:20, 5 hours ago
M
miker1264Software Dev
Posted 3 hours ago
After 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 :-)

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 19:36, 55 minutes ago
You can view all discussion threads in this forum.
You cannot start a new discussion thread in this forum.
You cannot reply in this discussion thread.
You cannot start on a poll in this forum.
You cannot upload attachments in this forum.
You can download attachments in this forum.
Moderator: Administrator
Users who participated in discussion: amigamia, deadwood, AMIGASYSTEM, pixie, Amiwell79, miker1264, mattson62
Sign In
Not a member yet? Click here to register.
Forgot Password?
Users Online Now
Guests Online 11
Members Online 0

Total Members: 259
Newest Member: jma
Member Polls
Should AROSWorld continue with AROS-Exec files (SMF based)?
Yes44 %
44% [12 Votes]
No26 %
26% [7 Votes]
Not sure30 %
30% [8 Votes]