Number of colors

GFA, ASM, STOS, ...

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

jury
Captain Atari
Captain Atari
Posts: 278
Joined: Tue Sep 21, 2004 11:11 am
Location: Poland

Number of colors

Postby jury » Mon May 07, 2018 7:22 am

I'm a bit lost trying to get more that few "colors on screen" through Hatari.
I would like to achive lowres and 640x480 in 8bit colors, but do not come even close to it. All I can see is just few colors and it looks ugly.
I have set system to Falcon and TOS is 4.04. Tried monitor settings as RGB and VGA.
How do I set up Hatari as a Falcon displaying 640x480x256?
Hatari is v2.0.0

edit:
And of course in TOS I have properly set resolution and colors ( like equivalent to 640x480x256 )

User avatar
dhedberg
Atari Super Hero
Atari Super Hero
Posts: 716
Joined: Mon Aug 30, 2010 8:36 am
Contact:

Re: Number of colors

Postby dhedberg » Mon May 07, 2018 7:58 am

jury wrote:I'm a bit lost trying to get more that few "colors on screen" through Hatari.
I would like to achive lowres and 640x480 in 8bit colors, but do not come even close to it. All I can see is just few colors and it looks ugly.
I have set system to Falcon and TOS is 4.04. Tried monitor settings as RGB and VGA.
How do I set up Hatari as a Falcon displaying 640x480x256?
Hatari is v2.0.0

edit:
And of course in TOS I have properly set resolution and colors ( like equivalent to 640x480x256 )

Well, what do you mean by getting more colors on screen? Do you mean the desktop or are you programming something?
The desktop is not using more than 16 colors for icons and such regardless if you're in 16, 256, or TrueColor mode.
Daniel, New Beat - http://newbeat.atari.org. Like demos? Have a look at our new Falcon030 demo MORE.

User avatar
Cyprian
Atari God
Atari God
Posts: 1488
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: Number of colors

Postby Cyprian » Mon May 07, 2018 8:28 am

jury, co się stało się?
Jaugar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Aranym / Steem / Saint
http://260ste.appspot.com/

jury
Captain Atari
Captain Atari
Posts: 278
Joined: Tue Sep 21, 2004 11:11 am
Location: Poland

Re: Number of colors

Postby jury » Mon May 07, 2018 12:29 pm

I have a picture 640x480x256 which looks like the one attached named f2.jpg, but when simply displaying it through:

Code: Select all

#include "SDL/SDL.h"
int main( int argc, char* args[] )
{
    SDL_Surface* pic = NULL;
    SDL_Surface* screen = NULL;
    SDL_Init( SDL_INIT_EVERYTHING );
    screen = SDL_SetVideoMode( 640, 480, 8, SDL_SWSURFACE );
    hello = SDL_LoadBMP( "pic.bmp" );
    SDL_BlitSurface( hello, NULL, screen, NULL );
    SDL_Flip( screen );
    SDL_Delay( 2000 );
    SDL_FreeSurface( hello );
    SDL_Quit();
    return 0;
}


It shows as attached f1.jpg, which looks dirty and ugly. I do not have a working Falcon now to check it, but this has looked fine there.
Firstly I though that I did a bad Hatari setup as my other tests also gave weird results, but those tests were probably wrong and lately I tested Hatari more and it seems that it should be fine. So I do not know whats going on.
You do not have the required permissions to view the files attached to this post.

User avatar
Cyprian
Atari God
Atari God
Posts: 1488
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: Number of colors

Postby Cyprian » Mon May 07, 2018 1:52 pm

I guess its just SDL issue, therefore would be better is move to Coding section.
There is a powerful debugger build in Hatari. You could check Falcon Shift Mode: $FFFF8266.w whether Videl
is in 8bpp video mode: https://mikro.naprvyraz.sk/docs/mikro/videl.html
Jaugar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Aranym / Steem / Saint
http://260ste.appspot.com/

User avatar
dhedberg
Atari Super Hero
Atari Super Hero
Posts: 716
Joined: Mon Aug 30, 2010 8:36 am
Contact:

Re: Number of colors

Postby dhedberg » Mon May 07, 2018 2:08 pm

