AROS Exec

Distros => Icaros Desktop => Topic started by: miker1264 on September 09, 2019, 03:24:38 AM

Title: AROS Picture DataTypes
Post by: miker1264 on September 09, 2019, 03:24:38 AM
While trying to find an easier way to export ilbm images from glowicons
I discovered "INFO datatype" which is also installed in the latest version of Icaros Desktop.

While reading the sources to find another way to export the iff icon images I read something
very interesting, for me at least. At the bottom of the README for INFO datatype was this:

========
 Author
========

OS4 version:
   Fredrik Wikstrom
   <fredrik@a500.org>
   
AROS version:
   Miloslav Martinka

Thanks:
   Yannick Erb
   Picture Datatype creation package.

If was this last part that caught my attention. "Picture Datatype creation package."?? Where is this magical package?

I went back to AROS Developer Docs/Libraries/DataTypes that I have visited so many times trying to figure out how
to compile an AROS Picture DataType and there is was at the very bottom, a link to the "pictdt_creationpackage".
So now I was really curious and a little dubious I must admit. Every other attempt to compile picture datatypes has
failed, so I didn't know if this would work. So I downloaded, installed and copied "tools" to my Icaros Desktop "bin".

As you can probably see by the screenshot it worked...now I will change a few lines in my ShowPicture program to
Test Picture Datatypes so that I can add my code to the missing save functions. I have written all my own functions
for BMP, ILBM, TGA & PCX. Especially for "Save ILBM" I have "SaveBitmapPic" & "SaveRGBPic".

Recompiled BMP Datatype. Testing now...

It seems the BMP datatype still can't save properly. I don't believe that ILBM datatype has a Save Function yet.
So I'll revised BMP and recompile and test it over the next week. I'll verify the ILBM datatype to see if anyone
beat me to it and actually wrote a "Save ILBM" function. If not, I have all the code necessary to do so and now
I can actually Compile Picture Datatypes!! YES.

Maybe "pictdt_creationpackage" was there all along but I just didn't see it there?! I'm not sure but it works!
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 09, 2019, 03:54:12 AM
Does anyone have contact information for Miloslav Martinka?

I'm trying to use the INFO Datatype but I'm not sure how to instantiate it.

for a new picture datatype:

DTImage = NewDTObject(   file_name,
                     (DTA_SourceType),   DTST_FILE,
                     (DTA_GroupID),      GID_PICTURE,
                     (PDTA_Remap),      FALSE,
                     (OBP_Precision),   PRECISION_EXACT,
                     TAG_DONE);

In the BMP datatype:
IPTR BMP__OM_NEW(Class *cl, Object *o, Msg msg)

In the INFO datatype, the last part is different.
IPTR INFO__OM_NEW(Class *cl, Object *o, struct opSet *msg)

If I can figure out how to use the INFO datatype I can export the iff icon images for glowicons for Icon Factory.
The next step will be to use ILBMtoIcon as a guide to write the "Save IFF Icon File" function.
Title: Re: AROS Picture DataTypes
Post by: mmartinka on September 09, 2019, 11:26:44 AM
The original package is on the www.a500.org
I converted the .info datatype into AROS os only.
Maybe he would help Fredric Wikström...

Sorry for my bad english :)
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 09, 2019, 02:48:51 PM
The original package is on the www.a500.org
I converted the .info datatype into AROS os only.
Maybe he would help Fredric Wikström...

Sorry for my bad english :)

Very Good. Thank you.
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 11, 2019, 06:24:45 AM
I have successfully compiled a new Windows Bitmap (BMP) picture datatype.

It is called BMPX. It will include all the Load and Save functions for BMP up to 24bit
and BMPX with 32bit and Alpha Transparency. So it will be designed to handle BMP & BMPX.

I'll revised the Save_BMP function and include Save_BMPX according to the bit depth.

Hopefully It will be done by this weekend. We'll see. It may require more testing. ;-)

 

I have Save Functions for BMP, PCX, TARGA and ILBM including Saving Bitmap Pics of 8bitplanes and below & Deep Images (IFF24).
I could revise the SaveRGBPic function to Save IFF32 but currently I don't believe the AROS ILBM datatype can read IFF32.

The ILBM Save Functions took the longest to write because it required a lot of research. It took about three months to complete.
The PCX Save Function was the second most difficult. It took an entire weekend to write that one. BMP format is not so difficult.

We'll see how it goes.
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 11, 2019, 06:34:51 AM
I adapted my ShowPicture Program to Save BMPX using the new picture datatype for testing.

The new datatype successfully opens BMP files and saves, but I still have to refine the save process.
Title: Re: AROS Picture DataTypes
Post by: mmartinka on September 11, 2019, 06:53:35 AM
very well  :)
Title: Re: AROS Picture DataTypes
Post by: o1i on September 11, 2019, 08:43:48 AM
The ILBM Save Functions took the longest to write because it required a lot of research. It took about three months to complete.

Nice, thanks for that one. I noticed a few weeks ago, that ilbm saving is not possible. I had a quick thought about implementing it, but realized, I have no time for it. So thanks for your work!
Title: Re: AROS Picture DataTypes
Post by: paolone on September 11, 2019, 03:42:08 PM
If was this last part that caught my attention. "Picture Datatype creation package."?? Where is this magical package?


