Re: [Adonthell-artwork] Images saving format

[Alexandre Courbot]

> 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.
-- 
http://www.gnurou.org