AROS Picture DataTypes

[miker1264]

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.

[miker1264]

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

[miker1264]

The BMPX Datatype can now Load 32bit BMPX.

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

[miker1264]

Icaros Desktop MulitView Displaying 32bit BMP file using the new BMPX Picture Datatype!

[salvatore]

well miker

ps.bmpx is the new standard of windows?

[miker1264]

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.

[salvatore]

ok i understand miker great

[miker1264]

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.

[salvatore]

ok that's very good job

[Ball000]

Sorry if I'm a little off-topic, but I'd be interested about your thoughts...

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, 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 which uses dcraw's code as a library, perhaps it's more useful for building a datatype?

[miker1264]

Sorry if I'm a little off-topic, but I'd be interested about your thoughts...

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, 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 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!

[miker1264]

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.

[asymetrix]

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.

[Ball000]

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.

[o1i]

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.