It is a complete Targa Datatype with all the load and save functions for 8,16,24,32bit. It also supports Run Length Encoding. It's the result of about 2 years of work on my part. PCX datatype is next. It's almost done. I have to integrate new code.

The old Targa Datatype in contrib is by another author. It doesn't have all the features. My datatype can be added to the repo but I messed up my Build System. I have to delete my sources and redo everything! Oops! I'll save my portsources so that will save a lot of time rebuilding it. :-(

I needed assistance with some of the Git commands but everyone else was busy. So I tried it myself and I messed up my cross compiler. But now I know what NOT to do. ;-)

My new Targa Datatype has the AROS License. I'll provide the 32bit version also. I haven't had time to upload it yet. The 64bit datatype is in Datatype/Image on AROS Archives.

Thanks for your work! If the new targa_datatype is an improvement over the one in the contrib package, maybe it would be worth submitting the code to the repository?

The New Targa Datatype 64bit version for ABIv11 has been uploaded to AROS Archives. It's in the Datatypes/Utilities location.

It should be available sometime today. I intend to install the Build System for ABIv1 as well as soon as I update the SSD on my development computer. I only have 15GB free. I have the m.2 SSD I need to clone my drive this weekend. I also, intend to to have a Build System for Aarch64.

Then I can start compiling for AROS Pi for Raspberry Pi. I recently bought a Raspberry Pi 400 for testing & fun!

Here's a short update:

The Targa Datatype is going through some testing on AROS One 64bit. In order to test the save functions I'll adapt my Pixel View application to use Save As the same as MultiView.

I haven't compiled my updated MultiView for x86-64 yet. I'm still working on it. Maybe soon though.

I was considering how difficult it would be to write a MIDI Datatype as AMIGASYSTEM suggested earlier. I'd also like to write an MP3 Datatype but I don't know much about Sound Datatypes. Now is a good time to learn about those things. :-)

Compiling Targa Datatype for 64bit.

See my previous posts for the 64bit version of Targa Datatype.

Here is the test package for Targa Dataype and
MultiView compiled for x86. The x86-64 version
will be available in a few days.

Here is the newly compiled but not yet tested Targa Datatype.
It has been compiled for x86-64 using the new Build System
for ABIv11 running in my new VMWare Workstation Pro 17.
The 64bit Targa Datatype compiled without errors on 1st try.

I will also include the x86 version compiled earlier & MultiView
compiled for x86. That archive also contains Targa test images.

I will prepare a new test package with MultiView compiled for
x86-64 as well in a few days.

Grazie Miker!

I installed PCX and Targa on the i386, thanks

The PCX Datatype code is done and I'm ready to start testing it before I post it to AROS Archives in a few days. This is the first version. There will be more updates for it later.

Probably, the next task for me concerning Datatypes will be to update ILBM datatype & Picture Datatype to use run length encoding when saving, and I'll look into HAM6 / HAM8 conversion from 24bit when saving ILBM images. ILBM datatype is also missing the Save_RGBPic that saves 24bit ILBM deep images.

It's all on my ToDo List. :-)

If you're interested, I'm still working on updating PCX datatype.

I'll do some work with 64bit this weekend then I'll post both TGA & PCX 32bit & 64bit on AROS Archives.
I'll post the source code as well.

Another thing, when you are using local AI agents, they can scan complete AROS codebase in a few minutes and give me an answer on how certain behavior works and what are it's depencies. I used to do this by hand and it was taking much longer and I was missing certain edge cases. This is a big time saver.

With regards to AI assisted code generate: for me it's a tool like any other. As long as you take the generated code and you actually understand it and extend/fix it further, then it's not different than automated snippets generated by IDEs - it just much larger scope. The rule is the same - you need to uderstand the code you write/generate.

I integrated the new WritePCX_RLE function for run length encoding. It's based on a sample from Copilot AI.

I expected it to need to be fixed as far as compiling errors but the code compiled and it worked. The code is smaller and more efficient than mine. I must have spent six weeks working on pcx rle encoding. The Copilot version only took a few days.

So now the ReadPCX_RLE & WritePCX_RLE functions are both based on Copilot AI sample code.

I'm not sure how other people feel about this subject. But AI assisted coding could significantly speed up development time! If nothing else the research possibilities using AI speed up the process tremendously.

In the past while searching for information about aros coding I usually didn't get anything about aros specifically. But rather I ended up searching for the Amiga version hoping that it was similar enough. Now using Copilot the responses are all AROS based information! Nice!!

Over the past few days I copied the pcx write functions from my old pcx datatype sources from a few years ago. It is functional and it loads & saves 8bit & 24bit rle compressed pcx images. But the code needs to be cleaned up & revised next week.

For example WritePCX_Line uses bit depth to prepare either 8bit indexes or 24bit pixels then calls WritePCX_RLE. It should be split into two functions: WritePCX_LUT8 & WritePCX_Truecolor. Then code can be added to write 1,2,4bit planar pcx.

There's still much work to be done!

So that you can see what is going on inside the pcx datatype here is the source code for my new read functions. It looks nicer & cleaner.

It's layout is based on AROS PNM datatype & my new Targa Datatype.

The includes & initial layout is from PNM datatype. The Read functions themselves & many of the D(bug) statements are copied from Targa Datatype. Hopefully I have converted them all to PCX Datatype;-)

The individual pcx_color & pcx_header structs are from samples. The Read RLE function is based on a sample provided by Copilot AI about how to decode PCX RLE (byte level run length encoding).

It all works together nicely though. I've already prototyped all of the Write functions as well. But I need to copy them from my old PCX Datatype sources then clean them up and rewrite them.

In the previous screenshot & in several other test images there's a small region of distorted pixels in the top left corner. At first I thought it was because of padding bytes. But then I discovered the problem.

In the two new screenshots you can see the layout of the struct PCX_Header which consists of 128 bytes. But I wasn't reading the last 54 bytes because it's all zeros. But that's what caused the offset errors.

I had to use the Seek command to set the file pointer to skip the last 54 bytes to arrive at the beginning of the image data. For 8bit images the ColorMap also immediately follows the image data. On the previous attempt the 24bit images had artefacts & 8bit didn't load at all.

After skipping the unused bytes in the header the images, both 8bit & 24bit loaded correctly! So, now the Read functions are working nicely.

Over the past week I have spent some time re-writing all of the Read functions of my PCX Datatype because I want to use it as an example for an instructional PDF about "How To Write Datatypes".

I revised all the functions used to read 8bit & 24bit PCX images. I also completely revised Read RLE to the extent that when I started to compile it I didn't expect it to work without a lot of error fixing & troubleshooting.

There were many small compile errors of course such as undeclared functions or variables, missing parentheses, etc. But after a while it compiled correctly! Nice start. :-)

But I still didn't expect it to work.

So here's the first screenshot of the new PCX Datatype in action...almost working!

I'm currently revising some of the read functions for my PCX Datatype.

It's actually going quicker than I expected. The write functions need some cleanup & revision also. We may have another new datatype in a couple weeks if all goes well.

I wrote the majority of my Targa & PCX Datatypes about three or four years ago when my programming skills were still under development. The code is so messy!! But it works!

Some Datatypes, and other software have copyrights from other developers not AROS Development Team. So their source code is located in Contrib not Main.

why datatypes are not in aros official repository?

For my next datatype projects I'm looking into MIDI Datatype, MP3 Datatype and revising my PCX Datatype. I've started JNG, MNG.

In the process of rewriting my PCX Datatype I plan to write an instructional PDF about writing Picture Datatypes. Later I may expand to Sound & Text Datatypes.