AROS World Exec
Development => AROS Software Development => Topic started by: magorium on March 04, 2023, 12:45:24 PM
-
Taken from another thread in order to not pollute.
If you could write a program that splits PNG Icons or Classic Icons that would be great. If you could compile it for Windows & AROS that's even better. Many times on Windows I have to use the Hex Editor to do it.
@Miker1264:
A few questions:
1) what to do with the Ic0n chunk in png images. I have seen icons that even have a ic0n chunk in both images.
2) I assume that writing the individual images to a standard png image would be ok ?
3) what would be a preferred storage format for classic icons (you mentioned ilbm but what exact format) ?
4) would you also like to have support for newicons (e.g. tooltype icons)
5) in case yes to 4, what about the classic images ?
Anything else I forgot to yo might think is a good idea to add/implement, please share.
If there is any priority with regards to a particular icon storage format then please give a note on that. f.i. splitting png images is a matter of writing 2 or 3 lines of code (if I would to use a pre-existing png class loader) while others like newicons requires a bit more work (especially since i did not write a decompressor for that format yet).
Streamlining everything into a single command line program would add some additional time as well.
-
Taken from another thread in order to not pollute.
If you could write a program that splits PNG Icons or Classic Icons that would be great. If you could compile it for Windows & AROS that's even better. Many times on Windows I have to use the Hex Editor to do it.
@Miker1264:
A few questions:
1) what to do with the Ic0n chunk in png images. I have seen icons that even have a ic0n chunk in both images.
2) I assume that writing the individual images to a standard png image would be ok ?
3) what would be a preferred storage format for classic icons (you mentioned ilbm but what exact format) ?
4) would you also like to have support for newicons (e.g. tooltype icons)
5) in case yes to 4, what about the classic images ?
Anything else I forgot to yo might think is a good idea to add/implement, please share.
If there is any priority with regards to a particular icon storage format then please give a note on that. f.i. splitting png images is a matter of writing 2 or 3 lines of code (if I would to use a pre-existing png class loader) while others like newicons requires a bit more work (especially since i did not write a decompressor for that format yet).
Streamlining everything into a single command line program would add some additional time as well.
All good questions. :)
When splitting the PNG icon into images store as PNG images. I usually assign names such as Img1.png & Img2.png or some variation. But be prepared if there is only one image. Maybe offer an output path different than the input icon path. Or default could be if output not specified save images to same location as the original icon file. It's ok to leave the icOn chunk in the first PNG image. That contains the active icon attributes. I believe that icOn chunks in second images may be unused.
When saving Classic Icons we are only concerned with the IFF icon images. The IFF Data starts with "FORM....ICONFACE". Save the ILBM file as the actual number of bitplanes & index values & colormap from the icon data. Once you extract the images & colormap it's easy to write the ILBM. To make it easier ILBM can be uncompressed planar images & colormap. There is information for ILBM format if you search for IFF85.
Sometimes Classic Amiga Icons contain OS3.5 IFF Data & ARGB data chunks attached to the end of the file. See Icon Library for methods to read the zlib compressed 32bit data.
The easiest way to split PNG icons & retain the icOn chunk is to find the first 'IEND' & second 'IEND' if there is one then calculate filesize1 & filesize2 then read & write binary. You could use another method to get the images but the icOn chunk may be lost unless you locate it just before 'IEND' then save it to .bin file or store it some other way to later write to file. As far as classic Icons you can just read them sequentially. For AROS we can just use IconControl functions but for Windows or an OS other than AROS you need another method to read the icon data.
-
Thank you Miker1264 for your swift and elaborated reply.
I'll see what I can do :)
Do you have preference wrt win32/win64 ?
-
Thank you Miker1264 for your swift and elaborated reply.
I'll see what I can do :)
Do you have preference wrt win32/win64 ?
I use Windows 64bit. If that's what you meant to ask. I use it for editing code & painting icons.
-
Thank you miker.
I required the info so that I could build and setup the correct cross-compiler.
Attached you will find a zip file that contains v0.0.1 of the aiix command line tool.
It is a pre-test and i would kindly ask if you could test and report back if the executable works for you (I can't test myself) so that I know that I'm on the right track or if I need to make (other) adjustments to my setup. It should be a x86_64 bit executable.
The tool itself is able to extract png image(s) based on the provided filename (e.g. test.info) and will write out the png images (for now in the same directory the provided filename is/was given), and tell you if if it was able to detect them. If the provided filename does not contain any png images then the tool will inform about that as well.
The filenames of the saved images are based on the original provided filename with an additional (hexadecimal) offset where the png image was located in the original file, and with a png extension.
Hardly any error-checking is currently provided so please keep that in mind.
If at any point you would like to compile the tool yourself or have a look at the source then just send me a pm.
$ aiix test.info
Amiga Info Image eXtractor v0.0.1
located 2 png images in file "test.info"
extracted 2 image(s) to file
$ aiix aiix.pas
Amiga Info Image eXtractor v0.0.1
located 0 png images in file "aiix.pas"
extracted 0 image(s) to file
$ aiix
Amiga Info Image eXtractor v0.0.1
aiix <infofilename>
todo: write help
-
Which OS is your tool compiled for? I assume AROS x86-64.
Also if it is AROS then is it for ABIv11 x86-64 or ABIv1 ?
Is the syntax aiix [file.info]
-
Which OS is your tool compiled for? I assume AROS x86-64.
Apologies as it is my bad that i forgot to mention it. Windows 64 bit:)
Also if it is AROS then is it for ABIv11 x86-64 or ABIv1 ?
If it is to become for AROS then it would initially be AROS ABiv0. AROS ABIv1 is not supported by Free Pascal atm and my AROS ABiv11 merge requests for Free Pascal are still in limbo :-X
Is the syntax aiix [file.info]
Correct.
Sorry for the inconvenience.
Current possible targets that are relevant and I am able to compile for are: amiga-m68k, ppc-morphos, ppc-AmigaOS4, win 32/64 bit, linux 32/64 bit. Besides some other exotic targets that I currently have setup some others require for me to setup a cross-compiler. AROS target is a work in progress (but will be there eventually)
-
magorium, I tried AIXX on my Win7 64Bit on my DualPNG Icons and it worked, the two images were extracted correctly, see screenshot.
I will try if it works with OS4 and OS 3.9 Glow icons, I will also try with a BAT file, so I can extract the images on many icons at once!
-
Thank you for testing and reporting back AMIGASYSTEM
If you have any suggestions to improve the tool (besides the suggestions already pointed out by user Miker) then feel free to suggest/ask.
The current executable is/was just a simple test to see if the executable works as intended.
Next on my list is support for the glowicons (as they seem the easiest to extract the images from) and then newicons. Support for (classic) bitmap images will probably follow after that.
-
I tried extracting images from many icons at once, but with the parameter
aiix *.info the files are not found again, maybe it would be needed a little GUI
-
@magorium
The aiix icon tool works on Windows 7 Pro 64bit.
It split the icon into two images with correct offsets.
You mentioned your build system. It would be great if you could also compile it for AROS ABOv0 for splitting icons.
I'm currently refreshing my ABIv11 sources then I have to rebuild the tool chain. Last time it took 3 hours. :o
-
@AMIGASYSTEM:
you are going waaay too fast for me dear padawan :)
This version is not even close to an alpha release, let alone that it supports file-pattern matching.
There is no need for a GUI (unless you really want to). I have no idea how to do it in a Windows shell/terminal but in Linux I can do something like:
for file in *.info; do ./aiix "$file"; done;
I know there is a Windows shell/bat file equivalent but I simply do not remember how that used to work in Windows.
On a completely other note. I did not test it but I came across a tool that seems to be able to extract image(s) from Amiga icons (amongst other files). It is called deark and can be found here (https://github.com/jsummers/deark). Perhaps that is able to fulfill some (current) needs.
-
@AMIGASYSTEM:
you are going waaay too fast for me dear padawan :)
This version is not even close to an alpha release, let alone that it supports file-pattern matching.
There is no need for a GUI (unless you really want to). I have no idea how to do it in a Windows shell/terminal but in Linux I can do something like:
for file in *.info; do ./aiix "$file"; done;
I know there is a Windows shell/bat file equivalent but I simply do not remember how that used to work in Windows.
On a completely other note. I did not test it but I came across a tool that seems to be able to extract image(s) from Amiga icons (amongst other files). It is called deark and can be found here (https://github.com/jsummers/deark). Perhaps that is able to fulfill some (current) needs.
For Windows cmd it should be aiix *.info
Then it should split every .info file in the directory into images in batch mode.
AMIGASYSTEM does that to me too! He puts the cart in front of the horse! Whoa!! We aren't there yet. ;D
-
Actually that is the command BAT, I use it with "XDMS" for multiple conversion of .DMS files to .ADF, and then after the conversion the deletion of the source files
The command I use is this:
attrib -r -s -h *.* /s
XDMS U *.DMS
Del *.DMS
-
The aiix icon tool works on Windows 7 Pro 64bit.
It split the icon into two images with correct offsets.
Thank you for testing and reporting back :appreciated:
You mentioned your build system. It would be great if you could also compile it for AROS ABOv0 for splitting icons.
Yeah, will do that.
I'm working at a newly setup machine and haven't gotten around setting up Free Pascal completely yet. The binutils for AROS are (as always) a crime to create (I only need the standalone binutils and that requires a bit of work when getting the correct patches from the AROS repo's, apply and build the binutils).
I'm currently refreshing my ABIv11 sources then I have to rebuild the tool chain. Last time it took 3 hours. :o
Yes, I know :'(
I am blessed with Free Pascal in that I am able to create the host, 8 cross-compilers with required binutils in about half an hour. Only AROS keeps being a PITA (actually the gnu binutils)
-
For Windows cmd it should be aiix *.info
Does that not /only/ expand the pattern to all files which are then feeded once as several arguments to the command ?
AMIGASYSTEM does that to me too! He puts the cart in front of the horse! Whoa!! We aren't there yet. ;D
LOL. Ah well, impatience :)
Steady going forward will get us there in the end as well :old-grey-wisdom: :coughs: ;D
-
@AMIGASYSTEM:
you are going waaay too fast for me dear padawan :)
padawan to me that I am 69 is a compliment ;D
On AROSx 86 Aixx you could use it on Dopus4, in this case you will be able to extract imagesgin to many icons at the same time ;)
-
Actually that is the command BAT, I use it with "XDMS" for multiple conversion of .DMS files to .ADF, and then after the conversion the deletion of the source files
The command I use is this:
The command you showed works because XDMS accept multiple files as arguments.
My tool currently does not do that (and it probably will not either because in doing so it causes some incompatibilities with future/planned command line argument options).
So, you rather need to take that part away from the tool and let the shell do all the hard work.
Windows can do it as well but I simply cannot test as I do not have any Windows nearby anymore.
So the first hit i got was this (https://superuser.com/questions/460598/is-there-any-way-to-get-the-windows-cmd-shell-to-expand-wildcard-paths). but that led me to nowhere (although there are some working solutions presented there). Thus I ended up here (https://stackoverflow.com/questions/5382957/for-loop-recursively-through-folder-in-windows-cmd-for-file-rename)
So.. that leads me to believe something like the following is able to work for Windows as well:
for /F %i in (*.info) DO aiix %i
-
Actually that is the command BAT, I use it with "XDMS" for multiple conversion of .DMS files to .ADF, and then after the conversion the deletion of the source files
The command I use is this:
The command you showed works because XDMS accept multiple files as arguments.
My tool currently does not do that (and it probably will not either because in doing so it causes some incompatibilities with future/planned command line argument options).
So, you rather need to take that part away from the tool and let the shell do all the hard work.
Windows can do it as well but I simply cannot test as I do not have any Windows nearby anymore.
So the first hit i got was this (https://superuser.com/questions/460598/is-there-any-way-to-get-the-windows-cmd-shell-to-expand-wildcard-paths). but that led me to nowhere (although there are some working solutions presented there). Thus I ended up here (https://stackoverflow.com/questions/5382957/for-loop-recursively-through-folder-in-windows-cmd-for-file-rename)
So.. that leads me to believe something like the following is able to work for Windows as well:
for /F %i in (*.info) DO aiix %i
it should be ok to not include batch mode. Splitting single icons is good.
On another note. Ubuntu Linux was giving me such problems while trying to refresh my AROS sources. It kept complaining about no wifi connection.
But I found that Ubuntu for some reason doesn't like Centrino Wireless so I shut off wireless and installed a usb wifi adapter and now it works. Linux. Ugh!
Now I can refresh and rebuild the toolchain. :)
-
it should be ok to not include batch mode. Splitting single icons is good.
Not saying I will not eventually add pattern matching detection. It is simply atm just not a priority as long as the tool is not able to extract anything else besides png images. I want to focus on that first. Besides that, you can work around the lack of batch processing by using a shell workaround.
glad to hear you got your issues wrt ubuntu sorted out. I'm currently on a testing release so unfortunately known too well how it feels when things start working or breaking apart (again) *sight*. Half the hardware in this machine is still not (properly) supported.
-
@miker:
with regards to Amiga OS3.5 icons (as you name them, I call them glowicons).
Those files consist of a classic info disk structure (might or might not contain a newicon structure in the tool-types), followed by an IFF icon structure (the actual glowicon bits).
A GlowIcon is thus an IFF structure with a ICON identifier which can contain the (newly added) chunks FACE and IMAG. The file may or may not contain multiple IMAG chunks (though a minimal of 1 and maximum of 2 makes sense in this context).
The question: do you expect these IMAG chunks to be saved in a individual manner ? Is there any software out there that is able to manipulate (read: extract/ combine) the images contained in such an IFF file and perhaps more importantly if the IMAG chunks would to be saved individually how would you want to combine them again ? atm I am not 100% sure (yet) i can save them without loosing any (important) information that gets lost (icon wise, not graphical data wise).
E.g. can you read/manipulate a IFF ICON file with using existing library functionality (or your own created functionality) ?
Reason I ask is a simple one: Although I understand the glowicon file format structure and internals of the IFF storage format I seem unable to find any information with regards to details on for example the compatibility of an IMAG chunk wrt the ILBM format, e.g. It might be that an IFF ICON is able/allowed to contain bit-resolutions that are not (by default) supported by the ILBM format (I currently do not contain the knowledge but do remember something with AROS and ILBM wrt higher bitdepth resolutions not being 100% correct supported: I do not know if that still is an issue)
-
@magorium
I'm rebuilding my cross-compiler tool chain. I will get back to you with the needed information about Glow Icons.
-
Thank you for letting me know. There is no need to rush there miker1264. Have fun building (and testing ofc) ! :)
-
@magorium
"with regards to Amiga OS3.5 icons (as you name them, I call them glowicons)."
They are Classic Amiga Icons with the OS3.5 Extension for IFF data (Glow Icons).
"Those files consist of a classic info disk structure (might or might not contain a newicon structure in the tool-types), followed by an IFF icon structure (the actual glowicon bits)."
Yes. That is correct. See: http://www.evillabs.net/index.php/Amiga_Icon_Formats
"A GlowIcon is thus an IFF structure with a ICON identifier which can contain the (newly added) chunks FACE and IMAG. The file may or may not contain multiple IMAG chunks (though a minimal of 1 and maximum of 2 makes sense in this context)."
The IFF data should contain two IMAG chunks for images but it could contain one or none. If it contains only one image we only export one image. If it contain no IMAG chunks for images but it contains one or two ARGB chunks attached to the end of the IFF data then it's an OS4 icon which is a Classic Amiga Icons with the OS3.5 Extension without IMAG but ARGB instead. If it contains one or two IMAG & one or two ARGB chunks then it is an AROS ARGB Icon format. I have two functions called Get_IFFOffset & Get_IFFType to deal with these icons styles. The first function will read through all the classic icon data starting with file signature then the diskobject data till it gets to the beginning of the IFF data that starts with 'FORM' then it returns that offset. The second functions uses IFFParse Library starting with that IFF offset to parse the IFF data looking for the IMAG & ARGB chunkID's. If they are found see above for the explanation of determining the icon style based on the image data present in the IFF data. As far as reading the IMAG images & converting that information into planar data to write to an ILBM along with the colormap. Icon Library uses IconControl to get the image data & the colormap data. I don't have a native method yet to read the IMAG & colormap data directly but I'm working on native methods to read classic icons to save the images.
"The question: do you expect these IMAG chunks to be saved in a individual manner ? Is there any software out there that is able to manipulate (read: extract/ combine) the images contained in such an IFF file and perhaps more importantly if the IMAG chunks would to be saved individually how would you want to combine them again ? atm I am not 100% sure (yet) i can save them without loosing any (important) information that gets lost (icon wise, not graphical data wise)."
The IMAG chunks & colormap data for each image will be exported to ILBM separately with one image per file. Once the ILBM images are exported the icon attributes that are stored in the icon file are no longer accesssible. As far as we are concerned to re-combine them requires rebuilding the classic icon data starting with the diskobject data, etc. There is a sample of that in ilbmtoicon to Save Classic Icon. In order to save the ILBM images to files there is a Save_Bitmap function that I put in INFO data that will allow saving ILBM images.
"E.g. can you read/manipulate a IFF ICON file with using existing library functionality (or your own created functionality) ?"
I have been using library functions for AROS. But in order to read the classic icons on any other operating system we will need to do it in a more generic way. We have to access the data directly by reading the offsets and the cunkID's & chunk data contained in the icon file. Reading the IFF images directly should be straightforward. I will provide program samples of all the obove as far as getting the correct offsets, reading the IMAG chunks & saving ILBM's. For simplicity I will just post a zip archive with the pertinent information for reading icons.
"Reason I ask is a simple one: Although I understand the glowicon file format structure and internals of the IFF storage format I seem unable to find any information with regards to details on for example the compatibility of an IMAG chunk wrt the ILBM format, e.g. It might be that an IFF ICON is able/allowed to contain bit-resolutions that are not (by default) supported by the ILBM format (I currently do not contain the knowledge but do remember something with AROS and ILBM wrt higher bitdepth resolutions not being 100% correct supported: I do not know if that still is an issue)"
If it is a Glow Icon with IFF image data & it is more than 8 bitplanes of image data then that represents an error situation. It must be 8 bitplanes or below. The ARGB data is 32bit data.
-
@magorium
I hope that wasn't too much information. ;)
I've made some progress in reading Classic Amiga Icons aka Glow Icons.
My test program uses a function called Get_IFFOffset to read through all the icon data to get the beginning offset of the IFF Data. It returns that offset to the calling function.
Next the iffoffset is sent to another function ReadIcon_IFF that uses the offset in the file to start reading the IFF Data. First we verify the IFF file id 'FORM' then the form size followed by the IFF type id 'ICON' then the FACE chunk. The FACE chunk contains, among other data, the width & height.
So far I can read all the way to the FACE chunk. Immediately following the FACE chunk should be the first IMAG chunk. I'm working on native methods to export the image data.
The image data itself can be compressed or uncompressed. The palette data follows the image data. It can also be compressed or uncompressed. So we have to look at imgfmt & palfmt in the IMAG chunk header. If compressed it uses RLE just like ILBM which makes it easier. We only need to process the palette data but it may already be uncompressed.
The image data is stored as planar data. So we look at imgfmt to check compression. Use width, height,depth & compression values for the BMHD. You can write a CMAP byte array for the palette then write a byte array for the image data directly to an ILBM BODY chunk. That allows saving ILBM files.
I'm not using any libraries just pure C code so it's portable.
-
I hope that wasn't too much information. ;)
Thank you for the elaborate information you posted, and no it was not too much information :)
I had planned to respond to your post with: try the newly attached executable but alas my schedule went a bit different then planned so i haven't even started to use the information you provided.
I've made some progress in reading Classic Amiga Icons aka Glow Icons.
Sorry for cutting it short but thank you for the good read on your endeavors. congratz at your progress. All my code is intended to be platform independent as well. I am aware this is counterproductive when it comes to developing AROS/amiga related programs but I really want to have this fileformat figured out completely (and can not do so properly with relying on libraries and/or OS code).
-
No worries.
I can provide a working prototype in a day or two that exports glow icon images using native methods only, no libraries & no OS functions. It's written in C code though. I needed it for one of my small icon tools I'm developing.
It also helps to use native methods only so that it can more easily be compiled for Amiga OS 3.x and Amiga OS 4.
I wrote the original Save ILBM functions for ILBM datatype & Picture datatype. So I'm very familiar with saving ILBM.
-
My first attempt to use native methods to read an Amiga Glow Icon and write an ILBM image file failed. The file size was zero.
But I can however successfully memcpy the byte array and write the entire IMAG chunk to a bin file. So I will try again. Maybe I will try to construct a new byte array with all the ILBM data and write that directly to file.
As normally happens with programming it hardly ever compiles correctly as written or ever works the first time. If it does then you're a guru. ;)
-
If my C code is not faulty maybe this will work.
To test the offsets I will try to manually build an ILBM with a hex Editor using the IMAG chunk data. That should be fun. 😊
-
I'm currently working at a ILBM class in order to read/write ILBM files.
I have some old code that is capable of reading/writing ILBM files but I did not encapsulate that into a class yet (which is what I am currently working on).
But... I hit a it of a snag as I just discovered the 48/64 bit ILBM extensions. I did not account for that in my old code so I have to add support for that as well (and requires a rewrite of the ILBM class I was/am working on).
Ofc not important for the icon image extraction but something I just want to do (as well).
-
@magorium
Thank you for the update. I have made some progress with my AROS test program that contains icon read/write functions that I need for IconPress and another icon app.
I will provide my test program in C code. It may help you to write your Pascal icon & ILBM handling code. So far I can read the IFF header data (FORM & ICON) & can find the FACE chunk & IMAG chunks. I can access all the data in the IMAG chunks & I can write ILBM files that are "almost" correct. I'm writing the valid IFF header for the files (FORM & ILBM) & the BMHD is correct. I can also write the correct color palette. But the image data is somehow incorrect.
I'll put the test program and a lengthy text document in an archive for you. In the text file I will provide all the technical information about ILBM files and Glow Icon files that I've learned over the past few years. :)
-
As you can see in the attached screenshot I can successfully access the data from each IMAG chunk which also means I can read the icon file to get to the IFF data.
The datatypes system recognizes the output files as valid ILBM picture files. But that's because the IFF header data and the BMHD are correct. The CMAP (colormap chunk) is also correct. I verified in a hex Editor. But the image data is wacky! The datatype tried to read it but the image is scattered and fuzzy. I assumed the binary data in the icon for the image was compressed planar data so I just copied it to the ILBM. Maybe that's incorrect. It needs processing.
In my experience dealing with saving ILBM files and HAM6/8 conversion there are a few reasons the image data is skewed. Either the colormap is wacky which it isn't or the image data is in the wrong format. For example if comp in BMHD is set to zero but we are trying to display RLE data the datatype gets confused so the image is scattered. Or if comp is one (compressed) but the data is actually uncompressed it's the same result. There is one other possible reason if the compression values are actually correct.
In the documentation for the palette the palfmt (compression) is usually always 0 and each byte represents a pixel. So it's 8 bits per pixel. So we can easily just copy the colormap byte array to the ILBM. But the information is vague concerning the image data. It says it can be compressed or uncompressed (imgfmt = 0 or 1). But it doesn't specify the underlying pixel format. Is it planar arranged in the correct number of bitplanes. Or is it chunky?
I suspect the image data is the same as the palette. One byte represents one pixel (8 bitplanes). But it is also RLE compressed. That explains why the datatype displays it as scatted and fuzzy. The BMHD says depth = 4 but it has 8 bitplanes or it's chunky not planar. So it needs conversion.
@magorium
If you discover the mysterious format of the image data in the IMAG chunk please let me know. I'm not sure about it.
-
Ah. I made a possible discovery.
In ilbmtoicon there is a clue in write icon in the function writeimagchunk.
when it gets to the point where it compresses the image data it does this:
gfx = createrle (img->bmh.bmh_Depth, &gfxpacked, &gfxsize, img->bmh.bmh_Width * img->bmh.bmh_Height, img->chunkybuffer);
It's an rle compressed chunky buffer most likely with one byte for each pixel (8bits per pixel). That's why my image was scattered and fuzzy! I was trying to display chunky as planar but it wasn't planar data.
That's easy to fix. Use unpackbyterun to decode RLE them convert chunky to planar with the correct number of planes.
Decode35 in icon library likely does both at the same time but I'll do it in two parts to verify my data. After the rle is unpacked I have a chunky to planar that reduces bitplanes that I used with HAM conversion. I will try to use that. :)
Then if all goes well the uncompressed planar data can be written to the ILBM file.
-
I haven't decided what the format is for the image data in the IMAG chunk. It can be RLE compressed but what are the data underneath the compression? Chunky bytes or planar data?
-
@miker:
I have the same question but I assume (might be completely wrong) that it is stored in the same way as the non 24/32 bit formats, except that the number of bytes per pixel is not a single byte anymore (but 3 or 4). Or in short: I assume in planar mode and without a palette but using true RGB values.
I was unable to find official documentation yet. But I have to search a little deeper/harder in the OS4 SDK. My initial searches did not reveal anything related to the IMAG chunk.
What do the existing 24/32 bit glow icons use ? or are you not able to determine that just yet ?
-
The format for the existing 32bit Glow Icons is easier. Immediately following the IFF chunks there are two ARGB chunks with zlib compressed 32bit pixel data.
-
aaargh. My bad.
That is what you get when reading about picture storage formats when the topic is about icon storage :-[
The best documentation I have found so far seems to be that of evillabs but imho there is still some ambiguity how exactly things are stored. e.g. i have a difficult time interpretating what it actually means. In that regards I should perhaps better focus first on the imag chunk decryption to see what is about exactly :)
Ofc i can take a peek at an existing library and/or code that loads these icons but I would like to figure it out myself first before looking at an actual implementation from someone else.
-
aaargh. My bad.
That is what you get when reading about picture storage formats when the topic is about icon storage :-[
The best documentation I have found so far seems to be that of evillabs but imho there is still some ambiguity how exactly things are stored. e.g. i have a difficult time interpretating what it actually means. In that regards I should perhaps better focus first on the imag chunk decryption to see what is about exactly :)
Ofc i can take a peek at an existing library and/or code that loads these icons but I would like to figure it out myself first before looking at an actual implementation from someone else.
I have some information that may help. I can post it tomorrow.
I also found this when looking at the Amiga Icon Converter that is written in Java.
But the note was interesting concerning Reading IFF Icon Data.
// note: this is BIT aligned, not byte aligned ...
// -> RLE control chars are 8 bits, but the data elements are n bits, determined by depth
Which may or may not indicate that the image data is RLE compressed but the data itself is planar by depth.
To test the image data I borrowed an image decoder from another program. It reads the icon image data. It's very similar to the decoder as used in icon library to read OS35 icons. I finally got the decoder to output data for my test program but it only works at full size ,(width * height).
Curiously I couldn't figure out why my ILBM images were still scattered and fuzzy. The images were scrambled. But then I realized that I may be expecting the wrong out put format. I will do some tests to verify.
When all else fails I will put a --v switch in my test program to optionally view the images so I can draw them on the screen. If that works then the decoder output format is 8bit chunky bytes not planar data as I had expected.
For example the decoder was using a strange formula if the image data in the IMAG chunk is uncompressed the output size is (imgsize * 8/depth) which if the image has 4 bitplanes is (imgsize * 8/4). It's twice as large. That's very puzzling!
-
Just a quick note with respect to the latter remark concerning uncompressed data.
The evillabs entry has a clue on that. No matter the bitplane depth the data for a pixel is stored in a byte. The upper (or lower depending on how you look at it) bits are
not used and need to be ignored.
That is what confuses me (at least initially) as the text on evillabs wrt RLE compressed data does mention the exact bitdepth. I just haven't come to those parts yet and have not investigated it. I'll come to it :)
-
Just a quick note with respect to the latter remark concerning uncompressed data.
The evillabs entry has a clue on that. No matter the bitplane depth the data for a pixel is stored in a byte. The upper (or lower depending on how you look at it) bits are
not used and need to be ignored.
That is what confuses me (at least initially) as the text on evillabs wrt RLE compressed data does mention the exact bitdepth. I just haven't come to those parts yet and have not investigated it. I'll come to it :)
I do remember seeing that also. It makes sense that the planar data is stored in bytes. That's how the planar bitmap in picture datatypes store planar data.
No matter the bitdepth (8bitplanes or below) the planar bitmap always has 8bitplanes. Maybe not all of them have planar data though.
The Image Decoder seems to confirm that at least it is performing bit masking & it is making bytes from the bits. Maybe it converts planar data to chunky bytes?
The good thing about all this is that my IconEdit program which uses a variation of the Icon Image Decoder works on AROS One x86.
It kept crashing on IcarosDesktop. I thought it was broken! I will use it for testing now to get it to save ILBM images.
This is a good place to find ILBM information:
https://www.fileformat.info/format/iff/egff.htm
-
I took a while to write the SaveImage function for IconEdit but it is actually saving an ILBM picture file!
But it contains uncompressed chunky bytes instead of planar data so it isn't quite right. It's a good start though.
It seems that I'm just missing a chunky to planar conversion algorithm to make it all work correctly.
Thank goodness for Dopus4 & ZuneHexEditor! Nice programming tools.
-
@magorium
Here is some imformation that may be helpful for you to write your Pascal Icon Splitter.
It also contains the SaveImage function that contains native methods to save an ILBM picture file.
I included the various functions and sample code for the Icon Image Decoders and some other information.
Also include in the archive you will find my SaveHAMPic code that converts 24bit image data to HAM6 or HAM8. :)
At the end of DO_HAM_BODY is my custom Chunky to Planar covversion routine used with SaveHAMPic.
-
I'm pleased that this has happened the way it did. I'm not entirely sure that the image data in the icon IMAG chunk is well suited to be copied directly to an ILBM.
Even if it is planar data or bits of planar data contained in bytes with or without RLE compression we can't just copy a byte array from the icon to an ILBM picture file.
It's good that the Image Decoder used masking and bit shifting to convert the data directly to chunky bytes (8bits per index value).
The ILBM file format requires that each scanline of bytes must be modulus 16 (evenly divisible) so that it ends on an even bitplane. We can't have partial bitplanes!
So at the end of each chunky scanline padding bytes (empty bytes or junk bytes) are added as needed. For example 46 is not evenly divisible by 16. It needs to be 48 so we add two bytes.
After the padding bytes are added to each scanline then the chunky data is converted to the proper number of bitplanes. We process each scanline independently then write to file.
But first I had to be 100% sure I was looking at 8bit chunky bytes for the index values that is the output of the Image Decoder. So I used a png screenshot, and a paint program to identify each rgb pixel.
I matched each pixel (it's only 46x46 pixels) to colors in the colormap, verifying the colormap index making sure it matched the index values in the image data. It all matches perfectly!
Now we just have to implement chunky to planar conversion and bitplane reduction which has already been done.
-
Maybe I have had too much caffeine! But the mystery of the image data format is beginning to reveal itself.
What does the mystery formula (numimg * 8/depth) mean?
Here is my theory:
For uncompressed data numimg refers to the total number of storage bytes present in the data. In that case if the depth is 5 bitplanes for example (numimg * 8/5) is the "planar capacity" or "c.apacity o.f p.lanar' (cop). It's the total size of the planar bits stored inside the bytes. You would need this number if you wanted to extract planar by depth.
For RLE compressed data numimg is the size of compressed data. The Image Decoder gives us a clue here. For compressed data the total uncompressed size is the total "entries" (each entry is index or pixel) is (width * height). I don't have a Glow Icon with uncompressed image data to test because 99% of the time it will be compressed. On Amiga computers size is important, the smaller the better. But in theory for uncompressed data numimg should equal (width * height).
So the image data in the IMAG chunk is multi-faceted. It is arranged by bitplanes in bytes. If you want planar data it is byte aligned by depth. Simply extract the correct number of bits from each byte and copy them to a planar bitbuffer. If you want the bytes arranged by bitplanes simply copy the storage bytes to your new byte buffer. If the bytes are in bitplanes if you think about it when you inflate for example 5 bitplanes of data to 8 bitplanes then three planes contain zeros. In each storage byte only 5 bits are valid and three are zeros. Since I suspect they are by bitplane it is already 8 bitplanes. Just copy the storage bytes to get 8 bitplanes of planar data. To get chunky bytes of index values the Image Decoder must convert 8 bit planar data to 8bit chunky bytes by masking and bit shifting.
If the storage bytes are not arranged by bitplanes then they are just 8bit chunky bytes that represent the index values.
-
@magorium
This is the chunky to planar conversion with bitplane reduction.
-
Hi Miker,
Thank you for your progress reports and attachments.
You are waay to fast for me ;D
I was still struggling with some modulo that decided to waste my time (you know when staring at your code and simply do not see it while it is right in front of you ?).
I thought I was going insane so questioned everything, even about my own internal used storage format. Eventually used raw data to check if everything was allright by using this very nice site (https://rawpixels.net/)
First picture is how it was, second how it should be :P
Now, i'm going to take a small break and after that going to read your endevours. I was already checking up on some documentation but the sad thing is that the only thing I was able to find where posts from people more experienced (such as peterK) that don't have official documentation either.
-
I certainly know that feeling when I'm looking at the code repeatedly and it's not working. But there's an easy solution. The only thing to do is to set it aside till the next day. The solution is usually quite simple. It was there all the time.
rawpixels.net Oh, that's Lena. :)
When scanlines should be modulus and they aren't it can cause problems such as with ILBM which must be modulus 16. I discovered that the hard way.
I'm still not 100% sure about the image data format for the IMAG chunk but using an Image Decoder similar to Decode35 that returns chunky bytes for the index values is better because it gives more control for adding padding bytes for each scanline. Then we just use chunky to planar conversion with bitplane reduction for each scanline. Then copy the planar scanlines in sequence to the output buffer. The image data is only 2 or 3kb in size so just write it to the ILBM all at once after converting chunky to planar.
It's interesting that the key functions that do the most are the smallest as far as lines of code. They are less than 30 lines each for Decode35, MakePlanar & ChunkyBytesToBitplanes. I don't have a working sample yet but the pieces are all there to read an icon & save images.
As far as documentation for Glow Icons and ILBM file format there isn't much readily available. PeterK provided some information about the ARGB data chunks. I think I provided that in my zip archives that I posted here for you.
I had to learn many things about ILBM on my own with trial & error methods. The same is true for IFF Icon Data & Classic Icons. The standard documentation provides a good framework but for specific information we just need to have a good understanding of the file format.
Once I learn more about the format of the image data in the IMAG chunk of the IFF data I may write an addendum to Amiga Icon Format explaining the structure of the IMAG chunk and the ARGB chunk for others to read about.
Everyone should have access to this information. I should also put together a text document or PDF about the ILBM file format and how to write or modify picture datatypes.
-
@magorium
Amiga Icon Converter on GitHub is written in Java to display Amiga Icon Images in a browser window.
The file icon.js contains lots of information about the structure of the IMAG chunk and the ARGB chunk. But I don't read Java very well.
Interestingly the way it reads the image data is nearly identical to the AROS IMAG Image Decoder called Decode35. I have attached readIFFICON.txt source from icon.js so you can take a look. It provides insight into exactly what Decode35 in AROS Icon Library does and it gives clues about the image data format in the IMAG chunk.
Have a look also at convertRLE in ilbmtoicon. It converts chunky bytes into image data to write to an IMAG chunk.
-
Hmmm...almost successfully saved IlBM files. ;)
The two small images are the icon images saved as ILBM files.
The images are skewed because although the planar linesize is 48 I only wrote 46 bytes per line.
So the two padding bytes at the end of each planar scanline are missing.
But my two new functions MakePlanar & ConvertBytesToBitplanes are working to convert chunky to planar!
-
SaveImage is now working! ;)
I'm reading an Amiga Glow Icon to get the offset to the IFF data. Then I read the IFF data to get to the IMAG chunk.
I use an Image Decoder to read the image data that then outputs chunky bytes for the index values of the colormap.
I then have to add padding bytes to the end of each scanline. In the case of an icon image 46x46 it should be an aligned width of 48 so I add two bytes.
The last step is to convert each chunky scanline into planar data to write to the ILBM file for the height of the image.
P.S. - This a prototype of the entire process. I'm saving 8bitplanes at the moment to test the chunky to planar conversion. Next I will used the real depth which is 4 & 5 bitplanes respectively.
-
Nice, great interesting tool that was missing on AROS !
-
Nice, great interesting tool that was missing on AROS !
This is intended to be a method to split an Amiga Glow Icon into two ILBM images using only native methods. No libraries and no OS functions. We read the binary from the files directly and copy data and mask and bit shift as needed.
I'm working on a prototype for AROS.
magorium is working on a portable version for Windows x64.
It's looks very promising so far but there's more to do. :)
-
Icons with ILBM images are great for OS3 PAL systems, Icons with PNG Images are better suited for RTG systems.
Also, creating Icons with ILBM Images on Windows is complicated, most Windows Graphics Editors do not use this format
-
Icons with ILBM images are great for OS3 PAL systems, Icons with PNG Images are better suited for RTG systems.
Also, creating Icons with ILBM Images on Windows is complicated, most Windows Graphics Editors do not use this format
I don't think the idea is to create icons on Windows but there are some nice paint programs that can be used.
Mostly the purpose of the icon splitter is to split PNG icons without having to do it manually. Being able to split Glow Icons is simply a bonus. We wanted to see if it can be done.
-
Yes it is useful, it happens to me that sometimes I accidentally delete some Icon images, and I use with Icon Editor to split my Icons and take the 2 images.
Regarding Windows, to ceare and shape the images I use Photofiltre free version, very simple child proof, very convenient and fast in working with transparencies, then I create the Icons with OS3 version of IconEditor with my AfA One, which is very fast, and most of all convenient because of the possibility to have the thumbnails "the preview" of the PNG images.
-
Hello miker,
I have taken a (quick) look at your attachments. Thank you for those.
fwiw: I have put the ILBM writer on the back-burner for the moment (as long as not meddling with ham, ehb, pbm, acbm etc then implementing it should not be too hard to do). I now have working code for handling FACE/ARGB. Currently working at IMAG.
I'm still attempting to write my code based on my own interpretation but atm seem a bit stuck. As you have already mentioned the RLE encoding seems a bit different than you average run length encoding (that is used by ILBM).
edit: problem seems "unstucked" no to check if my rle decoding works. As always it is the one typing things on the keyboard that is at fault :P
-
magorium is working on a portable version for Windows x64.
Actually for every target that is supported by Free Pascal but atm I have only the Win64, Linux64, MorphOS, AmigaOS4 and classic AmigaOS68k (cross) compilers installed.
@AMIGASYSTEM:
We are working on tools that are able to aid your graphical adventures on/for whatever platform you prefer. There are not a lot of Linux/Windows tools that allow you to read/display and split images found in Amiga .info files.
The extraction of the images inside icons is especially useful if you want to apply a graphical effect to one or both of the images, and our tools can help automated some of that process.
-
@magorium
The key to understand the image data in the IMAG chunk can be found in ReadIFFIcon in icons.js of Amiga Icon Converter on GitHub. The notes & code explain it all. :)
My prototype code is working to export ILBM images. Now I have to transfer the main functions to another more streamlined program (I have to re-write everything) .
No worries on the timeline. The aiix tool works!
-
@miker:
Your explanation and example code for rle decoding saved the day for the last few (literal) bits.
Thank you very much for that miker1264.
IMAG chunks are now working for me as well, see attachment.
Need a lot of code cleanup, comments, abstraction and a complete rewrite to be able to add it to aiix.
output of test_icon program:
./test_icon icons/a.info
formtype = 49434F4E
reading chunk FACE
fc.Width = 46
fc.Height = 46
fc.Flags = 0 ()
fc.Aspect = 42
fc.MaxPaletteBytes = 18766
reading chunk IMAG (774 bytes)
imag.Transparent = 0
imag.NumColors = 21
imag.Flags = 3 (has_transparent_color has_palette )
imag.ImgFormat = 1 (rle compressed)
imag.PalFormat = 1 (rle compressed)
imag.Depth = 5
imag.ImgSize = 707
imag.PalSize = 57
image and palette size fits in chunk
read 707 bytes from stream into compressed buffer (707 bytes)
read 57 bytes from stream into compressed buffer (57 bytes)
here we should decompress the palette
decoding palette succeeded
here we should write the pixels into a image file and save it
Pixelbuffer contains 2116 bytes
Palette contains 63 bytes
out of bound = 0
inbound = 2116
reading chunk IMAG (1051 bytes)
imag.Transparent = 0
imag.NumColors = 0
imag.Flags = 1 (has_transparent_color )
imag.ImgFormat = 1 (rle compressed)
imag.PalFormat = 0 (uncompressed)
imag.Depth = 5
imag.ImgSize = 1041
imag.PalSize = 1
image size fits in chunk (no palette)
read 1041 bytes from stream into compressed buffer (1041 bytes)
no palette present for this IMAG chunk. Need to rewrite code to re-use first palette
-
@miker:
Your explanation and example code for rle decoding saved the day for the last few (literal) bits.
Thank you very much for that miker1264.
IMAG chunks are now working for me as well, see attachment.
Need a lot of code cleanup, comments, abstraction and a complete rewrite to be able to add it to aiix.
That's fantastic! I'm glad your code works too.
I need some code cleanup, more concise comments, streamlining and a re-write to make it all work as well.
-
The streamlined AROS Icon Splitter is almost finished.
It can now save ILBM images with chunky to planar conversion & bitplane reduction.
Whereas before we were just saving 8bitplanes now it converts & saves the correct no. bitplanes & numcolors by depth.
-
Just when you thought the Icon Splitter Project was completed...
The first image decoder was DecodeOS35. The second one will be DecodeArgb for AROS Argb Icons & OS41 icons with ARGB data chunks. Unfortunately they use zlib compression.
-
It can now save ILBM images with chunky to planar conversion & bitplane reduction.
Whereas before we were just saving 8bitplanes now it converts & saves the correct no. bitplanes & numcolors by depth.
Congratulations on your progress. I am still working on some abstraction so i can add the ILBM saving parts (which is a still a long way to go for me).
Just when you thought the Icon Splitter Project was completed...
The first image decoder was DecodeOS35. The second one will be DecodeArgb for AROS Argb Icons & OS41 icons with ARGB data chunks. Unfortunately they use zlib compression.
Yeah. I had to use the zlib uncompress function for that. Other then that it is pretty straighforward:
DWORD which always seems to be 1.
DWORD compressed size - 1
WORD always seems to be zero
followed by array of compressed size bytes which can be fed to uncompress. Size of the destination buffer is FACE chunk fields Width (+1) * Height (+1) * 4 (ARGB bytes per pixel: note the order of ARGB)
edit: in the end i'll have a look at the deflate algorithm to see if it can be implemented without depending on zlib. see also here (https://en.wikipedia.org/wiki/Deflate).
edit2: In case interested in the layout of the zlib compressed data see here (https://www.rfc-editor.org/rfc/rfc1950)
-
@magorium
Thank you for the information.
At least the data format of the ARGB chunk is better documented than the data format of the IMAG chunk. Although IMAG is better understood now.
There is some additional information provided by PeterK about the flags in the FACE chunk where bit 0 means frameless & bit 1 means ARGB data is present. Although searching for the 'ARGB' chunkID works just as well.
We have to be able to decode the ARGB chunk data for AROS ARGB Icons which are Classic Icons with IFF data with IMAG chunks & ARGB data chunks. Also for OS41 which are Classic Icons with IFF data with a FACE chunk but no IMAG chunks followed by ARGB data chunks.
The ARGB data can be exported as PNG images.
-
The command line version of the icon splitter for AROS that I'm working on is the basis for the IconSplit GUI (GadTools).
All valid images will be available to save after loading. The command line version will simply save all. The GUI version will give a choice. To accomplish that I'm using 3 structs to store the icon data:
struct IconPalette,
struct IconImage (contains ImageData & IconPalette),
struct IconImageCollection (contains string IconStyle & 2 sets of IcoImages [ OS35Image, ARGBImage].
All ImageData is either 8bit or 32bit chunky bytes.
I still have to make sure it all works correctly. I'm not so sure about how the structs will work as a group. :)
Along with aiix icon splitter I'm starting a nice Windows-Amiga-Aros Apps collection. (Windows Apps for Amiga) 8)
-
At least the data format of the ARGB chunk is better documented than the data format of the IMAG chunk. Although IMAG is better understood now.
True.
There is some additional information provided by PeterK about the flags in the FACE chunk where bit 0 means frameless & bit 1 means ARGB data is present. Although searching for the 'ARGB' chunkID works just as well.
Yeah, I knew. Sorry for that. I should have linked to the post of PeterK at EAB :-[
We have to be able to decode the ARGB chunk data for AROS ARGB Icons which are Classic Icons with IFF data with IMAG chunks & ARGB data chunks. Also for OS41 which are Classic Icons with IFF data with a FACE chunk but no IMAG chunks followed by ARGB data chunks.
The picture posted in my reply #45 is such ARGB icon.
The ARGB data can be exported as PNG images.
I'm still thinking about adding support for (optional) saving them as 32-bit ILBM as well.
Although I can fire up AROS and/or classic to verify a few things I had (perhaps still have?) a difficult time finding a viewer for Linux that is capable of viewing particular ILBM files. For now I settled with XNView but initially resorted to an online ILBM viewer. Most viewers do not support bitmap depth schemes other than 1,2,4 or 8 planes, not to mention crashing completely when not supplying a full CMAP (the IFF standard does allow it).
So I had to waste a few days figuring out whether or not my code was doing things wrong or the used viewer was in error :)
Next on the list is adding (RLE) compression but it is not the most important feature to me to add right now, I rather focus on something you wrote in your post that you wrote right below the one I quoted, namely being able to access all icon related image data in a way that makes the code a bit more bearable to read as it is currently a giant mess ;D
-
I'm starting the process of compiling the icon splitter for Amiga OS 3 as well as for AROS. It only uses standard methods to read Classic Amiga Glow Icons to split them.
One question though. Is zlib available for Amiga OS 3.x ?
-
One question though. Is zlib available for Amiga OS 3.x ?
If you are referring to the zlib.library you will find 2 versions of it here:
https://amiga.foul.fr/index.php
-
One question though. Is zlib available for Amiga OS 3.x ?
If you are referring to the zlib.library you will find 2 versions of it here:
https://amiga.foul.fr/index.php
Thank you. That helps immensely.
I can use standard methods (simple C code) to split an Amiga Glow Icon into images.
That should also work on Amiga OS 3.x and AROS. The difficulty was that ARGB data chunks such as used with
Amiga OS4.1 icons requires zlib on AROS to decompress the ARGB data before writing PNG images from that data
or any further processing such as converting Amiga OS4.1 icon to AROS Dual PNG icon.
The missing part for using the IconSplit code on Amiga was the use of zlib. This makes things much easier. :)
The IconSplit cli version written for AROS has been compiled for Amiga 68k and it is working in Amiga OS 3.5.
But I believe it is getting the wrong offset to the IFF data. So there's still much work to do now that I feel better. ;)
-
Actually, after doing some research and testing I found that it is reading the offsets correctly.
Notice at the end it says number of OS 3.5 icon images is 0. That's because the orange icon only has newicon images in the Tooltypes. That's why the end of the Tooltypes + 6 bytes is the end of the file ( offset 1965 ).
I suppose I should try the icon splitter with an icon that really has IFF icon data. Maybe then it will save the ILBM images.
This is only my second Amiga 68k program. The first one of course was "Hello Amiga World" using an EasyRequester. :D
-
I can confirm that the Amiga 68k version of the Icon Splitter is working!
See screenshot...
-
And best of all...
The Amiga 68k binary that runs on Amiga OS 3.5 also runs just fine on AROS 68k.
So now I can comfortably switch to test the splitting of ARGB icons with AROS 68k since it can display these icons.
-
As always great work miker !
-
As always great work miker !
This is only my second Amiga 68k program after Hello World. :)
I was quite surprised it compiled easily and it worked as expected. It only uses native methods (standard C code) with no libraries, datatypes or OS methods.
I was also quite surprised that the Amiga 68k binary also works unmodified on AROS 68k. That means it's hopeful that the GadTools user interfaces for the other Icon Tools will also work with Amiga 68k as well as for AROS with the same sources.
-
The 68k version of AROS aims to be binary compatible with 68k Amiga applications, so that's a good sign if it works on both!
-
The 68k version of AROS aims to be binary compatible with 68k Amiga applications, so that's a good sign if it works on both!
Yes AROS is compatible with 3.0/3.1 binaries but it is not compatible with 3.2/3.5/3.9 binaries.
Also, AROS 68k "native" (ELF) binaries are not compatible with Amiga systems (all of them)
-
The 68k version of AROS aims to be binary compatible with 68k Amiga applications, so that's a good sign if it works on both!
Yes AROS is compatible with 3.0/3.1 binaries but it is not compatible with 3.2/3.5/3.9 binaries.
Also, AROS 68k "native" (ELF) binaries are not compatible with Amiga systems (all of them)
That depends on the 68k binary.
I used DevCpp to compile IconSplit as an Amiga 68k binary. I used Amiga OS 3.5 in WinUAE and AROS 68k Vanilla to test. It works well in both. I assume it works for any Amiga OS 3.x since it works with OS 3.5.
-
I used DevCpp to compile IconSplit as an Amiga 68k binary. I used Amiga OS 3.5 in WinUAE and AROS 68k Vanilla to test. It works well in both. I assume it works for any Amiga OS 3.x since it works with OS 3.5.
Yes I was referring to the opposite, Binary AROS 68k cannot run on Amiga (All)
Regarding App 3.2/3.5/3.9, do they use "Reaction" not supported by AROS 68k ?
-
I used DevCpp to compile IconSplit as an Amiga 68k binary. I used Amiga OS 3.5 in WinUAE and AROS 68k Vanilla to test. It works well in both. I assume it works for any Amiga OS 3.x since it works with OS 3.5.
Yes I was referring to the opposite, Binary AROS 68k cannot run on Amiga (All)
Regarding App 3.2/3.5/3.9, do they use "Reaction" not supported by AROS 68k ?
That depends on the app. Mine is a cli app with no user interface. My other Icon Tools use GadTools user interface. You can choose to use Reaction GUI Toolkit or MUI or something else for Amiga but to be AROS compatible it should be cli only, GadTools or MUI. I'm still experimenting.
-
Usually OS3 based MUI or GadTools Apps are better supported by AROS 68k, then maybe the incompatibility may also depend on the libraries used, maybe OS 3.9 and 3.2 use more up-to-date libraries.
-
IIRC, classic Amiga 68k uses the Hunk format for executables, while AROS, MorphOS and AmigaOS 4 prefer ELF. So, an AROS ELF file won't run on a 68k Amiga.
-
Yes correct, although AROS, MorphOS and AmigaOS 4 use ELF incompatible with each other !
-
Yes correct, although AROS, MorphOS and AmigaOS 4 use ELF incompatible with each other !
That's a shame.
-
So what do we do with the ILBM images once they have been split from the icon & saved to files?
We could easily convert them using datatypes to 32bit ARGB then save as PNG. After that we can use a paint program to edit the image or we could use HSL color rotation to change colors.
After modifying the image how do we convert it back to ILBM that can be used to make a new GlowIcon? I wrote a small command line app called DT2GIF. It converts 24bit or 32bit images using Neuquant into 8bit GIF with 256 colors.
In this case the output of Neuquant is determined by Max Colors which in this case is 256. If we modify the program to make it DT2OS35 for example we set the number of Max Colors to 32. Neuquant will quantize the colormap to 32. But the index values are still 8bit chunky values. Luckily IconSplit has provided some useful functions for the conversion process.
I can re-use SaveImage to use native methods to save an ILBM. I can also use the functions MakePlanar & ChunkyBytesToBitplanes to reduce the number of planes to 5 to correspond to 32 colors. It also outputs planar data. The colormap & planar data are then sent to SaveImage. We can specify the max colors (planes) at the command line. So it doesn't need to be 5. That's just an example.
Of course, if this process works ( DT2OS35 ) then we could in theory quantize any 32bit icon image to save an ILBM. The ILBM images could then be used to make a new GlowIcon. Maybe not all 32bit icon images are suitable to convert but it would be interesting to try.
I believe this could work to quantize a 32bit image and save it as ILBM with the specified number of biplanes. ;-)
-
@magorium
I was just wondering if you had completed aiix icon splitter?
I will send you a PM regarding the Pascal sources.
I'm working on the Encoder part to save Amiga Icons. Maybe if I understand the Decoder part better it will be easier to write a working encoder.
In the meantime I wrote an RLE encoder algorithm from scratch that works well to encode the 8 bit palette data.
That's a good starting point for the image encoder part.
-
I was just wondering if you had completed aiix icon splitter?
Unfortunately I did not finish the project. I stopped at my 3th re-write for some reason (the reason why eludes me atm, probably some distraction).
The previous two rewrites were necessary for me in order to grasp/detail the saving routines and detecting the re-use of the same coding/decoding routines. That led me to a smart-ass solution for the 3th rewrite but one which I never seem to have finished (no saving routines implemented at all). Things become rather complicated when you want to be able to convert from every available storage type to another one, including reducing colors (in case necessary).
I will send you a PM regarding the Pascal sources.
That is ok. I already noticed your PM but allow me a little time to clean things up :)
I'm working on the Encoder part to save Amiga Icons. Maybe if I understand the Decoder part better it will be easier to write a working encoder.
Understood. It is complicated enough as it is.
Funny/Ironic part is I used c-code for reference :P
In the meantime I wrote an RLE encoder algorithm from scratch that works well to encode the 8 bit palette data.
Nice !. at least that means you'll have something that you can check against.
-
I have made some progress understanding the encoding and decoding process for the IFF Icon Data as far as the encoded image data. It is a "bitstream" of data. The bytes we see in the encoded data are not real bytes. They are encoded bytes. Even the RLE bytes are encoded also.