icon splitter

[magorium]

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. 

LOL. Ah well, impatience 

Steady going forward will get us there in the end as well :old-grey-wisdom: :coughs: 

[AMIGASYSTEM]

@AMIGASYSTEM:
you are going waaay too fast for me dear padawan 

padawan to me that I am 69 is a compliment

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

[magorium]

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. but that led me to nowhere (although there are some working solutions presented there). Thus I ended up here

So.. that leads me to believe something like the following is able to work for Windows as well:

Code: [Select]

for /F %i in (*.info) DO aiix %i


[miker1264]

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. but that led me to nowhere (although there are some working solutions presented there). Thus I ended up here

So.. that leads me to believe something like the following is able to work for Windows as well:

Code: [Select]

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. 

[magorium]

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.

[magorium]

@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)

[miker1264]

@magorium

I'm rebuilding my cross-compiler tool chain. I will get back to you with the needed information about Glow Icons.

[magorium]

Thank you for letting me know. There is no need to rush there miker1264. Have fun building (and testing ofc)  ! 

[miker1264]

@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.

[miker1264]

@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.

[magorium]

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).

[miker1264]

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.

[miker1264]

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. 

[miker1264]

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. 😊

[magorium]

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).