OK Thank you

Here is a version of TiffInfo & ViewTIFF that are working. Both programs are using Tiff Library.

Thanks miker it works well, can Tooltypes be used as a default tool in the future, or can PixieView do it?

You can use DefaultTool to open ViewTIFF to view TIFF Images but this is just a test version with messages that need to be removed for the official version. I'm using ViewTIFF to test TIFF Datatype. So far the Datatype is falling. I have to find the working source code on my ABIv1 Build System. I have a working 64bit Datatype but I don't know which source code it relates to.

Although my picture tools and icon tools projects are fun to work on it's time to do some work that will benefit more of the AROS users. :-)

I'll be updating Datatypes for the next few months. I'll still work on my personal projects from time to time.

I decided to start with the updated Targa Datatype. It's nearly finished.

The Targa RLE compression for 24bit & 32bit works but 8bit & 16bit aren't working yet. Once I complete the RLE compression then Targa Datatype is completely done then I can commit the changes.

The PCX Datatype has also been updated & it works but it needs some serious code cleanup.

Both Targa & PCX will be compiled for AROS x86 & x86-64.

After the updates for these two I'll re-write my TIFF Datatype by adding an internal TIFF decoder/encoder. So it will be independent of LibTIFF.

In between, when I can find time, I'll attempt to update two Amiga 68k Datatypes by adding save functions.

Other updated or new Datatypes will follow after that if all goes well.

This time around no datatype is safe! ;-)

The ILBM datatype currently only saves two different types of images. When I wrote the Save Function(s) I intentionally used a main function & two sub functions. But originally there were going to be three!

Save_ILBM is the main save function. It looks at the bmhd of the datatype to decide which of the sub functions to use. Currently it can choose either "SaveBitmapPic" for 8 bitplanes or below or "SaveRGBPic" for 24 bitplanes. But I wanted to add "SaveHAMPic". I have written the new function and it's on one of my flash drives that I use for sources.

In theory, in order to save as HAM6 or HAM8 a few things are needed. The pixel data in the datatype must be 24bit RGB. Also we have to copy the HAM ColorMap to the datatype. Lastly, we must modify the bmhd for numcolors & depth to reflect that it's not standard ILBM; It's HAM6/HAM8. Then save the ILBM.

Looking at the current sources for ILBM datatype it seems "SaveRGBPic" is missing. I'll add that as well to save 24bit Deep Images.

Also JPEG datatype might need some updates for JFIF, JPEG2000, JPEG XL, XR, XS, XT, JPEG-HDR or as much compatibility we can add.

Hmmm...

It seems that TIFF Datatype is already in the source code repository. But it also seems that the SaveTIFF function is missing.

However, I have SaveTIFF in my original sources to save a 24bit TIFF file with a single directory (1 image). I can add SaveTIFF to the datatype.

But before I do that I have to update my Build System. I changed computers so it's an all new setup.

Many thanks for this; Datatypes are one of the things which make Amigaoid systems special. I get so frustrated at work when trying to open a picture file or play a video and have to hunt around for a program that can handle that particular format.

Cheers,
Nigel.

Thanks Nigel.

I started my AROS programming years ago it seems updating, fixing & writing Datatypes such as BMP, ILBM & Picture Datatype. You're right, Datatypes - picture, sound & text are the most widely used & most important system component.

Great work as always, miker, is there a 64-bit version of PixieView available?

Regarding Datatypes, Midi.Datatypes isn’t available on AROS systems; the source code is on Aminet, but I haven’t been able to compile it.

https://aminet.ne...ype/MidiDT

AMIGASYSTEM,

In the next few days I'd like to refresh my AROS Build Systems to get them ready to compile Datatypes for 32bit and 64bit. At that time I'll compile the current PixieView for both AROS 32bit and AROS 64bit.

I plan to do some updates for PixieView after that such as adding Color Count, Display ColorMap, Color Histogram and some Graphics Effects. Most important, there will be a new display method to make it compatible with Amiga 68k/AROS.