Is the palette set correctly? The Falcon uses a longword for each color where the R, G, B components make up a byte each on the form RRGGxxBB.
Note that only the higher 6-bits are used for the R, G, B components, the lower 2-bits are ignored, but that's OK. Because of this the Falcon has a palette of 262,144 colors, whereas if it would have supported 8-bit components it would have had a palette of ~16.8 million colors.
Daniel, New Beat - http://newbeat.atari.org. Like demos? Have a look at our new Falcon030 demo MORE.

jury
Captain Atari
Captain Atari
Posts: 278
Joined: Tue Sep 21, 2004 11:11 am
Location: Poland

Re: Number of colors

Postby jury » Mon May 07, 2018 5:15 pm

dhedberg wrote:Is the palette set correctly?

I have no idea. Untill now I just used different bmp's and those worked fine so I did not take any care for palette. Especially that I would guess that regarding a pallete setup its rather static up to single bit. So thanks for suggestion, I will check it.

Cyprian wrote:I guess its just SDL issue, therefore would be better is move to Coding section.
There is a powerful debugger build in Hatari. You could check Falcon Shift Mode: $FFFF8266.w whether Videl
is in 8bpp video mode: https://mikro.naprvyraz.sk/docs/mikro/videl.html


I'm absoluteley new to Hatari so I'm just learning it ( by playing with it and slowly reading the manual ), but this 'powerful debugger built in Hatari' sounds great. Must check it.

jury
Captain Atari
Captain Atari
Posts: 278
Joined: Tue Sep 21, 2004 11:11 am
Location: Poland

Re: Number of colors

Postby jury » Tue May 08, 2018 3:56 pm

dhedberg wrote:Is the palette set correctly? The Falcon uses a longword for each color where the R, G, B components make up a byte each on the form RRGGxxBB.
Note that only the higher 6-bits are used for the R, G, B components, the lower 2-bits are ignored, but that's OK. Because of this the Falcon has a palette of 262,144 colors, whereas if it would have supported 8-bit components it would have had a palette of ~16.8 million colors.