I'd bet you're looking for this:
http://archives.aros-exec.org/index.php?function=showfile&file=datatype/utility/picdt_creationpackage_v2.0.i386-aros.zip (http://archives.aros-exec.org/index.php?function=showfile&file=datatype/utility/picdt_creationpackage_v2.0.i386-aros.zip)


By the way, maybe I should consider budling it with Icaros Desktop, if I already didn't, in Extras/development.
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 11, 2019, 04:36:39 PM
If was this last part that caught my attention. "Picture Datatype creation package."?? Where is this magical package?


I'd bet you're looking for this:
http://archives.aros-exec.org/index.php?function=showfile&file=datatype/utility/picdt_creationpackage_v2.0.i386-aros.zip (http://archives.aros-exec.org/index.php?function=showfile&file=datatype/utility/picdt_creationpackage_v2.0.i386-aros.zip)


By the way, maybe I should consider budling it with Icaros Desktop, if I already didn't, in Extras/development.

paolone,
Thank you.
I downloaded the picdt creation package and installed the Tools in Development/bin a few days ago. Since then I've been working on BMP datatype, then others when it's done.
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 11, 2019, 04:42:48 PM
The ILBM Save Functions took the longest to write because it required a lot of research. It took about three months to complete.

Nice, thanks for that one. I noticed a few weeks ago, that ilbm saving is not possible. I had a quick thought about implementing it, but realized, I have no time for it. So thanks for your work!

o1i,
I remember one of the Core developers mentioning that "Save As IFF" (ILBM) is disabled in Datatyoes Library because there's no Save function. Even if you write a new save function and compile the datatype you can't test it till it is enabled in the library. Maybe ask Neil or someone to enable it.

In the meantime, thank you for your efforts.
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 11, 2019, 04:48:15 PM
paolone,

Do we have a 64bit version of the picdt build tools so I can compile 64bit pic datatypes?
Title: Re: AROS Picture DataTypes
Post by: paolone on September 11, 2019, 09:45:48 PM
paolone,

Do we have a 64bit version of the picdt build tools so I can compile 64bit pic datatypes?

AFAIK we don't have a 64bit build of this picdt package. I don't know exactly if it would help ATM, since we don't have a working 64bit gcc for AROS. Please have a look at my posts on icarosdesktop.org about compiling programs for 64bit AROS. You need Linux to do that (either using a crosscompiler, or the AROS build system directly).
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 12, 2019, 04:32:33 PM
The bmpx picture datatype is coming along nicely.
It should be finished in a few days. Then testing.

This weekend I'll start to add Save Functions for the AROS ILBM datatype. It is in three main parts: Save_ILBM which directs traffic according to bitDepth to either SaveBitmapPic for 8 bitplanes and below or SaveRGBPic for 24 or 32 bitplanes. It may take two weeks to complete the dayatype.

I'll post completed binaries and source code for both under the AROS License.
Title: Re: AROS Picture DataTypes
Post by: Yannick on September 12, 2019, 05:39:53 PM
The picture datatype creation package is only a collection of tools that should be available when you build Aros yourself.
At the time I've created it they were not part of the distributed files, it might be the case now.

Just search for them in a 64bit built and you should have them.
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 12, 2019, 06:02:44 PM
The picture datatype creation package is only a collection of tools that should be available when you build Aros yourself.
At the time I've created it they were not part of the distributed files, it might be the case now.

Just search for them in a 64bit built and you should have them.

Thank you. I will do that.

The build tools are very helpful.
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 15, 2019, 12:46:41 AM
Writing the bmpx datatype is nearly finished. I had to overcome a couple minor obstacles along the way.

I was told by an AROS core developer a while ago that a dataype is part of a Library, so it has to interact with System Libraries. It should be coherent and concise. It also has to be effective.

With that in mind the Save Function for bmpx (bmp also) is a pioneering effort for me which will provide functions and techniques that can be used writing other datatypes. I wanted to use an existing Save Function as a template to start from but many AROS picture datatypes lack Save Funcions. The best options were Save_Gif from GIF datatype or Save_PNM. from PNM datatype. Save_GIF was nearly identical to the old Save_BMP. I wanted a fresh start that was concise and easy to understand so I chose Save_PNM as the prototype for Save_BMPX.

One thing I liked about Save_PNM was that it reads a single scanline from the datatype at a time. For BMP files the scanlines must be flipped so that the first scanline, scan0, is at the bottom of the BMP file. So instead of using a y offset starting at 0 to read the planar bitmap I set it to yoffset = height -1. Reading from the bottom of the planar bitmap and writing to the top of the BMP flips the scanlines without addressing issues and we can flip one scanline at a time!

Another slight obstacle took about three hours to figure out. Save_PNM uses FWrite as its primary write method. But FWrite != fwrite. FWrite uses pointer type BPTR where fwrite uses a pointer type FILE. Not the same. Also FWrite accepts a pointer to the data not the data itself. So it can be used with char* or unsigned char* or UBYTE * but not LONG, WORD, string litetal. It only uses pointers.

