Re: [Adonthell-artwork] Images saving format

[Benjamin Walther-Franks]

On Tue, Feb 19, 2002 at 04:04:18PM +0100, Alexandre Courbot wrote:
> 
> > One problem I can see is that all gfx programs I've come across don't
> > let you save as 16-bit. There's usually RGB (which means 24-bit in most
> > cases) and indexed which is up to 256 colours (a la GIF) ...and in
> > Photoshop you have CMYK too, which as far as I know is 32-bit - but
> > that's just for printing anyway.
> 
> Oh - no worries then. Images would still be imported using a 24bpp
> format, like PNM as we always did. Sorry for forgetting mentionning this
> :)
> 
> > I'm not opposed to saving in 16-bit - like you said, for Adonthell it
> > makes no noticable difference. It's just that the editors would have to
> > take 24-bit input images and do the converting themselves. This may
> > raise some problems with the ff00ff masking - presumably other 24-bit
> > values are made to transparent in 16-bit too - I mean for every 256
> > 24-bit colours there's just one 16-bit colour, right? So what are the
> > other 255 colours that will become transparent?
> 
> Everything that reassembles the pink color will become transparent. But
> don't worry, the gap isn't that large. I even remember some of the
> images you or Ben sent me still had pink noise in 16bpp ;)) No, that's
> not a real problem, I think. Just avoid using something which values is
> +-10 the pink noise one :)
> 
>  Also, say I've designed
> > something that consists of several mapobjects that get placed together
> > and two touching parts have slightly different colours ( +/- 1 or 2 in
> > 24-bit RGB ). In 24-bit you will not be able to see the difference but
> > if when converted to 16-bit these colours become further apart you might
> > see a slight difference which would produce an ugly line in the gfx.
> 
> I think on the contrary that these colors will be mapped to the same
> 16bpp one. Anyway if the problem was that serious it would have appeared
> on Waste's Edge (as everything is converted to 16bpp in memory when
> using a 16bpp depth).
> 
> > Just think of 16-bit gradients with their notorious banding - yuk! I
> > guess this all depends a bit on what algorithm you use to convert 24 ->
> > 16-bit.  ...how is 16-bit split up anyway? Is it 5-bit R 6-bit G and
> > 5-bit B or what?
> 
> 5-6-5, yes. 16 bits gradients aren't beautifull, agreed. But when will
> we use gradients in Adonthell anyway?
> 
> > Would it work to always store the gfx in memory as 24-bit and just
> > render them to the desired colour depth. I mean most PC users will
> > (should?) be using 24-bit or more, especially gamers. Sure it uses some
> > more memory but I don't think anyone has less than 64MB these days which
> > ought to suffice... right? Certainly by the time we release 0.4 those
> > specs should be a minimum for most people.
> 
> That would imply realtime conversion for 16bpp depths, which is awfully
> slow. We could also drop 16bpp depth, but in this case only people will
> 24bpp screen will have decent speed. And considering the speed of 16
> over 24, I'd rather be for dropping the second one.
> 
> That's a relief to hear you don't mind, though. This will make things
> much easier for me. I'll wait for Ben's comment first anyway ;)
> Alex.


Well, how nice of you ;) 

As far as I can tell, 16bbp should be enough for our Adonthell gfx. If we can 
live with with a 640x480 resolution, then we should be able to live with 
slightly less colour depth...


BEN