Wait, you are probabbly right with the above, but as I do not do it manually but through SDL library I should not care for this kind of low level stuff. I just call the load function and I should get the image properly loaded. But for some reason its not. I also tried png and jpg image loading throug SDL_image library, but the result is the same :(

Cyprian wrote:I guess its just SDL issue, therefore would be better is move to Coding section.
There is a powerful debugger build in Hatari. You could check Falcon Shift Mode: $FFFF8266.w whether Videl
is in 8bpp video mode: https://mikro.naprvyraz.sk/docs/mikro/videl.html


Checked $FFFF8266.w content through Hatari debugger and it shows $0010, so it seems that yes, Videl is in 8 bitplane mode.

But it has worked fine before on the Falcon at the beginning of the year when I was playing with SDL a little. So maybe the images I used earlier on the Falcon just were not so complicated so thats why those seemed to display fine when loaded through SDL or SDL_image functions.

User avatar
Cyprian
Atari God
Atari God
Posts: 1488
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: Number of colors

Postby Cyprian » Tue May 08, 2018 6:02 pm

try to load Falcon color palette on your own $FFFF9800 - $FFFF98FC
Jaugar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Aranym / Steem / Saint
http://260ste.appspot.com/

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1712
Joined: Sun Jul 31, 2011 1:11 pm

Re: Number of colors

Postby Eero Tamminen » Tue May 08, 2018 6:28 pm

In case there are multiple SDL Atari version floating around, which SDL version you're using? And which SDL driver you use?

jury
Captain Atari
Captain Atari
Posts: 278
Joined: Tue Sep 21, 2004 11:11 am
Location: Poland

Re: Number of colors

Postby jury » Thu May 10, 2018 8:14 pm

Eero Tamminen wrote:In case there are multiple SDL Atari version floating around, which SDL version you're using?

The version downloaded couple months ago from Patrice's blog. Its the one from 14th october last year.

Eero Tamminen wrote:And which SDL driver you use?

No idea. Its the default one in TOS ( I forgot which one it is but as it runs in fullscreen I would guess its xbios one )

Cyprian wrote:try to load Falcon color palette on your own $FFFF9800 - $FFFF98FC


Yes, but first I need to do some palette conversion, as loading it in the form its in the file would probably give the same result ( but tomorrow when I will have some time I will try anyway )
So it seems Daniel is right, as the palette on Falcon uses 6 bits for Red, Green and Blue it has to be set properly when image is a 'standard' 8-bit palette.
I tried Apex and GrafX, but did not find any way of reducing palette to 6 bits, there are options to choose number of colors for an image in every paint program, but it seems that customizing palette is not something common there.

Any suggestions how to do this conversion are welcome. It could be a name of a paint app or an info how to do this conversion 'manually' so I could try to implement it in code after displaying an image.

And by the way, reading about 'bmp and company' I found out something that I would not expect: there was even 8-bit 'true color mode'.
From wikipedia:
"The other form is where the 8 bits directly describe red, green, and blue values, typically with three bits for red, three bits for green and two bits for blue. This second form is often called 8-bit truecolor, as it does not use a palette at all, and is thus more similar to the 15-bit, 16-bit, and 24-bit truecolor modes."
Last edited by jury on Thu May 10, 2018 8:25 pm, edited 1 time in total.

User avatar
dhedberg
Atari Super Hero
Atari Super Hero
Posts: 716
Joined: Mon Aug 30, 2010 8:36 am
Contact:

Re: Number of colors

Postby dhedberg » Thu May 10, 2018 8:25 pm

The 6-bits per component is not a problem. Falcon stores the components in 8-bit but only cares about highest 6-bits. I think the problem is more likely the order of the components in the Falcon palette. The Falcon uses the RRGGxxBB format (where xx means "not used"). The palette is most likely stored as just RRGGBB in the file, and is probably set as RRGGBBxx, or xxRRGGBB, which means you'll lose either the blue or red component.
Last edited by dhedberg on Mon May 14, 2018 9:37 am, edited 1 time in total.
Daniel, New Beat - http://newbeat.atari.org. Like demos? Have a look at our new Falcon030 demo MORE.

jury
Captain Atari
Captain Atari
Posts: 278
Joined: Tue Sep 21, 2004 11:11 am
Location: Poland

Re: Number of colors

Postby jury » Thu May 10, 2018 9:17 pm

dhedberg wrote:The 6-bits per component is not a problem. Falcon stores the components in 8-bit but only cares about highest 6-bits.


Yes, I understand this, but if the original image, where 8-bit palette is used is loaded in Falcon which will 'cut' the 2 bits off ( wchich were used ), some information of a color will be lost, so the picture should look sometimes quite strange, isn't it? So I would understand, that there needs to be done some conversion, where each color is converted from 8bit ( 16 mln palette ) to the closest possible 6-bit color from the 262 thousands palette and sure each of those 6-bit components can be written to a byte where 2 bits will be 'empty'. Or I got it wrong?

dhedberg wrote: I think the problem is more likely the order of the components in the Falcon palette. The Falcon uses a RRGGxxBB format (where xx means "not used"). The palette is most likely stored as just RRGGBB in the file, and is probably set as RRGGBBxx, or xxRRGGBB, which means you'll lose either the blue or red component.


And this could be another thing ( but rather easy to solve as its just the order of color components )

User avatar
dhedberg
Atari Super Hero
Atari Super Hero
Posts: 716
Joined: Mon Aug 30, 2010 8:36 am
Contact:

Re: Number of colors

Postby dhedberg » Thu May 10, 2018 9:59 pm

No conversion needed as it is the 2 lowest bits that are ignored.
Daniel, New Beat - http://newbeat.atari.org. Like demos? Have a look at our new Falcon030 demo MORE.

jury
Captain Atari
Captain Atari
Posts: 278
Joined: Tue Sep 21, 2004 11:11 am
Location: Poland

Re: Number of colors

Postby jury » Sun May 13, 2018 7:26 pm

I have trouble loading the palette from bmp file. Well, it generally loads for sure, as the colors change, but they are quite wrong.
From what I have read and understand about bmp file format, the palette for 8bit color images usually starts from byte 54 and is in format of 4 bytes ( red, green, blue, and 0 as last byte )
When I open up the desired bmp in hex editor it seems exactly like specified, at 54 byte I can see a series of 3 byte values followed by byte with 0. But when I try to load this sequence starting into 0x00ff9800 ( changing component order to red, green, zero, blue ) the image colors are quite a mess.
If anyone has a clue, please share :)

This is a function reading the bmp file and trying to set the palette directly to Videl registers:

Code: Select all

