IconClone Icon Exchange

[AMIGASYSTEM]

AMIGASYSTEM

Thanks for the information. I will investigate that issue.

In the meantime IconClone has been revised to version 1.10 which will be posted on AROS Archives in the next few days

Work on the next icon tool is going well. It's called IconPress because it "presses" (joins) two images into an icon file. It does what ilbmtoicon does but in a more meaningful & user-friendly way. 

Simply drop either two PNG images or two ILBM images in the two Display Areas on Left & Right. There are two buttons. "Save Icon" will save a PNG icon if both images are PNG. It will save a Classic Amiga Icon with OS35 Extension if both images are ILBM. "Save Argb" only works will PNG input images. It will save Classic Amiga Icon with OS35 Extension with Argb data chunks. For example Gorilla Icons are Classic Icons with Argb data chunks.

IconPress uses Neuquant Color Quantizing to reduce the 32bit PNG images to ILBM images with 8 bitplanes to be stored in the OS35 IFF Data. This image conversion is the basis for two small command line apps for AROS that I will write called icon_to_os4 (PNG to OS4.1) & os4_to_icon (OS4.1 to PNG). As far as splitting icons I'm working on two other small command line utilities icon2png (split PNG icon) & icon2iff (split Classic OS35 icon). DT2IFF already reduces a 32bit PNG to 8bit ILBM. All these small utilities will be posted to AROS Archives as well with source code

As mentioned earlier IconClone, IconPress, IconSplit, IconBatch, IconType & IconColor are all small icon apps that will be part of Icon ToolKit. They will also work as standalone icon apps. That's the plan. 

Great job, this will also be useful for users who like the old Glow Icons of OS 3.9 and OS 3.2

[miker1264]

AMIGASYSTEM

Thanks for the information. I will investigate that issue.

In the meantime IconClone has been revised to version 1.10 which will be posted on AROS Archives in the next few days

Work on the next icon tool is going well. It's called IconPress because it "presses" (joins) two images into an icon file. It does what ilbmtoicon does but in a more meaningful & user-friendly way. 

Simply drop either two PNG images or two ILBM images in the two Display Areas on Left & Right. There are two buttons. "Save Icon" will save a PNG icon if both images are PNG. It will save a Classic Amiga Icon with OS35 Extension if both images are ILBM. "Save Argb" only works will PNG input images. It will save Classic Amiga Icon with OS35 Extension with Argb data chunks. For example Gorilla Icons are Classic Icons with Argb data chunks.

IconPress uses Neuquant Color Quantizing to reduce the 32bit PNG images to ILBM images with 8 bitplanes to be stored in the OS35 IFF Data. This image conversion is the basis for two small command line apps for AROS that I will write called icon_to_os4 (PNG to OS4.1) & os4_to_icon (OS4.1 to PNG). As far as splitting icons I'm working on two other small command line utilities icon2png (split PNG icon) & icon2iff (split Classic OS35 icon). DT2IFF already reduces a 32bit PNG to 8bit ILBM. All these small utilities will be posted to AROS Archives as well with source code

As mentioned earlier IconClone, IconPress, IconSplit, IconBatch, IconType & IconColor are all small icon apps that will be part of Icon ToolKit. They will also work as standalone icon apps. That's the plan. 

Great job, this will also be useful for users who like the old Glow Icons of OS 3.9 and OS 3.2

Perhaps another small icon app  "os35_to_icon" (ILBM to 32bit PNG) ? Then you convert GlowIcons to DualPNG.

But of course the original quality determines the output.

[AMIGASYSTEM]

I don't know I have never created Glow icons in OS 3.9 style!

[miker1264]

Also for Disk Icons, AROS x86 with Dual-PNG Icons behaves strangely:

Any Project icon if copied to the root of the disk, automatically turns into a "Disk" Icon, vice versa if you copy the same icon to a folder it goes back to being a "Project" icon, see screenshot

All this does not happen with Native AROS icons

The strange behavior is probably due to the fact that PNG icons don't store the IconType in the icon data like a Classic Amiga Icon. Instead the icon attributes are stored in the ic0n chunk.

Do you get the same behavior on Wanderer & Dopus4 ?

[AMIGASYSTEM]

As shown in the first screenshot I had posted earlier, the difference from Disk Icon to project icon is really noticeable with Dopus4

On Wanderer "it all depends on its filename," see screenshot

- If a DualPNG icon is named "Disk.info" it will be a Disk Icon.
- If we rename the same Icon "Disk2.info" or other name, it will become a Project Icon

On AfA OS the Dual PNG Icons do not have this problem, a Disk Icon will remain a Disk Icon even if renamed.

On OS 3.9, on the other hand, if a DualPNG icon "Disk.info" is renamed "Disk2.info," it will become a Tools Icon

[miker1264]

I don't fully understand how all the icon data is stored in the ic0n chunk in PNG icons. Specifically I'm not sure Icon Library hard codes the icon type attribute in ic0n chunk.

According to Icon Library code if type = 0 it will deduce the icon type based on several criteria.