I'll do some testing tomorrow then post the source code and compiled binaries for ABIv0
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 15, 2019, 07:35:13 AM
The BMPX Datatype can now Load 32bit BMPX.

I'm fine tuning Save 8bit BMP & Save 32bit BMPX. Save 24bit BMP works well.

Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 15, 2019, 08:18:05 AM
Icaros Desktop MulitView Displaying 32bit BMP file using the new BMPX Picture Datatype!
Title: Re: AROS Picture DataTypes
Post by: salvatore on September 15, 2019, 11:19:07 AM
well miker :)

ps.bmpx is the new standard of windows?
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 15, 2019, 02:36:35 PM
well miker :)

ps.bmpx is the new standard of windows?

No. Although Windows can display Bmpx, it's not a new standard. Windows can't save Bmpx. Photoshop CS4 and GIMP can save. And now AROS can save Bmpx as well.

Bmpx has been around for a while. It includes standard BMP bit depths such as 1bit, 4bit, 8bit and 24bit, as well as 32bit which is BMPX since it wasn't part of the original BMP standard till recently. It means Bmp-Extended.

So the AROS bmpx picture datatype includes support for both BMP and BMPX. It can Load all standard BMP files as well as 32bit BMP. It can now Save 8bit and 24bit and 32bit BMP.

It's nearly complete but there are a few small issues I'm working on. The 32bit Load and Save works well for images that don't contain an Alpha Mask. It has difficulty with transparent images. The Padding Bytes aren't exactly right but that can be fixed as well. And some 8bit images don't display correctly but they look fine in the Windows Picture Viewer. It may be a problem with the Old BMP Load Function. I'll look into that issue as well.

In a future update I may include support for OS/2 BMP Files as well, though it isn't widely used nowadays. But being all-inclusive is better.

As soon as I finish Bmpx and realease it then I will move directly to the ILBM datatype to add the Save ILBM Function that it has been needing for so long now. I will also modify the Load Function to Support IFF32 which is ILBM Deep Images with 32 Bitplanes arranged in 4 sets of 8 Bitplanes. The first 8 planes contain R components, the second has G's, the third has B's, and the fourth set contains Alpha components. IFF24 is similar. It has 3 sets of 8 bitplanes for RGB data.

Although I have all the Save ILBM code that is already working in my graphics program when you include it in part of a Library such as a datatype it has to be written in a certain way. It has to be very "data-typish". The gcc compiler is very strict when compiling dtypes.

So what I have learned writing Bmpx can be applied to writing ILBM as well. Then maybe Save Functions for Targa and PCX. I have developed the code for that also. I may decide to write a complete new TIFF datatype in the near future. So many things to do.

After working on Bmpx and ILBM datatypes I'll get back to working on the 3D Renderer.

Title: Re: AROS Picture DataTypes
Post by: salvatore on September 15, 2019, 02:48:13 PM
ok i understand miker great :)
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 15, 2019, 02:59:27 PM
For the 3D Renderer I wanted to add Save As PNG and Save As IFF as well as a small menu to the Viewer that is included with the 3D Renderer but I've decided to wait till the Save ILBM Function is complete.
Title: Re: AROS Picture DataTypes
Post by: salvatore on September 15, 2019, 04:33:12 PM
ok that's very good job :)
Title: Re: AROS Picture DataTypes
Post by: Ball000 on September 15, 2019, 08:39:04 PM
Sorry if I'm a little off-topic, but I'd be interested about your thoughts...