int set_palette_falcon ()
{      
   long p_super;
   unsigned char *p_screen;
   FILE *p_file;
   int i;
   struct rgb palette;
   
   printf ( "set_palette_falcon\n" );
   
   p_super = Super ( 0 );
      
   p_file = fopen ( "hello.bmp", "rb" );
   
   if (!p_file)
   {
      printf ( "Problem opening bmp\n" );
      return 1;
   }
   else
   {
      printf ( "Bmp opened in set_palette_falcon\n" );
   }
   
   fseek ( p_file, 54, SEEK_SET );
   
   // set palette from bmp
   i = 0;
   p_screen = 0x00ff9800;
   for ( i ; i < 255; i++ )
   {
      fread ( &palette, sizeof ( struct rgb ), 1, p_file );
      printf ( "r=%d g=%d b=%d z=%d\n", palette.r, palette.g, palette.b, palette.z );
      *p_screen = palette.r;
      p_screen++;
      *p_screen = palette.g;
      p_screen++;
      p_screen++;
      *p_screen = palette.b;
      p_screen++;
   }
   
   Super ( p_super );   
   fclose ( p_file );
   return 0;   
}

ThorstenOtto
Captain Atari
Captain Atari
Posts: 312
Joined: Sun Aug 03, 2014 5:54 pm

Re: Number of colors

Postby ThorstenOtto » Mon May 14, 2018 6:34 am

jury wrote:From what I have read and understand about bmp file format, the palette for 8bit color images usually starts from byte 54


Usually maybe, but not always. BMP files consist of a 14 byte file header, a BITMAPINFOHEADER, the palette, and then the data. The offset 54 is only valid when the file has an old BITMAPINFOHEADER, but actually it can have different sizes (you can check the first LONG after the file header, it should be 40 in your case).

for ( i ; i < 255; i++ )


Why 255? Normally, there should be 256 entries. Also there might be files where the biClrUsed entry is set; in that case the palette might have fewer entries. And of course you should check at least whether the file has 8 planes at all.

*p_screen = palette.r;
p_screen++;


I'm not entirely sure whether that makes a difference, but you should construct the value from the rgb entries, then write it as long.

jury
Captain Atari
Captain Atari
Posts: 278
Joined: Tue Sep 21, 2004 11:11 am
Location: Poland

Re: Number of colors

Postby jury » Fri May 18, 2018 6:56 pm

Thank you for the suggestions.

ThorstenOtto wrote:
jury wrote:From what I have read and understand about bmp file format, the palette for 8bit color images usually starts from byte 54

Usually maybe, but not always. BMP files consist of a 14 byte file header, a BITMAPINFOHEADER, the palette, and then the data. The offset 54 is only valid when the file has an old BITMAPINFOHEADER, but actually it can have different sizes (you can check the first LONG after the file header, it should be 40 in your case).


As for the offset 54, I forgot to mention that I have checked biSize in the header and it was stating exactly 40 bytes, so the palette has to start at offset 54 and as I mentioned, starting from this offset it seems as the color data ( 3 bytes of some values + one 0 byte ).

ThorstenOtto wrote:
for ( i ; i < 255; i++ )


Why 255? Normally, there should be 256 entries. Also there might be files where the biClrUsed entry is set; in that case the palette might have fewer entries. And of course you should check at least whether the file has 8 planes at all.


Yep, you are right. Its a typo and should be of course 256. If i goes for biClrUsed entry it has 0, so from the format description it means that all the indexes for the palette are used.
And if it goes for checking if the file has 8 planes, how to check it? I do not see this kind of information in the bmp format description, besides biPlanes which states "This is the number of image planes in the image. It is always equal to 1", and it is exactly 1 in my case.

ThorstenOtto wrote:
*p_screen = palette.r;
p_screen++;

I'm not entirely sure whether that makes a difference, but you should construct the value from the rgb entries, then write it as long.


Well, seems that it shouldn't make a difference. I have written to Patrice and he adviced me to use SDL's own mechanisms: getting the colors from SDL_PixelFormat structure ( so it seems that I tried to reinvent the wheel :) )
I did so, got the colors from there and set the palette with SDL_SetPalette and I got the same result, exactly the same color mess I'm getting if I read the colors directly from the BMP file and put them directly to Videl registers. So it seems that the problem must lies somewhere else. Below is the whole code for viewing this bmp, maybe someone will spot something.
Also, can someone please name some BMP Viewer for Falcon? I tried couple of programs but did not find a bmp format.

Code: Select all

#include "SDL/SDL.h"
#include <stdio.h>
#include <osbind.h>

const int SCREEN_WIDTH = 640;
const int SCREEN_HEIGHT = 480;
const int SCREEN_BPP = 8;

