Re: [Plib-devel] Texture loading problems (bmp/rgb)

[steve <sjb...@ai...>]

Jan Reucker wrote:
> Hello,
> 
> I'm currently having two problems with texture loading, and I want
> your opinion if these are real bugs, missing features or whatever.
> 
> First: bmp loading
> 
> As already stated in bug tracker item 1275291, bmp textures are
> displayed flipped (upside down). Is this a generall problem?
> Or does bmp support different modes (like "first pixel bottom left" /
> "first pixel top left") which aren't properly evaluated?
> The loader seems to always flip the loaded data. If someone can
> give me a heads-up on the bmp format details I'd like to prepare
> a bugfix.

Yes - that's it exactly.  There is an 'upside down' flag.  This
is a typically stupid Microsoftian coding stupidity.   It makes
it very fractionally easier for some programs to write out images
if they store them that way up internally - at the price of
belabouring every single image reading program with the additional
code to conditionally flip them back the right way around.

Worse still, the BMP file format is a horrible mess with
multiple headers inside other headers - each of which can have
duplicates of that flag bit.  Some programs set all of the
flag bits - others set only one of them - some seem to treat
the bit as applying consecutively so two 'invert' flags are
supposed to flip it back the right way up.

It's a horrible mess - and I refuse to take the time to sort
it all out.

So don't use BMP.   It's a crappy format anyway.


> Second: rgb loading
> 
> When loading an rgb texture, there's a check if the number of
> bit planes is two or four. If this is the case, the texture
> is deemed to be translucent (translucent greyscale or RGBA).

Right.  There is really no other way to do that.

> But this makes a textured object translucent no matter if the
> texture really uses the alpha channel or not. Wouldn't it make
> more sense to check if any pixels in the alpha channel are
> really set to values less than 1.0? None of the tools I'm currently
> working with (mainly the GIMP) seems to be capable of producing
> a pure RGB .rgb image, only RGBA, so the textured objects will
> randomly be hidden behind other translucent objects.

No - that's not true.  I do this in GIMP all the time - and I
know other people who do it in PhotoShop - so I know it's
possible.  In GIMP, use the 'flatten image' menu item (I think
it's under the 'Image' menu) - then you'll have
no alpha plane in the image at all and when you save you'll
get a 1 or a 3 byte image.   Similarly, if you load an opaque
image (eg from JPEG which doesn't support alpha) and just
write it out, it'll be a 3-band image.  You have to explicitly
add an alpha plane or create an alpha layer to make GIMP
write 2 or 4 bands.

You should do that for images that don't have alpha because
otherwise you are wasting disk space, memory space and texture
memory and making the file take longer to load.

> My only
> choice right now is to fall back to .bmp textures which I don't
> like for several reasons, one being the bug mentioned above.
> Would it hurt to extend the rgb loader like this?

It might break existing programs that load the image and then
add alpha information themselves - so it wouldn't be an entirely
'safe' change.