To better see exactly what data is in the icon files I'm writing a small tool 'IconInfo' that will list at the command line everything about Classic Icons & PNG icons.

So then I will know if Wanderer is not being truthful. 

So far I looked at the icOn chunk data for about ten PNG icons. The results are surprising!

None had Icon Type defined in the attributes. Drawer icons had some drawer data & stacksize = 4096 & frameless whatever that is. Project icons had stacksize, frameless, iconx, icony & defaultool defined. Strangely, disk.info only had drawer data, stacksize, frameless & two tooltypes. It looks like a drawer icon.

[magorium]

@miker:
Craps, I totally forgot about this. My Apologies.

From memory thus afaik (I'll dig up my code) the 'settings' in the icon chunk are stored as tags. AROS uses a set of default tag-values in case the icon chunk does not contain them or one is not present.

edit: found my code (icon chunk indeed contains tags). You got a PM miker1264 

[miker1264]

@miker:
Craps, I totally forgot about this. My Apologies.

From memory thus afaik (I'll dig up my code) the 'settings' in the icon chunk are stored as tags. AROS uses a set of default tag-values in case the icon chunk does not contain them or one is not present.

edit: found my code (icon chunk indeed contains tags). You got a PM miker1264 

Thanks for the information. It's good that you reminded me that a char array ends with null char.

Reading the ULONG tag ID's wasn't difficult. But I was trying to find an easy way to read Defaultool & Tooltypes.

When I find the tag ID for Defaultool for example I can just read the remainder of the icon chunk into UBYTE *chunk data. Then value = (char *)chunk data. And length of string is strlen(value). Something like that. 

But I will need to work with the icOn chunk in a later project

[miker1264]

Ha! Now IconClone can load & display Volume Disk Icons.

It wasn't easy to work out how to get the correct icon filename.

I'm wondering if volume disk icon names are case sensitive? Is "Disk.info" the same as "disk.info" ?

[AMIGASYSTEM]

Disk.info, disk.info, DISK.INFO, nothing changes, we are on AMiGA no Linux

When will the new version of IconClone be available?

[magorium]

Thanks for the information. It's good that you reminded me that a char array ends with null char.

You're welcome. Hopefully it was helpful (as i PM'ed you quite some long detailed technical boring crap)

Reading the ULONG tag ID's wasn't difficult. But I was trying to find an easy way to read Defaultool & Tooltypes.

The tool-types is/was a bit tricky for me as well. Once you got these reading correctly then all else in the icon chunk false into place (automatically) except for those tags that your current code-base does not support yet (but can then easily be added).

But I will need to work with the icOn chunk in a later project

Then it is indeed better to tackle this format in an early stage.

Unfortunately the format itself leaves a lot desired as it involves a lot of if/then checks in order to be able to determine the actual/correct icon type.

Any hows: If you have more questions or run into bumps in the road or you simply wish to check your progress then feel free to make a shout. we could always compare/check our tools (and perhaps I have mistakes in there as well so we could compare notes).

[miker1264]

@magorium

Thanks. I'm using diskobjPNGio.c  function ReadIconPNG as a guide. I'm only using the attr defines. I'm reading the ULONG tag ID's directly. Reading the icOn chunk & listing it's contents is for a new small command line app IconInfo which lists all the icon attributes & other data for Classic Amiga Icons, ARGB Icons including OS4.1 Icons & AROS PNG Icons.

I'm just finishing up the new features for IconClone.

@paolone
It now has command line arguments & switches. I will add the syntax for those in the readme file.

It also now supports loading & displaying single image Gorilla Icons for AROS 68k. It also supports loading & displaying Volume Disk Icons (Disk.info).

If you change the icon images for a Disk Icon on Workbench a system restart is required for the visual changes to take place. Remember that if you exchange images for Ram:Disk.info if you want changes to be permanent you must also change the def_Ram icon in Presets/Env-Archive/SYS.

[AMIGASYSTEM]

miker, for swapping the DiskInfo.info, but also other System Icons you don't need to reboot the system, just do a refresh of Wanderer.

On AROS to my knowledge there is no refresh command , but you can refresh Wander simply by using the command "Wanderer Backdrop"

[miker1264]

miker, for swapping the DiskInfo.info, but also other System Icons you don't need to reboot the system, just do a refresh of Wanderer.

On AROS to my knowledge there is no refresh command , but you can refresh Wander simply by using the command "Wanderer Backdrop"

Very nice. 

I assumed there was a way to do that but I wasn't sure about how to do it. There may be a similar feature for Magellan to redisplay the Workbench.

[AMIGASYSTEM]

No on Magellan, "Opus Backdrop" does not refresh the Workbench.

AmiStart also has a Refresh but it only works on its bar.

I think it should not be difficult to create a small command to do a Workbench Refresh, if any developer would like to do it we would be very grateful.

I will do some research if there is any source or OS3 script that can be adapted


EDIT:

Found on Aminet "SmartW" C-Source is included.
Tried to compile on AROS x86 it but I get compile errors

http://aminet.net/package/dev/src/SmartWB10