long p_super;
unsigned char *p_screen;
Uint16 *p_spshift;

struct rgb
{
   Uint8 b, g, r, z;   
};   

struct rgb old_palette[256];

SDL_Surface *image = NULL;
SDL_Surface *screen = NULL;

int set_palette_falcon ()
{      
   FILE *p_file, *p_out_pal;
   int i;
   struct rgb palette;
   Uint8 bajt;
   
   printf ( "set_palette_falcon\n" );
   
   p_super = Super ( 0 );
      
   p_out_pal = fopen ( "out_pal.txt", "w" );

   p_file = fopen ( "hello.bmp", "rb" );
   
   if (!p_file)
   {
      printf ( "Problem opening bmp\n" );
      return 1;
   }
   else
   {
      printf ( "Bmp opened in set_palette_falcon\n" );
   }
   
//   fseek ( p_file, 54, SEEK_SET );
//   fread ( &bajt, sizeof ( bajt ), 1, p_file );
//   fprintf ( p_out_pal, "Byte 54: %d\n", bajt );
   
   fseek ( p_file, 54, SEEK_SET );
   
   // set palette from bmp
   i = 0;
   p_screen = 0x00ff9800;
   for ( i ; i < 256; i++ )
   {
      fread ( &palette, sizeof ( struct rgb ), 1, p_file );
//      printf ( "r=%d g=%d b=%d z=%d\n", palette.r, palette.g, palette.b, palette.z );
      fprintf ( p_out_pal, "Pixel Color-> Red: %x, Green: %x, Blue: %x. Index: %d\n", palette.r, palette.g, palette.b, i );
      *p_screen = palette.r;
      p_screen++;
      *p_screen = palette.g;
      p_screen++;
      p_screen++;
      *p_screen = palette.b;
      p_screen++;
   }
   
   Super ( p_super );   
   fclose ( p_file );
   fclose ( p_out_pal );
   return 0;   
}

int main( int argc, char* args[] )
{
   SDL_PixelFormat *fmt;
   SDL_Color colors[256];
   int index;
   FILE *p_file_out;   
   int i;
   
   p_file_out = fopen ( "out.txt", "w" );
   p_super = Super ( 0 );
   p_spshift = 0x00ff8266;
   fprintf ( p_file_out, "1 spshift: %d\n", *p_spshift );
   
   //save old palette
   p_screen = 0x00ff9800;
   i = 0;
   for ( i ; i < 256 ; i++ )
   {
      old_palette[i].r = *p_screen;
      p_screen++;
      old_palette[i].g = *p_screen;
      p_screen++;
      p_screen++;
      old_palette[i].b = *p_screen;
      p_screen++;
   }   
   
   Super ( p_super );
   
   SDL_Init( SDL_INIT_EVERYTHING );
   screen = SDL_SetVideoMode( 640, 480, 8, SDL_SWSURFACE );
   image = SDL_LoadBMP( "hello.bmp" );
   
   p_super = Super( 0 );
   fprintf ( p_file_out, "2 spshift: %d\n", *p_spshift );
   Super ( p_super );
   
   SDL_BlitSurface( image, NULL, screen, NULL );
   SDL_Flip( screen );
   
   // setting the palette by using Falcon hardware
   set_palette_falcon();

   //setting the palette by using SDL structure
//   fmt = image->format;
//   if ( fmt->BitsPerPixel != 8 )
//      fprintf ( p_file_out, "Not an 8-bit surface.\n" );
//   else
//      fprintf ( p_file_out, "8-bit surface.\n" );
//   SDL_LockSurface ( image );
//   index = 0;
//   for ( index ; index < 256 ; index++ )
//   {
//      colors [ index ] = fmt->palette->colors[index];
//      fprintf ( p_file_out, "Pixel Color-> Red: %d, Green: %d, Blue: %d. Index: %d\n", colors[index].r, colors[index].g, colors[index].b, index );
//   }
   
//   SDL_UnlockSurface ( image );

//   SDL_SetPalette ( screen, SDL_LOGPAL|SDL_PHYSPAL, colors, 0, 256 );

//   SDL_Delay ( 1500 );

   SDL_Delay ( 1500 );
   SDL_FreeSurface( image );
   SDL_Quit();
   
   p_super = Super( 0 );
   
   // restore old palette
   i = 0;
   p_screen = 0x00ff9800;
   
   for ( i ; i < 256 ; i++ )
   {
      *p_screen = old_palette[i].r;
      p_screen++;
      *p_screen = old_palette[i].g;
      p_screen++;
      p_screen++;
      *p_screen = old_palette[i].b;
      p_screen++;
   }
   p_screen--;
   printf ( "pointer_end=%x\n", p_screen );

   Super ( p_super );
   fclose ( p_file_out);
   return 0;
}


