Hi, I am using Arch Linux, I have compiled the AROS Cross Compiler and AROS system, see attached photo. All seems to be working.

Hello and welcome to AROS, I assume you need to use Mint because pre-build binaries or AROS are not working on Arch linux? Can you describe what problem are you having? PS. An alternative would be to build AROS from sources: [url]https://github.com/deadwood2/AROS/blob/master/INSTALL.md[/url]

I am an Arch Linux user. I run AROS Linux Hosted on Linux mint but it's not my native one. Has anyone tried running Icaros on an Arch linux machine. I am an Arch Linux user. Im use EndeavourOS Linux x86_64. Sorry for my poor english. Any help is needed . Best regards !!!

icaros desktop over the years has been quite successful but many years have passed

I think it's the other way around, Amiga users don't like AROS!

I know, I know! AROS users don't like Amiga! :-) But I believe in interoperability where programs that work on AROS can be compiled for Amiga.

Interestingly, I'm in the process of re-writing PixieView to allow it to compile & run on AROS x86 & x86-64 as well as Amiga. I'm changing the display method to one that is more Amiga compatible. It is currently using CyberGraphics Library. The new method is to use Datatypes with AddDTtoWindow. I've already demonstrated the new method on Amiga 68k. PixieView uses Datatypes to display images in an Intuition Window with a menu system. All these things are Amiga compatible. Now it needs a new Glow Icon for the Amiga 68k version. ;-)

Yes the 32Bit version reports the invalid icon file, but the 64Bit version goes into Guru

[quote name=AMIGASYSTEM post=7659]@AMIGASYSTEM - Miker, I tried to compile your new source, the 32Bit version works perfectly, while the 64 version splits and saves in RAM perfectly the 2 images of a PNG Icon, but if you add a wrong or invented filename to the command a Guru arrives! This had also happened with the compilation of your previous source, unfortunately I don't know if this Guru is caused by the "not yet stable" AROS 64 Bit[/quote] By "wrong or invented filename" I suppose you mean something other than an icon file. It should search the file signature for 'png' or 'e310'. If not found it should report 'Invalid Icon File!". I will check that out when I have time.

Miker, I tried to compile your new source, the 32Bit version works perfectly, while the 64 version splits and saves in RAM perfectly the 2 images of a PNG Icon, but if you add a wrong or invented filename to the command a Guru arrives! This had also happened with the compilation of your previous source, unfortunately I don't know if this Guru is caused by the "not yet stable" AROS 64 Bit

Here is the newest sources for IconSplit. It's command line only at the moment.It take 2 arguments, program name & icon filename. It can be compiled for x86 or x86-64. It can split several icon styles such as Dual PNG, OS3.5/3.9 Glow Icon, New icon stored in ToolTypes, OS4 with ARGB chunks & AROS ARGB Icons with ARGB chunks. The images are saved to Ram Disk.

The Iconsplitter binary is for Amiga 68k. The Amiga version will look for a specific number of Icon Lib (Peter K's Icon Library). If not found it won't do anything. Not sure about error checking. I will test it to be sure. The Iconsplit binary is for AROS. The code is slightly different. It should compile for 32bit or 64bit. Not sure about error checking with this one either. I will need to do some testing. :-) In the shell the syntax is Iconsplit file.info. It's the program name followed by an icon name. Not sure it will work with just the program name. It should print the Help text in the shell but maybe it's not doing it correctly. PS - I can confirm that IconSplit compiles correctly & it works well on ABIv11 64bit. However, as I suspected if the user only enters the program name in the shell it will crash because it doesn't check the number of arguments. This has been corrected & I will post the new code. Now it checks for the number of arguments. It is command line only so it won't work from Wanderer. If the user only enters the program name it will print the Help Message in a shell.

Yes I confirm Pixieview 64Bit does not recognise graphic formats, it seems to have problems with picture.datatypes, but I may be wrong! IconSplitter 64Bit works fine, if on the shell I run "IconSplitter ?" I get a Guru, but this could be due to AROS 64 still not being very stable :) IconClone 64Bit, Icondrop 64Bit on the other hand seem to work very well |

For PixieView I was doing some 64bit testing. It didn't work the first time. More work to do! ;-)

Recently I revisited my old C# (c sharp) program "ILBM Viewer" to get the code for drawing the color map for bitmapped images (<=8bpp). The ILBM Viewer draws the color map on the right side but PixieView will display it in a window with color data in the window titlebar (max colors/used colors). I was surprised at how SLOW the C# code is compared to C code. AROS apps are faster!! PS - I will do some 64bit testing tomorrow.

Yes for all images, but this happens "only" for the "64Bit" version, the version compiled on 32Bit works perfectly!

Do you get the "Can't Read Picture File" for all images? Have you tried several images? Maybe you selected some images that don't have the updated Datatypes? That's why I'm asking. The makefile.src is used with the Build System using the Linux Cross-compiler. It defines many of the parameters for the compiler such as the source code files to be compiled, the output exe filename, the output exe path & which libraries to include if any. Some mmakefiles such as the one I included are simple but some others can get very large & complex. Are you using gcc in a shell or the full build system for ABIv11 ? You also mentioned on the Icon Tools topic that Icon Split isn't working for 64bit. I will check both of these out when I get some free time.

Thanks miker, before I talk about my source compilation, I would like to ask you a question: What is mmakefile and how do you use it, thanks ! - Compilation of your source on AROS One x86 was successful, and PixieView works perfectly, only filters don't work - The compilation of your source on AROS One 64Bit was successful, but the pictures are not seen error "Can't Read Picture File", the same picture with Multiview is seen fine ! I will now test your new version you posted !

In case you missed it here is the binary for the current version. Here's the story for the Color Count menu item which consists of 4 functions & 2 macros to count the number of unique colors in an image. I started the test version of the program that contains Count Colors on 12-12-24 last month. For the first 4 weeks I only wrote Count_Colors which uses Find high index to get the color count for bitmapped images with index values. But I didn't know how other programs like FastStone Viewer & IrfanView actually counted the unique colors in a 24/32 bit images. Two weeks ago I had an idea. At first I was going to simply compare pixels bytes by bytes but I didn't know how to sort the pixels or remove the duplicate pixels. Those are the basic methods. I thought about using the GetUint32 macro to convert 32bit pixel data into a long *array of 4-byte long numbers. The second macro I used was the "quicksort" method aka qsort with a custom comparator. Lastly I used a simple "Remove duplicates" function that requires the integer values to be grouped together in ascending order & that's why qsort was needed for it to accurately remove the duplicate integers. Two days ago the functions were working mostly but I was using jpeg images for testing. After several hours comparing the color counts for about a dozen images I realized my functions were working correctly but jpeg uses Lossy Compression schemes. So I tested PNG & BMP. After that everything worked as expected. Some jpegs behave nicely. But mostly jpeg images aren't consistent for getting the color count. However, Lossless Image types such as PNG,BMP, PNM,PPM,TGA,TIFF, etc. work well.

There is a new item on the Colors Menu for PixieView. The Color Count menu item returns the Number of Unique Colors (Used Colors) in an image. It works for bitmapped images with a color palette or 24/32 bit images. Interestingly, I found that Lossless Image types such as PNG or BMP work best because the number of pixels doesn't change. However, jpeg images for Color Count are not consistent. That's because jpeg uses a Lossy Compression Scheme so some pixels are lost in the process. Here is a sample image that works well called "French Country Life".