Login
Username:

Password:

Remember me



Lost Password?

Register now!
Main Menu
Who's Online
2 user(s) are online (2 user(s) are browsing Forum)

Members: 1
Guests: 1

Yannickescu, more...

Browsing this Thread:   1 Anonymous Users



« 1 2 3 (4) 5 »


Re: ShowPicture Image Viewer/Converter

Joined:
2017/5/2 17:15
From California, United States
Group:
Member
Posts: 164
Offline
More progress on ShowPicture. I successfully converted HAM8 ILBM images to 24bit PNG. I also successfully converted an ILBM with 5bitplanes (32 colors) to an 8bit PNG image file.

My reasoning was that the picture datatype for IFF loads all the pixel data into the planar bitmap (bm). The bitmap, I believe, has bm->Planes[8] where each Plane is a pointer to a UBYTE array of bitplane data. Because there are 8 planes (8bit) ReadPixelArray can easily turn that into an 8bit chunky buffer as when loading an 8bit standard image (PNG, BMP, etc). Then the image can be saved as any supported image type!

Posted on: 2017/11/13 18:23
Transfer the post to other applications Transfer


Re: ShowPicture Image Viewer/Converter

Joined:
2017/5/2 17:15
From California, United States
Group:
Member
Posts: 164
Offline
Now that I can Load a 5 bitplane ILBM image and save it as an 8 bit standard image the next step is to display it as a 8 bit image using WriteLutPixelArray and a ULONG CTable. My ultimate goal in the next week or two is to write the Save ILBM function for the IFF Datatype. It isn't necessary to display an ILBM in order to write the save function, but it seems like the logical next step.

Writing Save ILBM will most likely come in three steps. First I will write the code to save an 8 bitplane ILBM (Save_Bitmap_Pic). Then I will expand that to include RGB and ARGB images (Save_RGB_Pic). Lastly I will modify Save_Bitmap_Pic to allow saving images less than 8 planes. The very last step, after several rounds of testing, will be to make slight modifications and insert it into the IFF Dataype. After compiling the new datatype there will be more testing, but that's the exciting part.

As an update: I have successfully displayed the ILBM images (5 bitplanes) at 8 bits per pixel. I started writing the Save_ILBM function and all is going well. I'm using my C# SaveILBM function as a guide. I'm having a little trouble with ConvertLongToBytes_BigEndian. I wonder if there is an AROS helper function somewhere to do this for me?

Posted on: 2017/11/19 18:22

Edited by miker on 2017/11/20 2:19:56
Transfer the post to other applications Transfer


Re: ShowPicture Image Viewer/Converter

Joined:
2017/5/2 17:15
From California, United States
Group:
Member
Posts: 164
Offline
I'm not sure that I have enough on my plate! Since I'm making good progress on picture datatypes, concurrently while working on Save_ILBM I'd like to start two new functions in my image viewer/test program: Load_TGA and Save_TGA. Hopefully, if all goes well, after the IFF Dataype is complete we can add TARGA (TGA) Datatype, and later maybe TIFF.

Posted on: 2017/11/20 9:14
Transfer the post to other applications Transfer


Re: ShowPicture Image Viewer/Converter

Joined:
2008/6/2 2:28
Group:
Member
Posts: 256
Offline
Thanks for updating to datatypes

Posted on: 2017/11/21 1:24
Transfer the post to other applications Transfer


Re: ShowPicture Image Viewer/Converter

Joined:
2017/5/2 17:15
From California, United States
Group:
Member
Posts: 164
Offline
While writing the Save_ILBM function for the IFF datatype I needed some helper functions. I already wrote Save_ILBM a few years ago, but it was in CSharp. The nice thing is that I can just translate CSharp into C code because it is very similar. That's what I did. If I can do that with the remaining sections of code I'll be finished with Save_ILBM sooner than expected.

//Write File Size [WriteBytesBigEndian].
offset = 4;
length = 4;
LONG fileSize = 35394;
unsigned char *FileSize;
FileSize = WriteBytesBigEndian(fileSize, 0);
WriteBytes(fileHandle, FileSize, offset, length);