dcraw (https://www.dechifro.org/dcraw/) is a program that allows to decode all (?) proprietary raw formats of reflex and high-end cameras. It compiles almost out of the box on Aros (http://archives.aros-exec.org/index.php?function=showfile&file=graphics/convert/dcraw.i386-aros.zip), and my skills just go that far. What would you think about trying to build a dedicated datatype able to call it? Or perhaps a datatype just calling dcraw and piping to some pnm converter... We once had a pnm (ppm? pbm?) datatype, I dunno if it's still there and working.
Or a datatype including dcraw's code? (Is it better? need to check what the licences allow for that matter.)
Of course supporting saving is out of the question for the raw formats... saving as tiff and pnm (both of which dcraw is able to output directly) and jpeg is the way and enough for that kind of matter afaik.

There is also libraw (https://www.libraw.org/) which uses dcraw's code as a library, perhaps it's more useful for building a datatype?
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 15, 2019, 09:43:26 PM
Sorry if I'm a little off-topic, but I'd be interested about your thoughts...

dcraw (https://www.dechifro.org/dcraw/) is a program that allows to decode all (?) proprietary raw formats of reflex and high-end cameras. It compiles almost out of the box on Aros (http://archives.aros-exec.org/index.php?function=showfile&file=graphics/convert/dcraw.i386-aros.zip), and my skills just go that far. What would you think about trying to build a dedicated datatype able to call it? Or perhaps a datatype just calling dcraw and piping to some pnm converter... We once had a pnm (ppm? pbm?) datatype, I dunno if it's still there and working.
Or a datatype including dcraw's code? (Is it better? need to check what the licences allow for that matter.)
Of course supporting saving is out of the question for the raw formats... saving as tiff and pnm (both of which dcraw is able to output directly) and jpeg is the way and enough for that kind of matter afaik.

There is also libraw (https://www.libraw.org/) which uses dcraw's code as a library, perhaps it's more useful for building a datatype?

This thread is about picture dataypes both existing and planned, so you are right on topic. :-)

It would require a little research to find out what is possible for dcraw. Supporting RAW file formats from camera output may be possible. We have PNM and PPM dataypes that go against AROS tradition so to speak. The PNM in particular has both a working Load and Save Function. Directing output to PPM files is also very easily done.

Maybe what you would need is a function or program that accepts the dcraw input from the camera and outputs to a file using PPM or PNM. I'll look up dcraw and the associated libraries so that I can give you a more definite answer to your question. Anything that AROS can support such as digital cameras and peripheral devices is good for AROS and its users. All the more reason to use and enjoy!
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 15, 2019, 10:17:12 PM
According to Wikipedia:

"dcraw is an open-source computer program which is able to read numerous raw image format files, typically produced by mid-range and high-end digital cameras. dcraw converts these images into the standard TIFF and PPM image formats. This conversion is sometimes referred to as developing a raw image (by analogy with the process of film development) since it renders raw image sensor data (a "digital negative") into a viewable form."

What's needed it seems is an AROS GUI Frontend using dcraw to output directly to PPM file format. Certainly the AROS PPM dataype can then display the PPM images that result from the camera data. We may also need to develop a TIFF datatype.

I wonder if drone imagery data is also in RAW format? Civil Engineering uses aerial drones. That would also be valuable for generating interest in AROS. Hook up your drone camera and convert it to something useful using the AROS RAW Utility!

Just a thought...But datatypes can be used.
Title: Re: AROS Picture DataTypes
Post by: asymetrix on September 16, 2019, 12:12:14 AM
This is great work. Thank you.

What would be also useful is to have some computer generated image samples that could be used to verify future image authenticity.

Specific developer functions to read into memory and check data in memory is actually read properly.
maybe small files could be used for data matching in arrays using asserts.

Then lastly byte by byte comparisons sent to a report file that flags computed results to expected results.
Title: Re: AROS Picture DataTypes
Post by: Ball000 on September 16, 2019, 09:21:00 AM
Maybe what you would need is a function or program that accepts the dcraw input from the camera and outputs to a file using PPM or PNM. I'll look up dcraw and the associated libraries so that I can give you a more definite answer to your question. Anything that AROS can support such as digital cameras and peripheral devices is good for AROS and its users. All the more reason to use and enjoy!

Exactly, it would be wonderful to be able to see our photos in Multiview. And easy to save them as jpeg if they don't need any work. Then a program to work on them would be far easier to implement imho if their opening is already done by a proper datatype.

Furthermore, once pictures datatypes are more integrated in the system, Wanderer and consorts will easily be able to preview those photos as thumbnail-icons, in their drawer, as any modern system does it.
Title: Re: AROS Picture DataTypes
Post by: o1i on September 16, 2019, 01:55:13 PM
Did not follow the thread entirely, but the jpeg datatype could use an update, too. There are  some jpegs, which can' be loaded. AFAIR there are some on the jpeg pages.
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 16, 2019, 03:02:36 PM
Did not follow the thread entirely, but the jpeg datatype could use an update, too. There are  some jpegs, which can' be loaded. AFAIR there are some on the jpeg pages.

That's correct. I've looked at the JPEG code. It can't Load or Save 8bit JPEG files, though 8bit files do exist. Some websites especially use 8bit JPEG files to store images such a cartoon site. I think it's called AlphaLuna?

Just some minor revisions might allow the datatype to Load 8bit as well as 24bit JPEG. But first I would like to finish BMPX and ILBM.

After all that I can add Save Functions for TGA and PCX if needed and start writing TIFF. I'd also like to have a Mac ICNS datatype for a future Icon Viewer that's for ICO, ICNS, INFO.
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 16, 2019, 03:21:08 PM
In order to finish the new BMPX picture datatype I'm working on the Padding Bytes added to the end of scanlines for images with odd dimensions. I've already spent about 30 hours on the datatype.

For images that are evenly divisible (modulus) then saving 8bit, 24bit nd 32bit BMP can already do that. I'll finish the last bits and clean up the code to make it prettier and well commented in the next few days. Then I can release it for you.

Next will come ILBM. Although I have the Save Functions for ILBM working it will take about two weeks to put them in the picture datatype.
Title: Re: AROS Picture DataTypes
Post by: salvatore on September 16, 2019, 03:56:29 PM
thank you miker :D
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 16, 2019, 04:29:40 PM
thank you miker :D

You're welcome! It's my pleasure to serve the AROS community in any small way possible.

Fixing up the picture datatypes and writing new ones has been on my priority list for a long time. Now that I have the tools to do it things may progress very quickly!

It is my hope that someday MultiView will be enabled to "Save As IFF" and "Save As PNG".
Title: Re: AROS Picture DataTypes
Post by: salvatore on September 16, 2019, 05:48:31 PM
good miker ;)
Title: Re: AROS Picture DataTypes
Post by: asymetrix on September 16, 2019, 10:42:15 PM

In future I hope Multiview converts to PDF/ASCIIDOC or other document archiving format.

Improved datatypes : leading a way forward for image/media processing frame server.

Apple is using their high performance HEIF file format.

https://nokiatech.github.io/heif/examples.html

https://github.com/strukturag/libheif
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 17, 2019, 12:10:33 AM
One reason why we don't have more datatypes is that there are many programmers out there for AROS but very few know how to write a datatype. Those that do know are probably too busy doing other projects. And some of the datatypes we have don't have sufficient documents for usage.

The type of datatype is only limited by one's own imagination and creativity. Do we have a PDF datatype yet?
Title: Re: AROS Picture DataTypes
Post by: salvatore on September 17, 2019, 12:34:29 AM
no miker
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 17, 2019, 01:42:50 AM
no miker

No what? My assessment is wrong?
Title: Re: AROS Picture DataTypes
Post by: Samurai_Crow on September 17, 2019, 04:04:37 AM
no miker

No what? My assessment is wrong?
No PDF datatype yet.  That may come with Ghostscript and Terminills' attempt at bringing AROS' print drivers up-to-date.
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 17, 2019, 04:35:35 AM
no miker

No what? My assessment is wrong?
No PDF datatype yet.  That may come with Ghostscript and Terminills' attempt at bringing AROS' print drivers up-to-date.

Ah! I understand. I'd be interested to see how the PDF datatype works.
I mostly work with graphics programs, file systems and disk imaging.
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 17, 2019, 04:42:42 AM
Still working on the BMPX datatype.

In theory at least the BMPX 32bit file is BGRA so it should display as Transparent.

In fact, I used a gold crown with a transparent background to test BMPX + Alpha.
I started with a transparent PNG (alpha mask), then saved as BMPX using PixelFormer 'Export As'.
In the Save Dialog I specified 'RGBA' but when I opened it with ShowPicture using datatypes the
background is not transparent. It's Black! But I reopen the same file in PixelFormer and it works!

Something must be wrong with my method for displaying the image! The format is RGBA but I'm
using Cybergraphx function 'WritePixelArrayAlpha' which expects RECTFMT_ARGB. Maybe that's it?

Title: Re: AROS Picture DataTypes
Post by: Yannick on September 17, 2019, 08:58:11 AM
As your colors are OK it seems that the endianess is OK.
In order to get a "background" for the alpha channel you first need to draw it yourself in the application, datatypes are not doing this.

Try opening the image in ZunePaint, it is using datatypes and draws a checkered background.
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 17, 2019, 01:54:13 PM
As your colors are OK it seems that the endianess is OK.
In order to get a "background" for the alpha channel you first need to draw it yourself in the application, datatypes are not doing this.

Try opening the image in ZunePaint, it is using datatypes and draws a checkered background.

Thank you. Good idea.

Zune Paint shows a checkered background for the orginal png but still black for the bmpx.
But the good news is that displaying 32bit bmpx without an alpha mask works very well.

Because of time constraints I may have to try to solve the bmpx alpha display issue later.
Padding Bytes works on nearly all images except a few. My formula for testing Modulus
probably needs adjusted. That's easy enough to resolve. I should have it ready tomorrow.

The bmpx datatype can Load 1bit, 4bit, 8bit, 24bit, and 32bit bmp files. It can Save 8bit,
24bit, and 32bit bmp's. In a future update I plan to also include OS/2 bitmap file support.
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 17, 2019, 02:24:24 PM
Using ZunePaint to test BMPX datatype.

I like how it scales the image to fit the screen.
Title: Re: AROS Picture DataTypes
Post by: Yannick on September 17, 2019, 03:09:25 PM
One thing that's sometimes causes troubles with the alpha channel : it might need to be inverted.
Internally this codes opacity, not transparency, i.e. 255 is fully opaque and 0 is fully transparent.
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 17, 2019, 05:22:49 PM
One thing that's sometimes causes troubles with the alpha channel : it might need to be inverted.
Internally this codes opacity, not transparency, i.e. 255 is fully opaque and 0 is fully transparent.

That's true. Thanks for the information.

I saved the uncompressed chunky pixel data from the original 32bit png as a .bin file. When I have time I will use a hex editior to compare the scan0 at the end of the bmpx file and compare it directly to the first scanline in the png which is 'ARGB'. I can compare byte by byte to see what format the bmpx 32bit data is in the actual bmpx file.

That also gives me a good test case to use the new Zune Hex Editor. Thank you for that.
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 18, 2019, 07:38:56 AM
The problem with the Padding Bytes at the end of the scanlines has been resolved.
It was a Mathematical Error on my part. The image on the bottom right is missing
Padding Bytes before I made the correction. The image at the top left has padding.

The formula for testing if a scanline is Modulus 4 (ends evenly on a 4-byte boundary)
is as follows:

//** Test for Modulus & Set Padding Values. **//
   
   LONG pixelElements = ( depth / 8 );
   //Is it Modulus 4??
   if((width * pixelElements)%4 == 0)
   {
      alignwidth = (width * pixelElements); //bytesPerPixel
      alignbytes = width;
   }
   else
   {
      alignwidth = ((width * pixelElements) + 3) & ~3UL; //Not Modulus 4
      alignbytes = (alignwidth / pixelElements);
   }

    >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
   
    if( FWrite( filehandle, linebuf, (alignbytes * pixelElements), 1 ) != 1 )


I was using  (alignbytes * pixelElements) as if it were equivalent to: alignwidth!
Mathematically that is incorect because...

If your image dimensions are 299x144 & it is 24bit RGB
299*3=897 so it requires 3 padding bytes such that alignwidth = 900.
Is it evenly divisible by 4? 900/4=225. alignbytes = (alignwidth/3) = 300.
That works.

Next image dimensions are 474x329 & it is 24bit RGB
474*3=1422 so it requires 2 padding bytes such that alignwidth = 1424.
Is it evenly divisible by 4? 1424/4=356. alignbytes = (alignwidth/3) = 474.6667
As far as I know, an int of that will yield 474 which is where we started.
That doesn't work!

Notice the FWrite statement:
 if( FWrite( filehandle, linebuf, (alignbytes * pixelElements), 1 ) != 1 )

The simple solution is to only use alignwidth but not (alignbytes * pixelElements)
because we have proven that the two are not equivalent.

 if( FWrite( filehandle, linebuf, alignwidth, 1 ) != 1 ) //That works!
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 18, 2019, 07:52:56 AM
Using the Nice Zune Hex Editor and my faithful HxD Hex Editor (which is very powerful)
I am very close to a solution for Displaying 32bit BMPX with Alpha Transparency.

Here are my test results for the same group of pixels in three samples.
My conclusions are that the PNG pixel data is 'ARGB' so it displays as transparent.
The Originl BMPX File is 'BGRA' But after Load_BMPX when it reaches my display
function it is transformed into 'XRGB' where 'X' if FF (255) so it is not transparent.
Now I have to find out where the missing Alpha Values went. Where are they hiding?

Note: I start reading pixel data at '1C' on the top line.

Test_PNG
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1C 7E 63 0B 93 D9 A5 19 F2 DE A2 1D FF DE A2 1E FF EA C4 70 FF F9 EE D7 FF FE FC F7 FF FD FA F4 FF FD FA F4 FF FD FA F4 FF FD FA F4 FF FD FA F4 FF FD FA F4 FF FD FA F4 FF FD FA F4 FF FD FA F4 FF FD FA F4 FF FD FA F4 FF FD FA F4 FF FD FA F4 FF FD FA F4 FF FD FA F4 FF FD FA F4 FF FD FA F4 FF FD FA F4 FF FD FA F4 FF FD FA F4 FF FD FA F4 FF FD FA F4 FF FE FB F6 FF FB F2 E0 FF E8 C0 63 FF DE A3 1D FF DE A2 1D FF DE A2 1D FF DE A2 1D FF DE A2 1D FB DD A0 1C C0 DA 9D 1B 3D 9F 73 13 00 49 49 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Gold_Crown_Export
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 19 A5 D9 93 1D A2 DE F2 1E A2 DE FF 70 C4 EA FF D7 EE F9 FF F7 FC FE FF F4 FA FD FF F4 FA FD FF F4 FA FD FF F4 FA FD FF F4 FA FD FF F4 FA FD FF F4 FA FD FF F4 FA FD FF F4 FA FD FF F4 FA FD FF F4 FA FD FF F4 FA FD FF F4 FA FD FF F4 FA FD FF F4 FA FD FF F4 FA FD FF F4 FA FD FF F4 FA FD FF F4 FA FD FF F4 FA FD FF F4 FA FD FF F4 FA FD FF F6 FB FE FF E0 F2 FB FF 63 C0 E8 FF 1D A3 DE FF 1D A2 DE FF 1D A2 DE FF 1D A2 DE FF 1D A2 DE FF 1C A0 DD FB 1B 9D DA C0 13 73 9F 3D 00 49 49 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

1C 7E 63 0B   'ARGB'  - - Test_PNG.bin
0B 63 7E 1C  'BGRA'  - -  Gold_Crown_Export.bmpx
FF 7E 63 0B   FF D9 A5 19   'XRGB' Test_BMPX.bin
Title: Re: AROS Picture DataTypes
Post by: asymetrix on September 18, 2019, 06:27:32 PM

The formula for testing if a scanline is Modulus 4 (ends evenly on a 4-byte boundary)
is as follows: ...


Don't know if it helps, from Kochans Programming in C book :

For example, to round off 256 days to the next largest number of days evenly
divisible by a week, values of i = 256 and j = 7 can be substituted into the
above formula as follows.
Next_multiple = 256 + 7 - 256 % 7 = 256 + 7-4
= 259
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 18, 2019, 07:13:31 PM

The formula for testing if a scanline is Modulus 4 (ends evenly on a 4-byte boundary)
is as follows: ...


Don't know if it helps, from Kochans Programming in C book :

For example, to round off 256 days to the next largest number of days evenly
divisible by a week, values of i = 256 and j = 7 can be substituted into the
above formula as follows.
Next_multiple = 256 + 7 - 256 % 7 = 256 + 7-4
= 259

That works.

One main problem, which has been solved, was that according to the bmp specs the scanline length must be evenly divisble by 4.

A potential problem also exists in the Load BMP function that is from the old BMP datatype. It assumes (alignbytes * 4) = alignwidth. But that's not true in all cases.

I'll have to examine Load BMP to make sure everything is correct to support Load 32bit.
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 19, 2019, 05:53:28 AM
Displaying Transparent BMPX Files!

Yes. It is possible.

I will have to re-write parts of Load_BMP in the BMPX Datatype for 32bit BMPX with Alpha.
Title: Re: AROS Picture DataTypes
Post by: salvatore on September 19, 2019, 06:18:18 AM
well miker :D
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 19, 2019, 06:43:26 AM
That means that Alpha Transparency may also be possible using an ILBM Deep Image with 32 bitplanes. That would be an exciting moment. 😊
Title: Re: AROS Picture DataTypes
Post by: mmartinka on September 19, 2019, 09:25:10 AM
very good job  8)
Title: Re: AROS Picture DataTypes
Post by: aha on September 19, 2019, 05:31:28 PM
Simply great!  :) I am looking forward to it.
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 20, 2019, 03:04:00 PM
In the past few days I have tested displaying BMPX files with Alpha Mask. In the process I've discovered a few things.

