@retrofaza

Miker's Icon Tools may be exceptional in terms of quality, but currently on AROS 32 and now also on 64-bit, you can add a luminous border, resize images/icons or add other effects easily with IconEditor. I am attaching one of my old videos.

https://youtu.be/kVrmM0NU1NI

AMIGASYSTEM,

Thank you for the very nice looking app logo for Icon Builder! It's one of the joys of working on the program every time I see the logo. It reminds me of the casino game "Huff-n-Puff".

AROS One used custom icons and for that the neon glow effect from Icon Editor would be sufficient because all the icons match.

But when someone is running an AROS distro that uses all icons in the style of Ken's v4 icons and they want to make new icons that match the old ones it isn't sufficient. My program will add drop shadows and glow borders that perfectly match Ken's icons. So the icons all match.

The Icon Builder program currently reads a text file that contains the chaincode needed to draw the glow mask around the perimeter of the RGB image in the middle of the icon. Once I have the glow mask I then import it into Photoshop to apply the blur effect which is a gaussian blur.

But in order for the process to be automated the blur effect and generating the chaincode to describe the perimeter of the image all needs to be part of the program.

With that in mind over the weekend I started writing Detect_Contour which is a function to read the pixel data of the RGB image to detect the perimeter of the image. It stored the information in a chaincode struct that is used in another part of the program to draw the glow mask.

The first time I tested the function this weekend it failed miserably! It caused AROS to lock up and restart. I set up two for loops x & y using width & height to find the control point nearest the top left of the image that part worked. Below that I used a while loop to detect all the perimeter pixels all the way around till it arrives at the control point again. But there was a problem. I had a while loop that was running continuously. So I changed it to a for loop that loops 200 times to collect all the perimeter pixels. 46x46x46x46=184 that should work.

I wasn't sure how to proceed with Detect_Contour but I assume I can use search patterns like I did with Write_Glow_Mask that reads the chaincode. The search patterns use x, y coordinates with Cartesian notation such as x+=1, y+=1 to describe pixel locations related to the current pixel.

Anyhow here I have attached my programming notes for Detect_Contour.

Contour Detection ( Edge Detection) is used in handwriting analysis, character recognition, computer vision and facial recognition.

Freeman Chain Code is also used in character recognition to describe the perimeter of the text characters.

https://www.imageprocessingplace.com/downloads_V3/root_downloads/tutorials/contour_tracing_Abeer_George_Ghuneim/alg.html

A while ago Salvatore had a folder full of new game icon images needing glow borders. I saved those to use for testing. ;-)

If anyone else has any png icon images in the style of Ken's v4 icons that need glow borders feel free to post them here or send them to me. I'll add drop shadows, glow borders and make new .info files for you.

[quote name=miker1264 post=11152]@miker1264

Also, over the weekend I fixed a display issue that involved dragging and dropping images with 32 bit glow borders with varying alpha values. I developed a formula for alpha blending for alpha blending the black pixels in the drop shadows with the background color (153,153,153) but I didn't allow for the colored pixels with alpha values. So I developed a new formula as such. It involves float variables.

In this case bgvalue is 153. Color is the pixel element . Alpha is the alpha value of the pixel we are blending. We have to blend each R,G,B pixel element separately. The alpha blend function returns each integer value one each for red, green and blue. The formula I used is:

float a = ((float)alpha/255.0f);
float value = (float)(Color*a) + (float)(bgvalue*(1-a);
int newcolor = (round) value;

The pixels on an AROS RTG window rasterport are RGB colors which have been alpha blended with the background color.

Reading a 32 bit glow image from the rasterport is more difficult. But if you know the HSL values for the glow border it's easier to decide which pixels have alpha values. But in that case a new formula is needed to reverse the alpha blending before saving the rasterport data to file.[/quote]
Maybe you can consider to provide an integer version of this conversion routine.

Floats weren't used on the Amigas, and since AROS's first goal was/is to be a complete replacement for the Amiga o.s. (WinUAE offers an AROS 68k ROM image, to avoid people using the copyrighted original o.s.), the change might be worth the effort

After a search I found this:

"Key Considerations for Amiga Programming:
Performance: The Motorola 68000/68020 processors often lack a native Hardware Floating Point Unit (FPU). Floating-point math is done via software library calls (mathieeedoubbas.library or similar), making double significantly slower than float.
Memory Constraints: The Amiga has limited RAM (chip/fast). Floats (4 bytes) take less space than doubles (8 bytes), which is crucial for large data structures or graphics.'

AROS already included Alpha Blending in graphics.hid driver.

Cybergrafx Library also does Alpha Blending.

It's good that you mentioned that. At some point I'm going to compile an icon program for Amiga 68k that will use the Alpha Blending formula to draw directly to the rasterport. I'll test it on my Amiga 1200 with PiStorm32 and Caffeine OS. :-)

[quote name=miker1264 post=11174]@miker1264 - After a search I found this:

"Key Considerations for Amiga Programming:
Performance: The Motorola 68000/68020 processors often lack a native Hardware Floating Point Unit (FPU). Floating-point math is done via software library calls (mathieeedoubbas.library or similar), making double significantly slower than float.
Memory Constraints: The Amiga has limited RAM (chip/fast). Floats (4 bytes) take less space than doubles (8 bytes), which is crucial for large data structures or graphics.'

AROS already included Alpha Blending in graphics.hid driver.

Cybergrafx Library also does Alpha Blending.[/quote]
The point is on how you implement it: either via floats (not recommended) or ints (recommended for the original machines).

I will look into converting the formula from floats to ints. But I have to get a few major functions working first before I can do that.

Although previously I used integer math with alpha blending of the drop shadow with the background. So it is possible.

This weekend I'll have time to finish writing and testing the Detect Contours Algorithm. I've been writing and revising it for four days. It's at a point where I can add it to Icon Builder and see what happens.

When Detect Contour is fully working I'll provide a PDF with pictures and examples with source code to explain what it does. I've attached the old PDF that describes Draw_Glow_Mask. It mentions briefly the search patterns using X-Y Transition such as x+=1, y+=1. That is used to describe the test pixel in relation to the current pixel (x, y).

Alpha Blending is also advancing. I found that I only need one alpha blend formula instead of two. I have one for Drop Shadows and one for the colored Glow Borders currently.

I couldn't wait for the weekend to do the integration and testing. ;-)

I integrated the Detect Contour Code last night and I did some testing. There were some compiling errors at first. I used Text Editor and gcc in the shell for testing. The Text Editor isn't very good to revise source code. It messed up indentation and it doesn't have syntax highlighting. Maybe something like Annotate would be better for AROS 32 bit?

Anyhow, the results weren't bad. It compiled correctly. But it didn't do much. It finds the control point which is the start point of the RGB Image. For testing it draws black dots for every perimeter pixels it finds. As you can see in the screenshot it found the control point pixel and another pixel off in La-La Land. My coordinate system is off.

I'll do more revising and testing this weekend to see if I cam get it working to generate the chaincode.

Icon Builder Detect Contour Algorithm is improving nicely.

In the screenshot you can see that it detects all the perimeter pixels along the top edge. It just needs to handle direction changes to be functional.

For testing I'm writing black pixels to all the new perimeter pixel locations.

This is the chaincode diagram I'm using for 8-connected chaincode. The letters along the edge are like directions on a compass. They are ascii characters that represent the direction of travel around the edges of the icon image.

The diagram also represents the directions from the current pixel to the new perimeter pixel. Combined with predefined searches and X-Y Transition codes that is the basis for the Detect Contour Algorithm.

Although Detect Contour isn't complete yet I've attached the source code and a couple diagrams to give you an idea of what's happening in the program. I also attached the log file to see it. It's almost working the way I wanted.

When I implemented the search patterns for directions 'c' and 'e' in the function GetDirection this is the result I got. Notice the black pixels along the perimeter of the image. Since then I have implemented the search patterns for 'g' and 'a' but I will test it later today. :-)

I've very briefly took a look at the code, and I've some comments. However, making a peer review of source codes without a proper tool (Gerrit is my favourite. GitHub is acceptable) is really a PITA. I don't know if AROS uses something to help in those (very common) cases.

I prefer to wait until you publish it, and hopefully there's a possibility to use some tool.

In the meanwhile, and since you've mentioned in the last post, I suggest you to make use of bitmasks instead of strings when dealing with the directions: they are much easier to handle and way more efficient.

cdimauro,

Thanks for your input about using bitmasking instead of the more simplistic string comparison that I was using. I've used bitmasking before while working with ILBM images and Amiga IFF Icons. So I can look at my previous source code to figure out how to use bitmasking.

The Detect Contour Algorithm is working with icon images that have rectangular edges with 90 degree angles. But it doesn't work will all icons images, especially ones with a mix of rectangular edges and oblique edges of 45 degrees. def_Floppy has both 90's and 45's.

The black pixels means that it has detected all the perimeter pixels and it has arrived back at the start point

I'll continue to revise the code and test it this week. Maybe by the weekend it will be working better. I'll revise GetDirection to use bitmasks. The text string "ffttt" can easily be described as 00111 where the 0 & 1 bits represent boolean values of true/false. That only uses one byte.

Detect Contour in Icon Builder is working very well. :-)

It detects all the perimeter pixels for the RGB image and stores them in a chaincode structure. Think of it as a "graphics path".

Here is a composite of a few screenshots to show that Detect Contour is working correctly. For testing it draws black pixels for the perimeter pixels it finds and it draws a white pixel when it returns to the start point indicating that the chaincode is correct and complete.

I'm still having a minor issue. The chaincode text file is missing a few CR+LF line endings for some unknown reason. I'm writing "rn" at the end of each line but it gets left out. But I can use a text editor.

BTW - I'm using ZunePaint to remove Icon Image Backgrounds for testing.

Now that I'm satisfied that Detect Contour is working well. Over the next week I'll clean up the source code and add bitmasking to the GetDirection function to simplify it and make it more efficient. Then I can post the code and a document describing exactly what it does. :-)

Icon Builder Detect Contour Algorithm is almost in it's final form. I've solved the issues with writing the chaincode to the text file. I've cleaned up the source code and I've started to add bitmasking to the GetDirection function to simplify it.

Now I'm looking for irregular icon images to use for testing. These are ones I wouldn't attempt to do by hand such as the Boing Ball Icon which is round, the Colosseum Icon which is oval and a Green Bird Icon as well as the Eagle Icon for Eagle Player. These are good for testing.

To write a chaincode text file for these by hand or to draw the glow masks in a paint program would be very tedious and time consuming. The computer can do it in 1 second. Let's see how well it does! ;-)