rockyone
Captain Atari
Captain Atari
Posts: 424
Joined: Thu Jan 20, 2011 8:47 pm
Location: France
Contact:

Re: Number of colors

Postby rockyone » Sat May 19, 2018 2:39 pm

jury wrote:From what I have read and understand about bmp file format, the palette for 8bit color images usually starts from byte 54 and is in format of 4 bytes ( red, green, blue, and 0 as last byte )
[/code]


You reversed the blue and the red !
May be in your program too :wink:

ThorstenOtto
Captain Atari
Captain Atari
Posts: 312
Joined: Sun Aug 03, 2014 5:54 pm

Re: Number of colors

Postby ThorstenOtto » Sat May 19, 2018 4:40 pm

As for the offset 54, I forgot to mention that I have checked biSize in the header and it was stating exactly 40 bytes


If its only used for your testing code, with a specific test file, thats ok, but of course in your real program you can't rely on that.

And if it goes for checking if the file has 8 planes, how to check it? I do not see this kind of information in the bmp format description, besides biPlanes which states "This is the number of image planes in the image. It is always equal to 1", and it is exactly 1 in my case.


That's because MS has a different idea what a plane should be. Indeed, the Planes number is alway 1 in a BMP file. But there is also a BitCount member, which is the number of bits/pixel.

Well, seems that it shouldn't make a difference.


From the logical point, that is the same. But hardware register might behave differently, depending on whether you do byte accesses or long-word accesses.

User avatar
thothy
Hatari Developer
Hatari Developer
Posts: 426
Joined: Fri Jul 25, 2003 9:36 am
Location: Germany
Contact:

Re: Number of colors

Postby thothy » Sun May 20, 2018 5:13 am

This topic has now been moved to the coding section.

MarkP
Atarian
Atarian
Posts: 5
Joined: Tue Jul 31, 2018 10:22 pm

Re: Number of colors

Postby MarkP » Wed Aug 01, 2018 1:21 am

Having lived through the 256 and 64k colours eras on PC, it looks rather more like a case of a JPG decoder that's flattened a finely-graduated photographic image down to 256 colours in an overly simple manner, possibly not even bothering to customise the palette. Something like that should look just fine with a customised palette even when picking from 32k colours let alone 262k, and maybe even picking colours as closest-match only rather than dithering.

There'd be some reduction in fidelity and a little bit of banding by flattening 24bpp to 15 or 16bpp (32k or 64k colours), but nothing you'd ever really have means to complain about, certainly not to the level pictured. And with the noise introduced by JPEG compression any bands should be broken up somewhat. If your converter also dithered the picture down to 32k/64k it would be almost indistinguishable from the original - I produced many desktop background BMPs using a similar method back in the day when having to choose between VGA rez/24bpp, SVGA rez/16bpp or XGA rez/8bpp. The 256 colour ones tended to come out looking just fine in all but the most pathological cases (and I have to assume those colours were chosen from amongst an 18-bit palette, as that's VGA standard anyway), and the hi-colour ones couldn't be told apart from the originals unless you deliberately looked very closely *trying* to spot the difference. If it was being simply flattened to 262k, from a JPEG original, it'd be difficult to see any change. Certainly wouldn't be anything worth complaining about. A lot of TVs and phone screens actually don't offer anything better than 18-bit colour natively and just use spatial and temporal dithering techniques to break up what obvious bands still remain...

But if you take a photographic picture and flatten it to 32k/64k without dithering you can sometimes tell a difference (mainly on very gentle gradients; any fine patterning hides the lack of colour depth because if you go from black to white, or cream to dark brown, in 64 pixels or less, you can't really see an obvious difference between 8/8/8bpp and 5/6/5bpp...), but if you flatten to 256 colours without dithering, especially with a fixed default palette (even if it's 6/7/6 level or 3/3/2 bit RGB), the loss of colour definition is VERY obvious with any but the simplest and most artificial graphics.


Social Media

     

Return to “Coding”

Who is online

Users browsing this forum: No registered users and 3 guests