AROS Picture DataTypes

[salvatore]

thank you i undenstand again 

[Samurai_Crow]

but you're basically fixing the datatypes and also creating new

The short answer is YES.

As far as Picture Datatypes I'm fixing what needs fixing and adding Save Functions where needed with a special emphasis at first on fixing up BMP datatype and ILBM datatype as I was directed to do about a year ago.

As for JPEG, TARGA, PCX datatypes out of respect for other developers I would ask the original authors if they intend to fix them or if I may be permitted to do so.

As far as problems with Datatypes Library like the one I found reading 'RGBA' when I have time I have a good chance of finding the problem now that I have witnessed its effect.

Because everything takes time and I have spent over 40 hours on BMPX datatype alone I am going to release it as it is tomorrow then go back when I have free time to try to find the problem in the libraries to fix transparency using 'RGBA'.  😊

Tomorrow I'll start fixing ILBM datatype to add Save ILBM functions. That will be fun!

That's the LONG ANSWER.

Converting a long from ARGB to RGBA takes only a bit rotate opration per pixel.  Internally GCC converts src<<8|src>>24 into a single opcode on long variables.

[miker1264]

Samurai_Crow,

I wish that converting ARGB to RGBA was the main issue.

In the Datatype Object in order to get the pixel data from the bitmap we use PDTM_ READPIXELARRAY and PDTM_WRITEPIXELARRAY.

Using these functions with PBPAFMT_ARGB works fine. Using them with RGBA causes errors.
It may be caused by an internal problem in one of the libraries. I suspect I should start looking in Picture.datatype Library. Not sure at the moment.
So far I have located ReadPixelArray & WritePixelArray functions and I am looking at the two functions to see if there is a copy data problem.
It may take a little while till I identify what could possibly cause the alpha values to all be set to '0xff' but I'm getting closer to the truth.

I suspect it is an initialization error then failure to copy the real alpha values.
For example, in ReadPixelArray: (notice the initial value for alpha is 0xff).
/* Copy picture data pixel by pixel */
    UBYTE r=0, g=0, b=0, a=0xff;

The good news is that everything else in BMPX picture datatype is working including the Load and Save functions for BMP and BMPX.
The only thing not working is alpha transparency until I figure out exactly why it isn't displaying correctly. But I'll solve that problem.

But I know how to create a cool blue neon effect. Just copy 'FF' (255) to all the Blue Values.

[miker1264]

I have successfully compiled the ILBM Picture Datatype from sources.

I put together a new makefile.ilbm and had to add -liffparse before it would compile.

Now I can proceed to Write the Save ILBM Function. I added "Save_ILBM" to "ILBM__DTM_WRITE" method.
I also added my Save_ILBM function which directs traffic to one of two subfunctions based on bitdepth.

The first subfunction to be included will be SaveBitmapPic which will save ilbm images <= 8 bitplanes.
It's easier to implement in the datatype because it uses a method I used called "Copy From Bitplanes".
SaveRGBPic will be the second subfunction linked to Save_ILBM which will save ILBM Deep Images.

[salvatore]

well miker

[paolone]

@Miker
Thanks for the sources. In the next days I will try compiling them for x64 AROS. I may ask your collaboration to create the right metamake file (mmakefile.src) for it.

[miker1264]

@Miker
Thanks for the sources. In the next days I will try compiling them for x64 AROS. I may ask your collaboration to create the right metamake file (mmakefile.src) for it.

I will do what I can. Hopefully I will finish the save functions for ILBM datatype in the next week or two. That will be good to Save As IFF.

When I have some time I will do more testing on Icaros Desktop Native to test for stability.

I'm using the same datatype descriptor for bmpx as with bmp. At first use when opening bmpx files you may get "unknown datatype". 

Just open a standard 8bit or 24bit bmp file then it will work as expected. Bmpx takes the place of bmp which could only Load images.

As for compiling for 64bit, Yannick says that the 64bit version of his picdt creation package may be included in the latest 64bit builds for AROS. So you can just follow his instructions and use makefile.bmpx to compile outside the build system. I suppose an mmake file is needed when building inside AROS sources.

[miker1264]

@paolone

I will post updated source code for bmpx datatype later today. Not sure if I included makefile.bmpx in the last one. It's new to me.

I have most of the source code for picture datatypes that need some attention. But where can I find sources for the TARGA Datatype?

[miker1264]

I was having difficulty getting PCX datatype to actually Save Something!

After taking a look at the Source Code for PCX, this may be part of the problem...there's no Save Function.