******************************************

//C sharp
public static void WriteBytesBigEndian(uint val, byte[] buffer, int offset)
{
buffer[offset] = (byte)((val >> 24) & 0xFF);
buffer[offset + 1] = (byte)((val >> 16) & 0xFF);
buffer[offset + 2] = (byte)((val >> 8) & 0xFF);
buffer[offset + 3] = (byte)(val & 0xFF);
}

******************************************

//C code
unsigned char *WriteBytesBigEndian(LONG val, int offset)
{
unsigned char *buffer;
buffer[offset] = (UBYTE)((val >> 24) & 0xFF);
buffer[offset + 1] = (UBYTE)((val >> 16) & 0xFF);
buffer[offset + 2] = (UBYTE)((val >> 8) & 0xFF);
buffer[offset + 3] = (UBYTE)(val & 0xFF);
return buffer;
}

******************************************

/* Prepare BMHD information. */
//Set_BMHD.

/* Write BMHD information. */
//Write BMHD.

/* Prepare ColorMap information. */
//Set_CMAP.

/* Write ColorMap and CAMG information. */
//Write CMAP.
//Write CAMG.

/* Prepare BODY information. */
//Set_BODY.

/* Write BODY information. */
//Write BODY.

Posted on: 2017/11/21 14:58
Transfer the post to other applications Transfer


Re: ShowPicture Image Viewer/Converter

Joined:
2017/5/2 17:15
From California, United States
Group:
Member
Posts: 164
Offline
Lately, I've been writing Save_ILBM and two subfunctions into my Test Program/Image Viewer. It's nearly finished.

I like to eat, and I like watching Food Network, so I'll put it in terms everyone can understand. Developing grfx apps for AROS is kinda like baking a cake. There are two ways to go about it. You could make everything from scratch, making every ingredient so everything is perfect. That's time consuming and labor intensive. The second method is easier and quicker! You can just get your ingredients from a box. They are pre-packaged and ready to go! Using Picture DataTypes is like the second scenario. Everything is pre-packaged and ready to go!

Sometimes while trying to test and improve the Picture DataTypes it is a journey of discover. There are moments of enlightenment when I suddenly realize that I don't have to re-create everything. It's already there to use. While trying to display ILBM images less than 8 bitplanes, which was more of a curiosity rather than part of the process for improving datatypes, I was faced with what I thought was a huge issue! But I discovered that whenever the picture datatypes load an image file, whether it is 8 bits or below, it produces a datatype object that has a bitmap (bm) which contains all the pixel data. The bitmap data is arranged in bitplanes. There are always 8 bitplanes for images of 8 bits and below! That was a revelation! So I simply used PDTM_ReadPixelArray just like I would for any 8 bit image file and displayed it in the same way as other 8 bit images. Surprisingly, it worked. Now it's time for the second revelation.

While writing SaveBitmapPic as part of Save_ILBM I had to come up with a way to convert the incoming pixel data to planar data to write to the BODY chunk that gets written to file. But then I realized that if the sending app creates a new datatype from a file and sends it to save, if the image data is 8 bits, 24 bits, or 32 bits it is already arranged in the bitmap in bitplanes! Everything is pre-packaged and ready to go! We simply have to copy the bitplane data to the BODY chunk scanLine by scanline and write to file.

The process for writing images less than 8 bitplanes is slightly different. Remember, when the incoming data is put into a datatype object, even if the original images has 5 bitplanes, the bitmap (bm) data is arranged in 8 bitplanes in order to be displayed in a rasterport. So if it's already 8 bitplanes and we only need to save it as 5 bitplanes we will have to somehow to convert the index values. Rather than trying to deal with re-arranging the planar data I would like to use what I already have. It's possible to use PDTM_ReadPixelArray again to convert the 8 bitplanes of data to a chunky buffer of 8 bits per pixel. Then I can send the chunky data to my function ChunkyPixelsToBitplanes which accepts a chunky buffer of 8 bits and the number of needed bitplanes. It will then convert the chunky data to planar data with the correct number of bitplanes. The planar data is then sent to the BODY chunk and written to the file. Piece of cake, isn't it?