After several attempts to display transparent bmpx images I suspected there might be something wrong in the way
that the datatypes library handles reading from the picture datatype as 'RGBA' but it has no problem with 'ARGB' such
as with png datatype. Transparent png images using 'ARGB' display perfectly. So I came up with a "Direct Read"
function to read the data in the bmpx file directly then display it on screen. That method worked perfectly as well.

I found these few lines in the PNG picture datatype which seems to confirm my belief there's something wrong here!

case PNG_COLOR_TYPE_RGB_ALPHA:
       png.png_depth = 32;
   #if 0
       png.png_format = PBPAFMT_RGBA;
   #else
       /* FIXME: PBPAFMT_RGBA not supported by picture.datatype, therefore using PBPAFMT_ARGB */
       png.png_format = PBPAFMT_ARGB;
       png_set_swap_alpha(png.png_ptr);
   #endif


So I proved that "Direct Read" works. It's interesting that I use 'RGBA' to encode the bmpx file but
Writing to the datatype (WRITEPIXELARRAY) works fine as well. After Save_BMPX programs such as
PixelFormer, GIMP and maybe Photoshop CS4/5 display the file as Transparent BMPX.

For example, when reading from the datatype as 'ARGB' all the Alpha values are changed to 'FF' (255).
When I change to reading from the datatype as 'RGBA' (wherein lies the problem) and using 'ARGB' to
display the image I get a skewed blue-ish but transparent image! In this case Read 'RGBA' - Display 'ARGB'
distorts the Blue values transforming them into, you guessed it 'FF' (255). Using 'RGBA' it can't read the
fourth value, either Alpha or Blue, whichever is indicated. I hope that all makes sense.