static LONG WritePCX (Class *cl, Object *o, struct dtWrite *msg) {
   return ERROR_NOT_IMPLEMENTED;
}

The original PCX datatype was written by Fredrik Wikstrom.

I'll check his website to see if his newest PCX has a Save Function, if not I'll make one based on my own Save_PCX.
When everything works correctly to Save PCX Files, I'll send it to him and include it in a revised PCX DataType file.
(I also believe that the INFO Datatype needs a Save Function if possible to accept two images & save an iff icon file)

//======================================================================//

Here's my Save_PCX Function. Notice all the code that is commented out. It's a little rough but it works!
I'll make it more "picture datatype-ish" & then make it into a datatype save function for the pcx datatype.

[miker1264]

As far as JPEG datatype, if you haven't seen an 8bit jpeg file...here's one made in Photoshop CS4.

Revising jpeg datatype to Load 8bit & 24bit involves a few things.

1. The bitdepth is automatically being set to 24bit without checking the actual depth to detect 8bit.
2. For 8bit the Pixel Format should be set to: PBPAFMT_LUT8.
3. For 8bit a method is needed to export the Color Palette then convert it to ColorRegister, CRegs.

The first two are relatively easy to accomplish. The last part will take some research to sort out.
An 8bit JPEG most likely has an 8bit Thumbnail image with a corresponding 256-color palette.
Is the Thumbnail always present in 8bit jpeg images? Does an 8bit jpeg have its own palette?


So after a few small revisions JPEG DataType should be able to Load 8bit Jpeg files as well as 24bit.

[salvatore]

good job miker

[miker1264]

good job miker

But I have only just begun with JPEG. 😊

(Actually I have never worked with JPEG)

[miker1264]

As far as 32bit BMPX with Alpha Taransparency I did mention I was working on it...

I've been thinking about the Neon Blue BMPX file that I somehow displayed on screen. I wasn't smart enough at the time to stop and archive my project. So I was going to try to reproduce the same image but to what purpose. It's better just to realize the significance of the Blue Neon Drawer.

Whenever I try to display a bmpx ( which is 32bit) with an alpha mask such as a png icon image the alpha value in the 4th slot (R G B A) which are then swapped to A R G B become 'FF' so alpha doesn't show correctly. So what's the meaning of the Neon Blue? It's R G B A displayed as A R G B.

In the 4th slot the B values (blue channel) are all set to 0xFF. I was going to examine READPIXELARRAY and WRITEPIXELARDAY for some error. But everything looks correct. I could set up a test writing and reading using these two functions but I already suspect it will all be correct.

It may very likely pertain to something I learned the hard way while writing SaveBitMapPic using CopyFromBitplanes to save ILBM images with 8bpl or less. You cannot get more pixel data from the planar bitmap than is present in the bitplanes!

Since the Load_BMP function was originally designed for BMP files up to 24bits there may be another mechanism at work that only writes 24bit valid bits of data per pixel to the datatype bitmap. The other 8bits (4th slot) remains as it was initialized as 0xFF in READ/WRITEPIXELARRAY.

So I will focus my attention on Load_BMP. 😊

Now you have an idea of what goes into a simple Save Function for a picture datatype. Hopefully Save_ILBM will go smoother than with Save_BMP.

[miker1264]

Update:

I like it when a crazy theory comes closer to being proven!!

Using my "Quasi-Scientific Method" I devised a test case by disabling all new code in Load_BMP that supports loading 32 bit bmpx data.
So the expected result would be that trying to load a 32bit bmpx file would fail miserably...but it loaded and displayed correctly.

Somewhat surprised, again using my "Quasi-Scientific Method" , I closed Icaros Desktop and restarted in Hosted Mode to try to reproduce the results.
Again, I opened the same 32bit bmpx file called "Shoreline". It used the newly compiled bmpx datatype with all 32bit code disabled in Load_BMP. It loaded.

I set up my test program to save the pixel data as Test.bin in Ram Disk every time a picture file is loaded and displayed. So I used Yannick's Zune Hex Editor.
Not so surprisingly, in ARGB Pixel Format all values in the 1st slot (alpha values) are 0xFF. That is the initialized values for alpha for READ/WRITEPIXELARRAY.

Conclusion: Load_BMP is only writing 24bits of data per pixel to the Datatype Object. That must be hardcoded somewhere in the function itself. Now to find it.

So there is some other mechanism at work here that loads the 32bit RGB+A data as if it were 24bit RGB. Once I find that code and correct it...
We may yet be able to display 32bit bmpx files with alpha transparency just like png with alpha! I certainly hope it all works well. That would be cool.

[salvatore]

ok thank's