Re: [Adonthell-artwork] Images saving format

[cirrus]

Alexandre Courbot wrote:
> 
> Don't know whether it fits better in the devel or artwork list, but
> whatever...
> 
> I am again facing the problem of image saving format. You know that when
> you save an animation for example, all the images are saved one after
> one in the animation file. The images are currently saved in 24bpp
> depth, while the game can run in 16 or 24 bpp depth.
> 
> The problem is that when images get loaded, they are converted to the
> screen depth, for better performances. That means that on my machine for
> example that runs in 16bpp, images are in 16bpp format in memory.
> 
> This is a true problem for editors. When editing animation, map objects
> or map characters, I have to load and save images. But if I work on a
> 16bpp machine, the images are loaded, converted to 16bpp, then converted
> back to 24bpp when I save them. But of course, you lost some colors
> during the 24->16 convertion, which means in this case saving in 24bpp
> is useless.
> 
> The last time I workarounded this by keeping a copy of the "pure" image
> along with the loaded images. That resulted in the creation of the
> image_edit class. But as animation, characters and so on needed to use
> this class too, I had to create animation_edit, mapcharacter_edit,
> etc... classes, with plenty of overloaded methods, which is a pain and
> pig work. Moreover, doing so images cannot be modified, as the copy
> isn't affected by pixel manipulation. I'm thinking a lot about this
> problem since years now and still haven't found something satisfying.
> 
> The ideal for the programmer would be to only have one image class to
> deal with. As we support both 16 and 24 bpp depths, the easiest (and
> only "good" solution I can think of) would be to save our images in
> 16bpp depth. I don't think this will result in gfx quality degrading,
> because the images we use usually don't have that much colors. Also,
> looking at Waste's Edge running in 16bpp, there is nothing shocking -
> it's just as nice as in 24bpp. Moreover this would also make images
> taking less space and being better compressed.
> 
> I'm not sure the gfx guys like the idea - please tell me what you think
> about this. This problem just come from the fact that we support two
> color depths: we have to scale to the lowest one. Of course, if someone
> has a working solution for this problem, keeping 24 bpp depth, I'm all
> for it. But I'd like we settle that so I can work correctly on the
> editors.


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.
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? 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.
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?

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.

        -James

-- 
   ___    ___  ___       ___ 
  /    / /__/ /__/ /  / /__                 Reg. Linux User #148821
 /___ / / \  / \  /__/ ___/@linuxgames.com  www.twiddles.com
                                            adonthell.linuxgames.com