This is my Direct Read Method that works well for my graphics program:

if(picType == "bmp")
       {
            BPTR fileHandle = Open(fname, MODE_OLDFILE); //MODE_OLDFILE
           Seek(fileHandle,54,OFFSET_BEGINNING);
           Read(fileHandle,bitmapImage,(in_pic->Width*4*in_pic->Height)); //BGRA
           UBYTE tempRGB;
           int imageIdx = 0;
            for (imageIdx = 0;imageIdx < (in_pic->Width*4*in_pic->Height);imageIdx+=4)
            {
                tempRGB = bitmapImage[imageIdx]; //blue
            bitmapImage[imageIdx] = bitmapImage[imageIdx + 3]; //alpha
            bitmapImage[imageIdx + 3] = tempRGB; //blue

            tempRGB = bitmapImage[imageIdx+1]; //green
            bitmapImage[imageIdx+1] = bitmapImage[imageIdx + 2]; //red
            bitmapImage[imageIdx + 2] = tempRGB; //green
            }
            Flip_Vertical(bitmapImage, in_pic->Width, in_pic->Height, 4);
            Close(fileHandle);
        }
       
        showImage(bitmapImage, bitmapInfoHeader, fname, isIcon);



So, in the next few days I will fix up what I have for the BMPX picture datatype.
It Loads and Saves BMP files correctly but it currently can't load an alpha mask.

