icon.library 46.4 test versions

[pixie]

There's no problems when setting tooltypes and such?

[mfilos]

Originally Posted by pixie

There's no problems when setting tooltypes and such?

The tooltypes etc from the original icons will be lost ofc.
But the way I do it is copy my DualPNG icon, dissect it into 2 PNG images (either with HexEdit or via PeterK's excellent script) then get the images to your PC and edit them, then where ready transfer them back to the Amiga and join them into an icon.
Then you can use CopyIcon to replace the original icon to the new one, maintaining all icon info (tooltypes etc).

[PeterK]

Originally Posted by pixie

Those are pretty massive indeed! xD
Is there any util that allow us to downscale the png icons? I would like to pick those png icons used on Amiga OS 4 and downsize them to AmigaOS 3.2 size but with true colour alpha et all

Yes, you can scale icons up or down and much more with this excellent ImageConverter by Thilo Koehler, ... (script removed, it needs an update)

Just read the supplied syntax from ImageConverter.doc and add some options in my script (like -w 48 -h 48) to the lines with the ImageConverter commands.

[PeterK]

Originally Posted by mfilos

@PeterK
You did it my friend! No more jagged lines on conversion from OS4 to PNG! YOU DA BOMB!
Ok time for questions now...
The script modifies the original/source icon (for example my SMB icon was 13,844kb and became after convertion 16,516kb. Is that due to the ConvertPNGToOS4 (running in my S-S) that my icons have (due to snapshoting etc)? Opening the icon with HexEditor shows for sure that is not PNG.

Oh dear mfilos, please don't run ConvertPNGtoOS4 or ConvertTrueColor at the same time together with ConvertToPngIcons!

And yes, ImageConverter still modifies the icon images a bit, because it can't get the original ARGB data from icon.library directly. My icon.library only updates the RGB data after merging the image and the background by using the alpha channel values. ImageConverter lets my library write the image twice: once to a white background and once to a black background, and then it recalculates the none supplied alpha values and RGB colors from the differences of these two images. The resulting ARGB data is quite good, but not exact for very low alpha values, because the fading with alpha is some sort of a lossy data processing, you are losing the fractions in the calculations, the colors can only be mixed in 256 steps for each RGB component, not perfectly. But usually, that little difference won't be visible for the user.

That's why I always copy the icons I want to convert to RAM: before running your script (not to alter my original icon).
Is there a way we can modify the script in order to get these PNG images to T: pngimages/ without altering the original icon? That will save me one copy to RAM for safety :P

Look into my previous answer for pixie, just comment out the last copy line in my script. The icon path/filename is already stored in the variable $file.

As a feature request... ...I would LOVE to be able to make a ToolsMenu entry that would run "ConvertToPNG []" (grabbing the icon path/filename from the selected icon) passing it to the script so I didn't have to run it and select via the requester.

Yes, I may add that Tools/Menu feature to a new script. I also tried to use a tool like DropView already to allow a simple icon drag 'n drop onto an appicon box, but I have some problems with font related errors when I use that tool and I'm still working on passing the filename correctly as an argument to the script with ".key". That's work in process ... there was not enough time yesterday to get it working correctly and reliable.

[mfilos]

Originally Posted by PeterK

Oh dear mfilos, please don't run ConvertPNGtoOS4 or ConvertTrueColor at the same time together with ConvertToPngIcons!

You know I'm not gonna disable my loving ConvertPNGtoOS4 everytime I wanna export an icon

Originally Posted by PeterK

Look into my previous answer for pixie, just comment out the last copy line in my script. The icon path/filename is already stored in the variable $file.

What a noob I am! I haven't seen that last line
That did the trick... all good now

Originally Posted by PeterK

Yes, I may add that Tools/Menu feature to a new script. I also tried to use a tool like DropView already to allow a simple icon drag 'n drop onto an appicon box, but I have some problems with font related errors when I use that tool and I'm still working on passing the filename correctly as an argument to the script with ".key". That's work in process ... there was not enough time yesterday to get it working correctly and reliable.

Making a Tools/Menu script would be great Peter.

Thanks for everything

[AMIGASYSTEM]

Originally Posted by pixie

I would like to convert png icons, if needed be I would convert OS4 into png. The thing is I cannot get either OS3 native nor AROS. I did find a video of yours on youtube, but it only showed the app being used, not where to download it.

The developer "PEB " has only Distributed only the OS4 version you will find it HERE.

The AROS and OS3 version were never distributed, you find the AROS version installed on AROS One and IcarOS, while the OS3 version you have to ask the developer !

[PeterK]

Carlo, I have an IconEditor v1.9 installed here on OS3 and just used it to check the separated alpha channel data and RGB images from the ImageConverter icon conversions. I don't know if it can be distributed, probably not without permission.

On OS4 I also have the old and the 2.0 version installed for tests, but I don't like these huge AISS image collections and these very large Hollywood addons.

And I'm not an icon designer due to my lack of creativity and the missing ambition to do something useful with these nice tools.

[AMIGASYSTEM]

If the developer doesn't distribute it, it means that for some reason he doesn't want to do it, he told me that on OS3 and AROS there was something missing, which I don't remember now, that didn't allow to create icons on OS4 style.

Then in the end even if the AROS and OS3 version can't create Os4 icons, that's fine with me anyway, I prefer DualPNG Icons, which among other things are the ones that work well everywhere.

Regarding "AISS" in fact and a great package, which slowed down a lot the installation of AROS One, for this reason in the Folder "ToolbarImages" I only left the images that the AROS OS and Third Part Applications ulizzano, so only a few tens of images, some I also improved them graphically.

Regarding the reaction of icons, I am not a creative person either, however, by dint of working with images, ideas and creativity come automatically.

[pixie]

Originally Posted by PeterK

Carlo, I have an IconEditor v1.9 installed here on OS3 and just used it to check the separated alpha channel data and RGB images from the ImageConverter icon conversions. I don't know if it can be distributed, probably not without permission.

On OS4 I also have the old and the 2.0 version installed for tests, but I don't like these huge AISS image collections and these very large Hollywood addons.

And I'm not an icon designer due to my lack of creativity and the missing ambition to do something useful with these nice tools.

It is for 3.9 or is available also for 3.0?

[PeterK]

Sorry, but I don't want to try out an installation on 3.0 or 3.1 now. It will probably not work, because in addition to IconEditor the required AISS and the Hollywood stuff have to support the old OS 3.0, too.

[pixie]

I asked because I got it from the author and it didn't worked, I guessed it was because I have a 3.1 build

[AMIGASYSTEM]

Originally Posted by PeterK

Sorry, but I don't want to try out an installation on 3.0 or 3.1 now. It will probably not work, because in addition to IconEditor the required AISS and the Hollywood stuff have to support the old OS 3.0, too.

Peter IconEditior works fine on OS 3.1, you just need to install the MUI libraries, Hollywood PlugIns and the required AISS images

[mfilos]

Karlo is correct.
The latest version I got from Paul was compiled in Hollywood 9 and it's v2.0.
Paul is a really kind guy that responds rather quicky. His version had issues with OS3.2.2 and P96 3.3.3 but that turned out to be an rtg.library bug which was fixed by a beta I got from Jens (and eventually will be released).

[PeterK]

If I understand pixie correctly, he needs the IconEditor on OS 3.0, not 3.1. But many coders don't care for 3.0, since their development kit is for v40, v45 or v47 and then sets the minimum requirements to that version automatically, not checking whether v39 could also be sufficient.

mfilos, I've modified my script a bit now, so it can be launched from the tools menu or a drop box, but multi-selection of a bunch of icons is not supported. If the icon loading per menu fails you will see the "requestfile" again. It works for me with AppMenu.

You have to ensure that the script file, ImageConverter and CopyIcon are in your PATH. Of course, every user can modify the script to adapt it to whatever he prefers, like using "Ram:" or a directory on the harddisk instead of "T:" for the temporary files.

The icon loading with DropView also works in principle, but DropView still has a problem with the font loading for its GUI, the preferences window. It tries to load XHelvetica 11, but that fails with "Error 2" if that font was not already loaded by something else like the font preferences. I have to check whether this is a bug in DropView or maybe a problem with a certain diskfont.library version or something else on my system. Edit: Solution in another post below ...

https://aminet.net/package/util/app/dropview

[mfilos]

Originally Posted by PeterK

mfilos, I've modified my script a bit now, so it can be launched from the tools menu or a drop box, but multi-selection of a bunch of icons is not supported. If the icon loading per menu fails you will see the "requestfile" again. It works for me with AppMenu.

You have to ensure that the script file, ImageConverter and CopyIcon are in your PATH. Of course, every user can modify the script to adapt it to whatever he prefers, like using "Ram:" or a directory on the harddisk instead of "T:" for the temporary files.

The icon loading with DropView also works in principle, but DropView still has a problem with the font loading for its GUI, the preferences window. It tries to load Helvetica 11, but that fails with "Error 2" if that font was not already loaded by something else like the font preferences. I have to check whether this is a bug in DropView or maybe a problem with a certain diskfont.library version or something else on my system.

https://aminet.net/package/util/app/dropview

The attachment contains the updated script only.

Script works like a charm mate with ToolsMenu.
I haven't tried Dropview but I wouldn't use it anywayz as I find ToolsMenu rather quick and easy for my taste.
Thanks a lot!
One thing that semi-annoyed me was the filename of exension in png images (image.png, image.png2). Tried altering the script but putting for example image1.png, image2.png doesn't work, so I just rename whenever I transfer the images to my PC (not biggie).
That script definitelly saved a lot of time, plus qualitywise is better and iconsize more precise! Fantastic \o/

[pixie]

Originally Posted by PeterK

If I understand pixie correctly, he needs the IconEditor on OS 3.0, not 3.1. But many coders don't care for 3.0, since their development kit is for v40, v45 or v47 and then sets the minimum requirements to that version automatically, not checking whether v39 could also be sufficient.

It was a slit of tongue, I actually use 3.1. icon.libraryvworks like a charm, with afaos it has some problems though... When I tried to run icon editor from Paul it didn't run, but I haven't a way to know the dependencies

[PeterK]

Originally Posted by PeterK

The icon loading with DropView also works in principle, but DropView still has a problem with the font loading for its GUI, the preferences window. It tries to load XHelvetica 11, but that fails with "Error 2" if that font was not already loaded by something else like the font preferences. I have to check whether this is a bug in DropView or maybe a problem with a certain diskfont.library version or something else on my system.

https://aminet.net/package/util/app/dropview

I found a solution for DropView now:

1.) Make sure that you have the "XHelvetica.font" size 11 installed (not just helvetica). There are different versions, also modified fonts, available on Aminet. I took the one from TinyMeter now.

2.) Optional, you could execute Sys:System/FixFonts after the font installation in Fonts:.

