New Picture Datatypes

[miker1264]

Actually, it wasn't difficult to modify JPEG Datatype to Save 8bit B&W images. It only took a few hours. 

Here is the 64bit version and the source code.

I will compile and test the 68k version tomorrow then upload it as well for testing.

[miker1264]

I've been a little busy in the past couple of weeks building a new computer and rebuilding a couple laptops. Whew! 

More AROS work coming soon.

[miker1264]

Testing the 32bit version of the updated Jpeg Datatype on x86-64...

[miker1264]

Here is the results of compiling the "official" Linux x86_64 jpeg datatype...

Other than the increased version number 41.2 there is no difference. That means it compiled correctly. 

[salvo]

thanks miker

[miker1264]

I'm finishing up modifications to Jpeg Datatype.

Started adding LoadTarga & SaveTarga for new Targa Datatype.

My SaveTarga function already works for 24bit images. So I will expand on that to add more bitdepths. Working on LoadTarga.

After completing Targa Datatype I'll take on the task of writing a new PCX Datatype. The PCX RLE (runlength encoding) is a bit tricky to implement. But again SavePCX is already working in one of my test programs. So I'll expand on that as well.

I still have to add Load/Save 8bit images to Tiff Datatype. Ultimately for Tiff Datatype I'd like to convert it to use an internal decoder to remove dependency on libtiff, reading/writing tiff.

Ultimately I plan to update the SaveILBM function in ILBM Datatype based on my recent work on DT_Write in Picture Datatype. Did I miss anything??

Much work to do. 

[salvo]

 

[miker1264]

I've been working on my new Targa Datatype over the last few days. It's coming together nicely.

The updated Jpeg Datatype Save function is ready to upload. That one will be available soon.

[AMIGASYSTEM]

Thank you

[miker1264]

The new Targa Datatype is almost ready.

It can load and save 8bit, 24bit & 32bit targa images.

I'm working on functions for loading & saving 16bit targa.

[miker1264]

While trying to write code to support loading 16bit files for targa datatype I realized two things. First, I've never tried working with 16bit so I know very little other than bit shifting is required. And second, I didn't have any valid 16bit targa image data for testing.

I discovered that there are two basic types of 16bit rgb data. There is rgb555 and rgb565 respectively. Apparently targa uses the rgb555 variety where red, green and blue are each 5bits. The remaining 1 bit can be discarded during decoding.

So I had the basic method but no sample data. Then I realized two things. Windows bitmap images can be 16bit and our bmp datatype can decode 16bit data. However, bmp is supposed to use rgb565.

But I had a graphics utility that could import and export a few image types but it provided bitdepth and conversion options. For exporting 24bit bmp it provided 3 options: rgb555 or rgb565 or 24bit. So I chose to export the 16bit bmp as rgb555 to match the supposed targa format.

When importing 24bit then exporting targa no options were provided. It simply saved 24bit targa. But when I imported the 16bit bmp I just converted then tried to export as targa it gave the same three options as for bmp. So I chose rgb555 to be consistent.

So here's the interesting part if you enjoy this type of thing. Using my favorite hex editor I compared the two files. The 16bit pixel data was identical. So now I could make 16bit test files.

Microsoft provided some code for converting 16bit to 24bit rgb. Now the rest is just writing the 16bit conversion code then inserting it into the datatype and testing it. Fun stuff. 

BTW it seems PaintDotNet can't display 8bit and 16bit targa images correctly. It forgets to swap the red and blue pixel elements per scanline for 16bit to make BGR into RGB. For 8bit it also fails to swap red and blue for colormap values with the same result. The images appear blue or oddly colored. But GIMP displays 8bit and 16bit targa images just fine. And soon our MultiView will display them as well using the targa datatype.

[miker1264]

Here's something else that is interesting if you're into c programming, although it's a little geeky!

As noticed with PaintDotNet even for 16bit pixel data we must remember to swap red and blue pixel elements for targa and bmp formats or the colors will be wrong when they are displayed.

Microsoft provided direct conversion code to convert 16bit pixels to 24bit pixels. It uses WORD masking and a WORD pixel. But first the data must be in a WORD array.

According to my research in order to convert 2 bytes to WORD we do this:

short val = ((left_byte & 0xff) << 8 ) l (right_byte & 0xff);

But the code in the AROS bmp datatype to convert 16bit to 24bit is slightly different.

It starts with:
WORD pixel;
pixel = *(buf1)++;
pixel l= (*(buf1)++) << 8;

So it is using WORD = right_byte l left_byte;

It swaps the bytes while bit shifting. So that when converted from 16bit to 24bit instead of a direct conversion to BGR it becomes RGB.

Even for 16bit data you swap the bytes before or after conversion but don't forget to make BGR into RGB.

The bit shifting and swapping method seems more elegant. But this is all theory till I actually test it. 

[salvo]

thank you miker for your effort

[miker1264]

Hmm...

Loading 16bit Targa Image...almost.

Someone forgot to flip the scanlines! 

Oooops!!!

[miker1264]

Ah...much better.