RE: [Flightgear-devel] fun with SGI images
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Melchior
FRANZ
Sent: 11 January 2005 14:03
To: flightgear-devel@flightgear.org
Subject: [Flightgear-devel] fun with SGI images
Erik reminded me to finish a program that I had written a
while ago. It uses
the SGI Image loader/saver that I had written for KDE to
optimize image files,
without changing the image contents. This is done by reducing
unused layers,
using better compression, and not compressing where this
actually generates
smaller images. I let this program now run over the
directories Textures{,.high}/
and Aircraft/ and got this difference:
cvs:223.61 MB
recoded:182.09 MB
--
savings: 41.52 MB
Now, what does it mean? That we should change all rgb(a), and
let every
cvs users sync down 182 MB? Of course, not. But paying a little more
attention to SGI images wouldn't hurt.
m.
Do the texture files _have_ to be in RGB(A) format?
I understand that lossy compression on textures is evil and wrong
(http://www.sjbaker.org/steve/omniv/jpegs_are_evil_too.html), but what about
PNG or even TIFF? These give smaller files with no information loss, and both
support alpha layers properly.
Looking at the plib documentation, it says:
Currently, only SGI format and uncompressed 8 or 24 bit BMP images are
supported - but more formats are planned for the future. Filenames ending with
'.rgb', '.rgba', '.int', '.inta', '.bw' are assumed to be SGI formatted files,
'.bmp' are in Microsoft's BMP format and '.png' are in Portable Network
Graphics format. (http://plib.sourceforge.net/ssg/state.html)
Which first says that PNG is not supported, but then implies that it is. Does
anyone know whether plib will load PNG files as textures?
Richard
This e-mail has been scanned for Bede Scientific Instruments for all
viruses by Star Internet. The service is powered by MessageLabs. For
more information on a proactive anti-virus service working around the
clock, around the globe, visit: http://www.star.net.uk
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fun with SGI images
Richard Bytheway wrote:
-Original Message-
[mailto:[EMAIL PROTECTED] Behalf Of Melchior
FRANZ
I let this program now run over the
directories Textures{,.high}/
and Aircraft/ and got this difference:
cvs:223.61 MB
recoded:182.09 MB
--
savings: 41.52 MB
Do the texture files _have_ to be in RGB(A) format?
Yes, any other (non OpenGL supported format) just saves some disk space
but no texture memory. As far as I understand it, OpenGL supports
compressed RGB images _in_memory_. So I think we should update CVS as well.
Erik
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fun with SGI images
Erik Hofman wrote:
Richard Bytheway wrote:
-Original Message-
[mailto:[EMAIL PROTECTED] Behalf Of Melchior
FRANZ
I let this program now run over the directories Textures{,.high}/
and Aircraft/ and got this difference:
cvs:223.61 MB
recoded:182.09 MB
--
savings: 41.52 MB
Do the texture files _have_ to be in RGB(A) format?
Yes, any other (non OpenGL supported format) just saves some disk
space but no texture memory. As far as I understand it, OpenGL
supports compressed RGB images _in_memory_. So I think we should
update CVS as well.
My understanding is that there is a special api the driver/card provides
for compressed textures. Remember that it is *plib* that does the
texture loading. It reads from the disk and decompresses it into a raw
format internally which it can hand off to the opengl api. If *plib*
can't read Melchior's better compression scheme, then there's not too
much point in doing it.
Regards,
Curt.
--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program http://www.humanfirst.umn.edu/
FlightGear Project http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fun with SGI images
On Tue, 11 Jan 2005 15:42:30 +0100, Erik wrote in message [EMAIL PROTECTED]: Yes, any other (non OpenGL supported format) just saves some disk space but no texture memory. As far as I understand it, OpenGL supports compressed RGB images _in_memory_. ..here you mean in video card texture memory? -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fun with SGI images
Arnt Karlsen wrote: On Tue, 11 Jan 2005 15:42:30 +0100, Erik wrote in message [EMAIL PROTECTED]: Yes, any other (non OpenGL supported format) just saves some disk space but no texture memory. As far as I understand it, OpenGL supports compressed RGB images _in_memory_. ..here you mean in video card texture memory? Yep, textures can be removed from main memory when sent to the OpenGL driver(*). Erik (*) Well, OpenGL still keeps a copy in main memory. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fun with SGI images
On Tue, 11 Jan 2005 23:13:16 +0100, Erik wrote in message [EMAIL PROTECTED]: Arnt Karlsen wrote: On Tue, 11 Jan 2005 15:42:30 +0100, Erik wrote in message [EMAIL PROTECTED]: Yes, any other (non OpenGL supported format) just saves some disk space but no texture memory. As far as I understand it, OpenGL supports compressed RGB images _in_memory_. ..here you mean in video card texture memory? Yep, textures can be removed from main memory when sent to the OpenGL driver(*). Erik (*) Well, OpenGL still keeps a copy in main memory. ..yeah, I'm _guessing_ main memory copies and AMD K6-2 flags like these 3dnow k6_mtrr might need a K6 kernel (or not?) might fool OpenGL or FG or whatever into doing stuff in the CPU rather than the GPU. Right now I'm running a 386 kernel, and have a few more things I need to get done this week and weekend (thermochemical gasifier test runs). -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
