I have used Copilot AI recently, mostly for research to help understand certain concepts. It also provides useful code examples that actually work when included in my application and when compiled. I used it for gaussian blur research.

It does speed up the development process because I don't need to search the AROS programming database or OS4 documentation for programming. I just ask specific questions to get specific answers.

I hadn't heard of Vibe Coding before. I'll look into that. Anything that speeds up the coding process whether it is assistance with research concepts or actual code examples is a bonus! It's beneficial.

Vibe / AI can help a lot improving the productivity, but I recommend it only to experienced people.
The most important thing for a developer is to exercise, practice, and develop a good mindset and knowledge-base.
After that, a bot can multiply the productivity.

The only issue with AROS programming is that it takes soooo long to develop source code that does anything useful. It's very time consuming and people just aren't willing to commit themselves to it.

It may take several months or even years to develop useful source code. One advantage would be to produce source code that can be re-used for other programs or system files. That's where I am now with my projects. Much of the code can be re-used to be included in new apps.

Although my programming skills are improving there are some things I still need to learn. My annotation in my source code has improved. Now I add notations and cleanup code and fix indentation as I go. I used to wait till the end, but that never gets done! It's too much to do at the end.

There are several things I need to learn to get better at programming. I have to get much better at using GitHub. I need to gain experience writing device drivers whether for sound or graphics or peripherals such as USB or Serial connections. I also need experience writing or updating system libraries. Picture Datatypes, in a sense, are simplified libraries so I have a good start there.

Hint: there is a UART driver for AOS4 that I'm looking at. I'd like to implement something like "Waffle Reader" for AROS using USB-Serial with Poseidon USB implementation.

AROS would have achieved all the goals it’s been dragging its feet on for years long ago if the ‘junior’ staff had been able to do all this.

Thank you for your valuable work!

cdimauro,

Thanks for the programming information. I still consider myself a junior programmer in some respects although I'm getting better.

At first I just wanted to get the application working to post it and share it here. I'll update it with the ideas and information you provided.

To be honest, I don't understand some of the terminology such as mantissa, although I can look at the code to improve it as you suggested as far as the variable types, etc.

I had intended to spend the next two weeks trying to tweak and improve the addshadow application to allow it to produce images with borders that are closer to the original. I'll incorporate some of the things you mentioned at the same time. I'll also be working on the addglow application as addshadow and addglow are similar in construction but slightly different as far as code.

For example addshadow uses the input image to construct a shadow mask composed of black pixels with a transparent background. But addglow uses the input image to build a colored Glow mask. It also applies post processing to adjust Saturation and Luminance.

I've not enough time to check all source. I share some quick comments.

Any reason for using both int and long?
Is long supposed to be 64-bit (I don't recall AROS's ABI for 64-bit system)? If yes, then better to use int instead of long where applicabile (for example, you used long for Width and Height, but you use int for Ctrl_X and Ctrl_Y which should similar size).

Try to better align big array structures where you make iterations. IconImage.ImageData, for example, has an odd width (143) which results in rows not being (at least) 16 bytes-aligned (SIMD architectures have at least 128-bit -> 16 bytes registers, but 256-bit are common, and 512-bit are spreading around). Compilers can vectorize code to make the loops executions much more efficient, IF they can recognize proper alignments.
Another example is ChainCode.Code which is oddly aligned by itself (e.g.: 3 32-bit values defined before it).

You can also give the proper type to some data elements and shuffle them to properly pack, saving space. IconImage.Depth could be unsigned char, and NumColors an unsigned short, so that they could take 32-bit space in total (counting the implicit padding used by compilers to align the next field in the structure, which is at least 32-bit). Transparency could be moved to after them to "complete" this sequence of fields (all together they will take 16 bytes at least, beforeImageData).

RGB is a duplicate of IconPalette.

In general, you might consider the usage of single instead of double for colours manipulation: it takes much less space, should be much faster on SIMD architectures (doubling the number of executions) and its precision should be enough to handle all transformations (colours use 8-bit of precision and single has a 23 bit mantissa: a good match).
You can also define a typedef for the type, so that you can easily change it in future (e.g.: half float precision might also be a good fit. But it needs some experiments to see if its mantissa could be enough).

Here is the cli application "addshadow" which adds a shadow border to the first icon image. The first image must have the background removed (transparent) by making all background pixels black (0,0,0) with alpha also set to zero.

The syntax for the program is:
addshadow OldImage1_Tile.png Composite_4.png which will generate a shadow mask and combine it with the image tile to produce the finished output image.

Composite _4.png is the output image. OldImage1_Tile.png is the input tile image with no background.

Yes. I spent the last two weeks making the functions abstract and portable so they can be used by other programs.

It uses two IconImage structs im1 & im2 as containers to hold width, height, depth and argb pixel data. The im1 struct contains the icon image with the background removed. The im2 struct at first contains a copy of im1 but it holds the shadow mask or the glow mask. At the end the image in im1 and the mask in im2 are combined.

If you abstract enough the functions, you can create a library for general image effects, that other programs then can use.

It's better to develop the code to add shadow borders and glow borders in small cli applications than a larger program such as Icon Builder. It's easier to debug a small application.

After some code cleanup I'll post the addshadow cli application later today or tomorrow at the latest with some sample icon images, source code and a brief set of instructions.

The addglow cli application is next. It's almost done. I just have to add a few more functions then it's ready.

The addshadow command line application is complete. Now I have to do some testing then after that it can be released along with the source code.

