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

[Jan R. <slo...@gm...>]

Am Sat, 18 Nov 2006 09:08:35 -0600 schrieb steve <sjb...@ai...>:

> Yes - that's it exactly.  There is an 'upside down' flag.  This
> is a typically stupid Microsoftian coding stupidity.   It makes

Well, if it's done the right way (only one flag at a fixed place
in the header), it's no problem to write a loader for it, the
overhead is actually very small. I'm not sure but I think TGA
does it that way.

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

In that case I agree. And it's really typical for M$'s file
formats. IMHO the DirectX model format (.x) is the same kind
of mess.
 
> 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.

Personally I prefer .rgb for textures, no problem. But I'd like
to make it easier for Windoze users to create models for my
program, and it's hard to find Windoze tools that can write
.rgb (yes, I know there's a port of the Gimp). And of course,
if PLIB offers the BMP loader as a feature it would be nice
if it would work for as many input files as possible, so
I'm willing to contribute patches to fill the holes if it
isn't too time consuming.

Do you know a good description of the BMP format? I found one
on Wotsit.org, but didn't find any information on the
"upside down" flag.

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

Aaah, found it! I never knew what this function was supposed to
do. I just tested it, and it works. In the meantime I also learned
how to use Image Magick for that purpose:

convert file_alpha.rgb +matte sgi:file_noalpha.rgb

But of course it's much more convenient to do it right inside
the Gimp.

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

Yes, I knew this behaviour, but I never knew how to remove the
alpha channel from existing RGBA images.

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

O.k., less work for me ;-) I'm convinced that it's a practical
solution to leave it as it is and do a proper texture conversion
with other tools.

Kind regards,
Jan R.

-- 
Jan Reucker
email: jan dot reucker at web dot de
web:   http://www.reucker-online.de