Login
Username:

Password:

Remember me



Lost Password?

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

Members: 2
Guests: 1

amiga, mordesku, more...

Browsing this Thread:   1 Anonymous Users



« 1 (2) 3 4 »


Re: AROS BMP Picture DataType

Joined:
2004/10/30 17:13
From Ireland
Group:
Member
Posts: 2646
Offline
I think I put a set of test BMP images in the test directory (which might be "developer/debug/test" currently - I'm on holidays and on my phone, so I can't easily check). They may include <8-bit images.

Posted on: 11/6 19:04
Transfer the post to other applications Transfer


Re: AROS BMP Picture DataType

Joined:
5/2 17:15
From California, United States
Group:
Member
Posts: 134
Offline
Thank you. I'll have a look.

Posted on: 11/6 19:58
Transfer the post to other applications Transfer


Re: AROS BMP Picture DataType

Joined:
5/2 17:15
From California, United States
Group:
Member
Posts: 134
Offline
For the BMP DataType this part of the code is used to fill the buffer. The part in the middle that says if (bytes > 0) looks suspicious. This might help to explain the banding in the 8bit images.

The notation says: /* copy existing bytes to start of buffer */

If there are existing bytes they will be copied to the beginning of the linebuffer. The "new" bytes for the current line will then be copied after the old bytes.
In the banded images that's what we are seeing, the leftover bytes from the previous line copied to the beginning of the current line and the new bytes for the current line copied after, leaving a remainder equal to the line above, which then repeats the process on the next line, and so on. That would help to explain how the banding happens. But that's just a guess without looking further to understand exactly what's happening here.

The banding in 8bit images doesn't affect 24bit and presumably 16bit images. In 24bit images an entire scanline (width + pad bytes) is read all at one time and after processing it is copied to the datatype. There are no leftover bytes to be copied to the next line. But for 8bit images we are reading one byte at a time and adding them to the linebuffer. We could just read one scanline just like in 24bit images. They are just one byte index values. Maybe that would help to alleviate the banding. But for bitdepths less than 8 we must read and process one byte at a time for bitwise operations.

/***************************************************/