Maybe I can fix the problem with alpha transparency in a future update along with support for OS/2 bitmaps. :-)
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 20, 2019, 04:32:31 PM
Sorry folks!

To summarize all the technical stuff -

For all the programmers out there, when trying to display 32bit bmpx files with alpha transparency there's a potential problem with datatypes library. When reading as 'ARGB' such as with 'PNG' it works. But it doesn't work reading with 'RGBA' and that is what bmpx requires to display transparecy!

Until the problem is fixed you should use a direct read method to get the pixel data directly from the bmpx file. All the data is there incuding the alpha values.

The bmpx picture datatype is finished and will be released as early as tomorrow.
Title: Re: AROS Picture DataTypes
Post by: salvatore on September 20, 2019, 05:58:52 PM
but you're basically fixing the datatypes and also creating new :-\
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 20, 2019, 06:56:01 PM
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.
Title: Re: AROS Picture DataTypes
Post by: salvatore on September 21, 2019, 01:01:11 AM
thank you i undenstand again  :D
Title: Re: AROS Picture DataTypes
Post by: Samurai_Crow on September 21, 2019, 02:37:35 AM
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.
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 21, 2019, 03:34:42 AM
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.
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 21, 2019, 10:00:47 PM
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.
Title: Re: AROS Picture DataTypes
Post by: salvatore on September 21, 2019, 11:37:53 PM
well miker
Title: Re: AROS Picture DataTypes
Post by: paolone on September 22, 2019, 12:19:11 PM
@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.
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 22, 2019, 12:59:05 PM
@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.








Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 22, 2019, 02:13:02 PM
@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?



Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 22, 2019, 02:52:15 PM
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.
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 22, 2019, 03:22:57 PM
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.
Title: Re: AROS Picture DataTypes
Post by: salvatore on September 22, 2019, 04:09:12 PM
good job miker :)
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 22, 2019, 07:17:20 PM
good job miker :)