The addglow application is almost complete and it is very similar to addshadow. Same concept except the mask is different - glow mask vs shadow mask.

As you can see in the composite image the addshadow app can programmatically produce a 1:1 black shadow mask using the sample code I posted earlier. It produces a shadow border from it and it saves the output image.

In order to finish addshadow I just need to add one more function to remove the outer perimeter of pixels from the shadow mask to make it the correct size. Then offset it x+1,y+2 instead of x+1,y+1 currently.

Here is the proposed code to draw the shadow mask programmatically and to do a -1 pixel inset around the perimeter and then offset it 1 pixel to the bottom and 1 pixel to the right.

It seems so easy to do the same thing in a paint program. But it involves a lot of computer code!

Here is the Shadow Border Comparison after testing.

This time the image on the left is the original def_Picture1.png with the original shadow border.

The image on the right was produced from the new black shadow mask and gaussian blur with 9x9 kernel size and 16.0 sigma.

They are very similar!

Now I have to produce the black shadow mask programmatically. Then "addshadow" cli app is done!

I have considered how to accommodate larger icons. Icon Builder display area is purposely large enough to display 46x46, 48x48 or 50x50 size icon images.

The 46x46 are the original v4 PNG glow icons. The 48x48 are larger square-round button icons, and 50x50 are the Square-round Faenza type icons. For the 48x48 I thought about doubling up one of the color bands for the glow mask. For 50x50 I would double up two color bands.

For the glow mask there are three color bands starting at the inner band which is white, then yellow, then gold on the outside. The 48x48 color bands would be white, yellow, gold. The 50x50 color bands would be white, yellow, yellow, gold. The glow mask is the only thing that changes. The rest of the program code doesn't care what size the icon is. It just processes images.

Maybe this weekend I can experiment with some larger icons.

@miker1264 have you considered that 1-2 pixels border might not be enough for big icons?
Nowadays we've (very) high-res screens compared to the original one (640x200 / 640x256) that we had at the Amiga time, so thin border might be very less visible.

So I'm working on two command line applications for AROS users to enjoy! ;-)

One is called addglow and the other is addshadow. You can guess what they do. I have reposted the previous images with glow borders. The image on the left wasn't produced by Icon Builder rather Addglow made it.

They are both at about 80% complete. I can provide a pre-made glow mask or shadow mask and an image tile with the background removed. The programs provide the blur and make the composite images. I'm using them now. :p

In a week or two both will be done. The finished versions will make the masks from the input image and perform all the steps to make the composite images for glow/shadow.

Now that I'm feeling confident that the processes and methods for adding a glow border to the second image is working well I decided to try something new. ;-)

For the past few days I've been trying to come up with a method or maybe better to say "the secret formula" for adding a shadow border to the first image in an icon.

When I talked to Ken a couple years ago his methods to produce glow borders I purposely didn't ask about how to produce shadow borders. I assumed it wouldn't be as difficult as adding a glow border but it may use similar processes. Also, I wanted the challenge of going it all myself.

For adding a black shadow border a few assumptions can be made. Similar to adding a glow border we start with a black shadow mask. We also apply the "blur effect" and then make the composite image. But there are still many unknowns.

Two days ago I made a black shadow mask which is just black pixels that take the place of the RGB image in the middle of the icon image. The background of the mask is completely transparent. The black mask was 1:1 the same size as the RGB image. I assumed it had to be offset to the bottom and to the right but I didn't know how many pixels. So I did the minimum. It was offset 1 pixel to the bottom and 1 pixel to the right. Then a blur effect was applied.

For the blur I used the gaussian blur I already used for the glow border but It needed different settings. I tried a kernel size of 5x5 and sigma value of 1.0 which was very similar to what I used for the glow border. But the first attempt for adding a shadow border two days ago failed!

The blur intensity needed to be much greater than for a glow border! Yesterday I tried again. I did about six composite images with shadow borders with various kernel sizes and sigma values. To my surprise the last settings for the gaussian blur produced a blur that almost perfectly matched the shadow border on the first image of def_Picture. But it wasn't perfect. I used a gaussian blur with a kernel size of 9x9 and sigma value of 16.0

After analyzing the test results and comparing alpha values I realized my black shadow mask needed to be adjusted. It has to be -1 pixel inset from the perimeter on all sides. Then it must be offset 2 pixels to the bottom and 1 pixel to the right to be the correct size and in the right location for the blur effect to work.

I have attached the black shadow masks that I used for testing. The larger one is the 1:1 mask which is incorrect. The smaller one is correct. Now more testing and more image composites to compare! :-)

I'm getting a little bit closer to the desired result.

The glow border on the left is produced by Icon Builder. The glow border on the right is produced by Photoshop CS4.

Although the Detect Contour Algorithm is finished and it's working very well development on Icon Builder continues.

This week I'll focus on the Gaussian Blur Algorithm for the "blur effect". It's working already but it's not perfect. The outer color band of the glow border is too light. Some post processing is needed to adjust the saturation using Hue, Saturation, Luminance (HSL) to make it visible.

Next week I'll focus on Change Glow Tint that uses HSL to do a Hue Rotation to change the tint of an existing glow border to neon green, neon blue, neon red, orange and purple. Only the glow border tint changes. The RGB image in the middle remains unchanged.

In the screenshot the image on the left has a glow border produced in Icon Builder using the "blur effect". I adjusted the saturation of the outer band manually. I'm working on the computer code to do the same thing. The image on the right has a glow border produced in Photoshop using the "blur effect". I'm satisfied that the images are very similar. :-)