BOOL LoadBMP_FillBuf(BmpHandleType *bmphandle, long minbytes)
{
long i, bytes;

//D(bug("bmp.datatype/LoadBMP_FillBuf() --- minimum %ld bytes of %ld (%ld) bytes\n", (long)minbytes, (long)bmphandle->filebufbytes, (long)(bmphandle->filebufsize-(bmphandle->filebufpos-bmphandle->filebuf)) ));
if ( bmphandle->filebufbytes >= 0 )
return TRUE;
bytes = bmphandle->filebufbytes + minbytes;
//D(bug("bmp.datatype/LoadBMP_FillBuf() --- %ld bytes requested, %ld bytes left\n", (long)minbytes, (long)bytes));


if (bytes > 0)
{
//D(bug("bmp.datatype/LoadBMP_FillBuf() --- existing %ld old bytes\n", (long)bytes));
for (i=0; i

/* copy existing bytes to start of buffer */
bmphandle->filebuf[i] = bmphandle->filebufpos[i];
}


bmphandle->filebufpos = bmphandle->filebuf;
bytes = Read(bmphandle->filehandle.bptr, bmphandle->filebuf + bytes, bmphandle->filebufsize - bytes);
if (bytes < 0 ) bytes = 0;
bmphandle->filebufbytes += bytes;
//D(bug("bmp.datatype/LoadBMP_FillBuf() --- read %ld bytes, remaining new %ld bytes\n", (long)bytes, (long)bmphandle->filebufbytes));
//D(bug("bmp.datatype/LoadBMP_FillBuf() --- >minimum %ld bytes of %ld (%ld) bytes\n", (long)minbytes, (long)bmphandle->filebufbytes, (long)(bmphandle->filebufsize-(bmphandle->filebufpos-bmphandle->filebuf)) ));
if (bmphandle->filebufbytes >= 0)
return TRUE;
return FALSE;
}

Posted on: 11/6 23:15

Edited by miker on 2017/11/6 23:38:14
Edited by miker on 2017/11/6 23:41:35
Transfer the post to other applications Transfer


Re: AROS BMP Picture DataType

Joined:
5/2 17:15
From California, United States
Group:
Member
Posts: 134
Offline
I sent the first revisions for the BMP DataType. I'd like to test the resulting DataType to find out how it works!

Posted on: 11/11 9:34
Transfer the post to other applications Transfer


Re: AROS BMP Picture DataType

Joined:
5/2 17:15
From California, United States
Group:
Member
Posts: 134
Offline
I sent the first revisions for the BMP DataType. I'd like to test the resulting DataType to find out how it works!

Posted on: 11/11 9:35
Transfer the post to other applications Transfer


Re: AROS BMP Picture DataType

Joined:
2013/5/17 6:23
From Germany
Group:
Member
Posts: 234
Offline
I don't understand Computer Code.Computer Code ist too cryptic to me. but it is good there are Coders!

Thank you everybody! I love you!

Posted on: 11/11 11:17
Transfer the post to other applications Transfer


Re: AROS BMP Picture DataType

Joined:
5/2 17:15
From California, United States
Group:
Member
Posts: 134
Offline
Work on the BMP Datatype has temporarily halted due to lack of access to the code repository to submit changes. In the meantime, while waiting for access I will try to focus on writing the Save_ILBM code for the IFF Datatype.

Posted on: 11/17 11:12
Transfer the post to other applications Transfer


Re: AROS BMP Picture DataType

Joined:
5/2 17:15
From California, United States
Group:
Member
Posts: 134
Offline
With the assistance of another AROS user I have been able to confirm a few things about the behavior of BMP datatype.

I'm using AROS Native i386 (Icaros Desktop) and when I'm loading and displaying 8bit images with the BMP datatype I'm getting two types of errors. Sometimes I will see a black image because no colormap is present. Or if the image size is less than 320x200 and biClrUsed is not set to zero the image displays properly. But in 8bit images larger than that there will be banding in the images. But 24bit BMP images display just fine on my system. All images display well on AROS Hosted. Maybe some of it may be endianness?

However, Save_BMP does have the same issues on both Native and Hosted. Currently it doesn't save correctly.

I said all that to say if you are using a version of AROS other than Native i386 and you haven't seen the types of artefacts in 8bit images I have described then that's a good thing for you! But in AROS Native they are there.

Posted on: 11/18 18:56
Transfer the post to other applications Transfer


Re: AROS BMP Picture DataType

Joined:
2016/8/16 0:09
Group:
Member
Posts: 319
Offline
Quote:

But 24bit BMP images display just fine on my system. All images display well on AROS Hosted. Maybe some of it may be endianness?

That is a too broad statement (although in the end it might be just related to endianess).

Think to yourself, what is different between the two (native vs hosted).

For instance, i run AROS hosted on my eeebox (windows) but run AROS natively on it as well. Therefor endianess is the same.

The only thing that differs there is that native AROS uses another driver vs hosted. Then you have your different drivers when running native. Did i start AROS using vesa or did i told AROS to use the GMA driver ?

Taking only hosted vs native into consideration is not enough to be able to conclude anything from your findings unless you take a note of these additional details.

Also note that it might even be that it is known for some drivers to 'lack' this or that feature (or have (reported) bugs).

btw, have you verified against ABIv1 as well ? It might be some of the encountered issues are already resolved there.

Posted on: 11/19 9:07
Transfer the post to other applications Transfer


Re: AROS BMP Picture DataType

Joined:
5/2 17:15
From California, United States
Group:
Member
Posts: 134
Offline
That's very true. I did consider the video drivers such as Native GMA that I'm using vs. Whatever AROS Hosted is using. I haven't dis-counted possible driver issues, but I can't think of any obvious way a driver could cause the behavior I'm seeing. Maybe but I get the same errors with the Vesa driver. I even tested the BMP Images using the Icaros Desktop Live!DVD which I assume is still ABIvO?

The AROS Hosted test setup was using ABIv1 though I'm not absolutely sure of that. I believe I'm using ABIv0 since I'm using Icaros Desktop 32 bit.

I know the issues I'm having with 8bit BMP images on my AROS system. If someone else that is using AROS Hosted ABIv1 would like to test the images by opening in MultiView, that might help to narrow down the problem.

Again, you are correct. I don't have enough test information to form a definite conclusion about the causes of these display issues. I only know what happens on my end.

I have only suggested changing the code for the Save BMP function because the results for that are more conclusive. Using MultiView Project>Save As for an 8bit BMP results consistently of a file of 792 bytes of junk. Saving a 24bit BMP results in a file of zero bytes.

I made the changes for Save BMP but they haven't committed them yet. I'm waiting on the changes for loading 8bit images to correct problems I'm seeing until I have more information about what causes it and which flavors of AROS are affected. Per your suggestion keeping legacy support for images less than 8bits is necessary. It's also necessary to build that legacy support into the Save ILBM function for the IFF Datatype as well. Thanks for your input on that.

Posted on: 11/19 12:40
Transfer the post to other applications Transfer



« 1 (2) 3 4 »



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
4359
2 magorium
magorium
4095
3 phoenixkonsole
phoenixkonsole
3892
4 nikolaos
nikolaos
3693
5 deadwood
deadwood
2923
6 ncafferkey
ncafferkey
2646
7 mazze
mazze
2214
8 clusteruk
clusteruk
2109
9 Kalamatee
Kalamatee
2024
10 damocles
damocles
1789
© 2004-2017 AROS Exec