But I have only just begun with JPEG. 😊

(Actually I have never worked with JPEG)
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 22, 2019, 07:43:53 PM
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.





Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 22, 2019, 08:48:49 PM
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.
Title: Re: AROS Picture DataTypes
Post by: salvatore on September 22, 2019, 09:11:30 PM
ok thank's
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 22, 2019, 10:19:15 PM
ok thank's

Sure! But I'm done yet.

Load_ BMP (though it wasn't written by me) doesn't meet my three main criteria for picture datatypes:

It should be "Coherent, Concise & Effective".

It isn't Coherent with Buffered Read Operations that are difficult to follow if there's a problem. There is definitely a problem here!

It is Concise. Other than "Buffered Reads" it has the minimal amount of code for the desired effects.

It's not effective because it's not "inclusive". Saying "if( depth != 24 )" //get colormap isn't effective. What if depth is 32? Instead it shoud say "if( depth <= 8 )" //get colormap. That's more effective. Reading one scanline at a time is a Buffered Read. That's enough for C code that is already fast.

Having said all that, I do admire the style in which Load_ILBM is written for the ILBM datatype. Its Coherent, Concise, Well-Organized, Effective & All-Inclusive.  ;)

With that in mind I will re-write the entire Load_BMP function with Direct Read Methods which I have already proven to be effective with Alpha Transparency for BMPX files.

(Sorry - salvatore didn't get the last word again) 😛
Title: Re: AROS Picture DataTypes
Post by: Samurai_Crow on September 23, 2019, 12:59:55 AM
The reversed byte ordering probably means you're running big endian code on a little endian PC.  There should be a macro in the developer kit with byte swapping.  That way it only takes a BSWAP opcode on 486.
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 23, 2019, 05:16:51 AM
The reversed byte ordering probably means you're running big endian code on a little endian PC.  There should be a macro in the developer kit with byte swapping.  That way it only takes a BSWAP opcode on 486.

That's a very good point.

I thought perhaps there was a problem in Load_BMP but that may not be the case.

Here is the situation:
I re-wrote Load_BMP to read the file directly. But the Alpha bytes are still 0xFF. I'm back to my original suspicion that READPIXELARRAY works fine when the PBPAFMT of source matches destination such as PNG stored as ARGB and read as ARGB. But BMPX is RGBA.

When I Save BMPX from PNG the soure pixel format for PNG is ARGB. That works fine.

When using the datatype in my graphics program I must use READPIXELARRAY with PBPAFMT_ARGB. So the datatypes system (READPIXELARRAY) is forced to convert RGBA to ARGB. Something happens in the conversion process and the Alpha in RGBA doesn't get copied from source to destination.

I may be going far out on a limb making assumptions without enough information. But it seems very strange that the initial values in READPIXELARRAY are: r=0, g=0, b=0, a=0xff. I'll keep testing the datatype. The problem with RGBA converting Alpha bytes to 0xff seems to be internal. I will direct my question to the Developers Mailing List to see if anyone there has an idea as to why alpha bytes are not being copied correctly from the source to the destination byte arrays.

The Endianess should be handled when the bytes are swapped around. But I'll consider that also as a probable cause.


Title: Re: AROS Picture DataTypes
Post by: salvatore on September 23, 2019, 08:38:50 AM
good job miker :)
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 26, 2019, 07:14:48 PM
I am currently working on Save_ILBM for the ILBM datatype. Note: I am not altering the Load_ILBM. I'm just adding save functions so we can finally save as iff in MuliView.

I'm working on Save_BitMapPic first to save ILBM images of 8 bitplanes and below.
Title: Re: AROS Picture DataTypes
Post by: miker1264 on September 28, 2019, 08:13:38 AM
I'm revising the SaveBitMapPic code to be used in the ilbm datatype. I'm testing it on Icaros Desktop Native.