Success! Adjusting the WriteRLE line length using "width" instead of "width*2" solved it. Now it works great when saving Targa 16bit RLE.

Now to fix 8bit RLE.

Here you can find the latest releases for 32-bit version:

https://axrt.org/downloads-aros

If your testing environment was based of 20220318 release then there is an update package there to the latest release.

@deadwood

Thanks for the links. I will do an update for my system files today or tomorrow.

Now it's time to archive the datatype code that is now working correctly and enjoy the moment! 😁

Then back to work to finish up the new datatype. It's fully functional but I have to re-write parts & clean it up.

Actually, My WriteRLE function in Targa Datatype is working great !

At first I thought there was an error in the RLE conversion because the program I was using to make RLE compressed test images wouldn't open the newly encoded 8bit files.

Pixelformer kept saying "Invalid Data". But Photoshop CS4, Gimp and PaintDotNet and even MultiView had no issues with the new 8bit RLE file.

So it seems my new Targa Datatype can correctly encode RLE for 8,16,24,32 bit images!!

The screenshot shows MultiView using Targa Datatype opening the newly compressed 8bit RLE image.

Pixelformer has some strange RLE sequences that are an RLE variant rather than PackBits. For example it writes a sequence similar to this: "04 AA BB CC DD.EE 00" where my WriteRLE function does this: "05 AA BB.CC DD EE". Pixelformer adds a zero as a padding byte at the end.

It's not standard RLE but it can be read by Targa Datatype. It has no problem using ReadTarga to decode the non-standard RLE sequences. Pixelformer, however, is very picky!! If it's not the format it expects it says "Invalid Data" for the 8bit RLE.

The other screenshot is my current version of 32bit AROS Native. I'll update my system files. Also, I plan to install AROS One x86 and x86-64 in a virtual machine for testing.