As far as MIDI Datatype I think I downloaded the sources. I'll take a look at it and try to build a datatype for AROS. Do we have an MP3 Datatype? If not it would be nice.

By the way, I was looking at my source code for Targa Datatype last night to see why Targa RLE wasn't working for 8bit and 16bit images. It seems odd that Truecolor 24/32bit works fine will Run Length Encoding.

My WriteRLE function was designed to be very generic using bpp (bytes per pixel) such as 1,2,3,4 that deals with 8bit, 16bit, 24bit and 32bit respectively. If it works for one it should work for all bit depths.

WriteRLE wasn't the problem. For WriteRGB16 I get the 24bit pixel data from the datatype. Then immediately after that is WriteRLE which is wrong. I was trying to use RLE encoding on the 24bit scan line. I have to convert the scan line to 16bit first then use WriteRLE. There were a few more issues that I fixed also. I haven't compiled it to test it yet but I'm confident it will probably work.

I'll post some screenshots later today to show my progress so far.

There is a data type for MP3s on Aminet called ‘mpegadt’, but there are no source files!

https://aminet.ne...pegadt.lha

It would be nice to play MP3s with Multiview, but on AROS it’s no problem to play MP3s – there are several players available, including MPlayer

Last night I did some compiling and testing for Targa RLE compression.

The RLE for 24bit and 32bit works. But not for 8bit and 16bit. In the screenshot you can see the banding. The same was true for Truecolor before I fixed the WriteRLE function.

Although RLE compression isn't fully working I plan to move forward with releasing the Targa Datatype. Once it's in the repository it can modified.

Hmmm...

I noticed that the banding effect for the Targa RLE 16bit image was very interesting, very regular. So I opened the image in PaintDotNet then zoomed in to see what it looks like!

In the screenshot you can see that it looks like basket weaving. :-)

Every other scanline is filled with junk. So I meticulously copied each good scanline to a new image to see what emerged.

In the second screenshot the first ten lines at the top are copied from the banded image. The rest was spliced in from the original. They match up perfectly! Every other scanline in the banded image is good. The alternating scanlines are simply filled with junk pixel data.

I suspect I know why. For the Targa Images the first scanline is at the bottom of the image because it has a Bottom-Up Orientation like Windows BMP. So in order to read the scanlines from the Datatype Object we should use "yoffset" instead of just "y" and the first value is "int yoffset = (height - 1)". After that each increment is simply "yoffset- -" to read up the image not down. But for some unknown reason WriteRGB16 currently uses "(y * height) - 1" every time we grab a scanline. That's wrong!

So I'll makes some changes then recompile the datatype and try again. I'm using PictureDT Creation Tool because my 32bit and 64bit Build Systems have an issue. :-(

@deadwood
When I compile a program with my Build System then try to run it AROS has an error such as "stdlib is missing". Does that mean my sources and tool chain pre-date the clib change and updated? Or my test environment pre-dates the change?

It rather suggests your test environment is missing the libraries that yor build system compiled the binary with.

@deadwood

Thanks for the information. This weekend I'll refresh my sources for ABIv0 and rebuild the toolchain and rebuild AROS.

With my old Toshiba P775 laptop with mechanical hard drive it took about 3 hours. Now I'm working with a new desktop with a fast SSD so it should take about 45 minutes.

Is there an update package for 32bit system files? How do I update my testing environment?

I found ABIv0:
AROS 20220318-1-U3-any-i386_Update.zip but All others are x86-64 updates and iso's.

Actually WriteRGB16 uses "height - y - 1". Which seems correct now that I think of it.

What a conundrum! The same code works perfectly to save 16bit images. But with RLE every other line is correct and the alternating lines are filled with junk pixels.

Hmmm...
I think I found the problem.

It's not how I read the data from the Datatype obviously because that works fine to save 16bit without RLE. But instead when I send the 16bit scanline to WriteRLE instead of width I was sending bpr which is (width*2). The length of data is twice the length that it should be so it writes junk in between. Sometimes it's just small mistakes that cause such big problems!