3.) Add the following line to your startup-sequence or user-startup:

LoadResource >NIL: Fonts:XHelvetica/11 LOCK

That fixes the problem of DropView with the Error 2 when you double-click on the app-icon to open the preferences window.

4.) You can change the viewer program in the preferences from "MultiView" to "ConvertToPngIcon" as a CLI script. Save your preferences, and if you like rename DropView to "ConvertIconToPNG" or whatever you like.

5.) Make sure that the locations of ImageConverter and CopyIcon are in your PATH, so that these tools can be found by the script.

[PeterK]

Originally Posted by pixie

It was a slit of tongue, I actually use 3.1. icon.library works like a charm, with afaos it has some problems though... When I tried to run icon editor from Paul it didn't run, but I haven't a way to know the dependencies

AfA_OS uses its own icon_lib.exe in most cases to load and display icons. I'm not a user or fan of AfA_OS and I can't fix the issues of icon_lib.exe. AMIGASYSTEM and mfilos may have more experience with AfA_OS and possible workarounds.

If you want to know the dependencies of a program you can run SnoopDos or install the exe.datatype and then load that program file with MultiView. The exe.datatype shows all required libraries and other resources. And that could end in a chain reaction: the libraries may need other libraries and so on ...

[pixie]

Originally Posted by PeterK