Posted on: 2017/11/24 11:01
Transfer the post to other applications Transfer


Re: ShowPicture Image Viewer/Converter

Joined:
2016/8/16 0:09
Group:
Member
Posts: 329
Offline
Congratz on a (better) understanding of a OS with its revolutionary concepts

However, be aware of the cake. It might be delicious (it really is) but it can be treacherous

Posted on: 2017/11/24 14:26
Transfer the post to other applications Transfer


Re: ShowPicture Image Viewer/Converter

Joined:
2017/5/2 17:15
From California, United States
Group:
Member
Posts: 164
Offline
Chocolate cake can be addictive even if it comes from a box. But eating too much cake has side effects!

AROS, on the other hand, is like an alluring temptress. Once the seductive Kitty lures you in there's no escape!

Seriously though, I've penciled in a function called CopyBitplanes. Crossing my fingers and toes. I hope it works.

Posted on: 2017/11/24 14:38
Transfer the post to other applications Transfer


Re: ShowPicture Image Viewer/Converter

Joined:
2009/9/11 21:53
Group:
Member
Posts: 9
Offline
Thank you for the great explanation of Datatypes and the work you are doing.

Would it be possible for this explanation to be part of a Documentation Section for Datatypes within AROS?

Or failing that could it be part of an update to AROS Developer pages on en.wikibooks.org/wiki/AROS/Developer/?



Posted on: 2017/11/24 20:42
Transfer the post to other applications Transfer


Re: ShowPicture Image Viewer/Converter

Joined:
2017/5/2 17:15
From California, United States
Group:
Member
Posts: 164
Offline
When I'm finished fixing up the Picture DataTypes I'd like to write a document describing the writing process and I'd like to set up a template for people to use.

For example writing a Picture DataType isn't that difficult if you already have a working Load and Save function. There are four parts to the datatype that are critical. You must provide a Load function and Save function that uses manual methods to read and save your image file. At the end of the datatype are the other two critical parts, the DTM_NEW that links to your Load, and DTM_WRITE that links to your Save. That lets the Picture DataTypes know what your function names are.

For the Load function when the sending application creates DTM_NEW it makes an Empty datatype structure and DTW_Write structure that contains a file handle. It sends these structure to your Load function. The Load function is responsible for reading the image data and filling in the empty datatype information such as bmhd, colormap, and the bitmap structure.

The Save function is just the opposite. The sending application sends a full datatype structure and DTW_Write structure with the filehandle for the file to save. Your Save function must read the information from the incoming datatype such as bmhd, colormap, and planar bitmap and put those into a format that fits your image type then the data can be written to the file.

Sometimes after writing a few picture datatypes it may get easier especially if the small helper functions are modular and the same technique is used inside the datatypes. If the read and write methods are all similar the code can be re-used. One problem with AROS picture datatypes which I've noticed is that they were written at different times by different people so the writing techniques are very different. They aren't consistent as far as coding style. But that may be unavoidable.

I'll document the process in more detail when I'm all done writing save functions for BMP and IFF datatypes. There is still lots of work to do on the save functions.

Posted on: 2017/11/24 23:29
Transfer the post to other applications Transfer



« 1 2 3 (4) 5 »



You can view topic.
You cannot start a new topic.
You cannot reply to posts.
You cannot edit your posts.
You cannot delete your posts.
You cannot add new polls.
You cannot vote in polls.
You cannot attach files to posts.
You cannot post without approval.

[Advanced Search]


Search
Top Posters
1 paolone
paolone
4433
2 magorium
magorium
4095
3 nikolaos
nikolaos
4024
4 phoenixkonsole
phoenixkonsole
3929
5 deadwood
deadwood
2917
6 ncafferkey
ncafferkey
2796
7 mazze
mazze
2221
8 clusteruk
clusteruk
2112
9 damocles
damocles
1789
10 BSzili
BSzili
1513
© 2004-2018 AROS Exec