AfA_OS uses its own icon_lib.exe in most cases to load and display icons. I'm not a user or fan of AfA_OS and I can't fix the issues of icon_lib.exe. AMIGASYSTEM and mfilos may have more experience with AfA_OS and possible workarounds.

Well, I just want it for the ttf system, I thought I was running without icon_lib.exe but I guess I was wrong, I took it off now from it's folder, I hope to have it sort out!

Originally Posted by PeterK

If you want to know the dependencies of a program you can run SnoopDos or install the exe.datatype and then load that program file with MultiView. The exe.datatype shows all required libraries and other resources. And that could end in a chain reaction: the libraries may need other libraries and so on ...

Nice tip, didn't knew of exe.datatype

[PeterK]

I never had any demand for TrueType or Antialiased fonts, because my eyes are so bad already, that I can't see anything clear and sharp, so they are doing the job of antialiasing perfectly for free.

But there is also a very simple solution for Antialiased fonts, a patch written by Stephan Rupprecht. It just merges the text color with the background for the surrounding pixels. It works with any bitmap font already. aafont.lha:

https://www.stephan-rupprecht.de
https://www.stephan-rupprecht.de/downloads/aafont.rea

If you don't like it, you could ask mfilos for his AfA_OS solution. He also just uses the TrueType font support, but don't has to active icon_lib.exe anymore.