Discussion:
Decompressing Compressed Textures
Chris Denham
2011-06-20 08:53:47 UTC
Permalink
Hi,
I have a question about extracting images from an IVE with compressed textures.
I have a some IVE format files that have been created using a command line e.g. "OSGCONV --compressed input.flt output.ive"
This works fine, but the problem I have is that I want to be able to reverse the process, e.g.
"OSGCONV -O OutputTextureFiles input.ive output.osg"
The problem being, the original JPG texture images referred to by input.flt can not be written out because the OSG JPG writer only seems to support image pixel format GL_LUMINANCE, GL_ALPHA & GL_RGB. That is, it doesn't convert from the compressed DDS type images that are embedded in the IVE file when using the "--compressed" option.

My question is, can anyone provide any tips on how to extract JPG images from an IVE with emeddeded compressed textures? In other words, is there a way to reverse the compression applied in osgconv by its CompressTexturesVisitor code?

Thank you!

Cheers,
Chris

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=40679#40679
Torben Dannhauer
2011-06-20 09:13:46 UTC
Permalink
Hi,

OSG provides an image processor class, it is used to compress and decompress image, maybe you can use it.

Thank you!

Cheers,
Torben

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=40680#40680
Chris Denham
2011-06-20 10:35:36 UTC
Permalink
Thanks for the tip Torben,
When I call osgDB::Registry::instance()->getImageProcessor(), I get NULL coming back. Digging a bit deeper, OSGs image processor relies on NVTT plugin, which relies on Nvidias NVTT SDK, which I'm struggling to find on the interweb. If you have a link to NVTT SDK download handy, could you send it to me.

I'm sensing I might need to pass through the flaming gauntlet just to get to a point where I can get a feeling for whether this is going to help me. ;-)

BTW. Does this reliance on NVTT mean it would only work in NVidia hardware?

Cheers.
Chris.
Post by Torben Dannhauer
Hi,
OSG provides an image processor class, it is used to compress and decompress image, maybe you can use it.
Thank you!
Cheers,
Torben
------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=40682#40682
Torben Dannhauer
2011-06-20 10:44:08 UTC
Permalink
Hi,

what is your development environment?

for windows / Visual Studio 2008 I provide a 3rdParty plugin which contains a lot precompiled 3rdParty plugins OSG support - including NVTT.


Thank you!

Cheers,
Torben

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=40683#40683
Chris Denham
2011-06-20 12:34:19 UTC
Permalink
Hi Torben,
On Windows, we are using Visual Studio 2005.
But I eventually found the link to NVTT download:
http://developer.nvidia.com/gpu-accelerated-texture-compression
I'll see if I have any success with that.
Cheers,
Chris

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=40686#40686
Torben Dannhauer
2011-06-20 12:52:01 UTC
Permalink
Hi,

good lucki, it should work.

Thank you!

Cheers,
Torben

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=40687#40687
Chris Denham
2011-06-20 14:06:26 UTC
Permalink
Hi Torben,
I've managed to build the NVTT plugin using that download, but now I'm still a bit stumped. The plugin and NVTT api seems to work, but it all seems geared towards compression rather than decompression.
I was hoping that I would be able to use it like:

Code:

osg::ref_ptr<osgDB::ImageProcessor> processor = osgDB::Registry::instance()->getImageProcessor();
processor->compress(osgImage, osg::Texture::USE_IMAGE_DATA_FORMAT, false, false, osgDB::ImageProcessor::USE_GPU, osgDB::ImageProcessor::NORMAL);


i.e. with second parameter with an uncompressed format. But this doesn't really work because the input image appears to be required to be in uncompressed RGB or RGBA.
In fact, looking at the nvtt.h header file the ONLY option for input format appear to be BRGA_8UB, and the plugin always converts to that assuming that input osg image is RGB or RGBA, and makes a "dogs breakfast" of anything else.

Ho hum... any more thoughts?

Thanks.
Chris

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=40689#40689
Torben Dannhauer
2011-06-20 14:39:27 UTC
Permalink
Hi, Chris,

I never used the imageProcessor myself (but I think I will in some month), so all I can do is to give you some free shots:

I read into the code a little bit. You are right it looks like it provides only compression currently.

Background: The NVTT integration was originally implemented into VirtualPlanetBuilder to allow NVTT usage for creating osgTerrain databases with VPB. Because it hast at all a more general focus, Robert create the ImageProcessor definition and created an NVTT based image Processor. Now VPB uses these ImageProcessor if available.
Because VPB only creates terrain, no decompressing function was required.
I'm sure NVTT provides not only compression but also decompression.

In my opinion the right way would be:
* Extending osgDb::ImageProcessor to provide and decompress interface
* Extending osgPlugins/nvtt/NVTTImageProcessor.cpp to implement the decompressing feature.

We should ask Robert for a (very) short statement before anyone starts implementing this, I'm not sure if I got all aspects and my advice is correct.

Having an decompressing feature would be nice! :)

Thank you!

Cheers,
Torben

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=40690#40690
Robert Osfield
2011-06-20 14:46:03 UTC
Permalink
Post by Torben Dannhauer
* Extending osgDb::ImageProcessor to provide and decompress interface
* Extending osgPlugins/nvtt/NVTTImageProcessor.cpp to implement the decompressing feature.
We should ask Robert for a (very)  short statement before anyone starts implementing this,  I'm not sure if I got all aspects and my advice is correct.
My short answer is "my focus 3.0.0, everything else gets shunted till
after the release"

Long answer is "yep, why not, go ahead an tinker, if it works submit
it to osg-submissions, but don't expect me to merge/review/participate
in discussions beyond a simply grunt."

Robert.
Chris Denham
2011-06-20 15:49:49 UTC
Permalink
Hi Torben,
Yes, I was thinking along the same lines.

I was just having a peep at the source of decompress.cpp that comes with the NVIDIA texture tools that might give a clue about the best way to do it. Which seemed to boil down to:

Code:
nv::DirectDrawSurface dds(inputImageFile);
nv::StdOutputStream stream(outputTGAfile);
nv::Image img;
dds.mipmap(&img, 0, 0); // get first image
nv::ImageIO::saveTGA(stream, &img);



Though it's not clear exactly whether the mipmap function, or saveTGA does the decompression.

I can't help wondering if we are missing a trick with OSG's DDS plugin?
It looks as though it might contain some reusable magic for these kind of compression formats. :-)

Cheers,
Chris

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=40691#40691
Robert Osfield
2011-06-20 16:35:33 UTC
Permalink
HI Chris,
Post by Chris Denham
I can't help wondering if we are missing a trick with OSG's DDS plugin?
It looks as though it might contain some reusable magic for these kind of compression formats. :-)
The DDS plugin just reads and write compressed formats as a single
block there is no compression of decompression either way.

As a general note I would add that all OpenGL compressed formats a
lossy are a pretty poor at representing the original images, they
don't come close to the likes of jpeg, png etc in terms of compression
quality. So uncompressing a GL compressed image will not result in
good results and is never intented to - it's all about getting good
performance down the GPU. Given these constraints it far better to
keep around the original images and do work on them and re-generate
the compressed data when needed, and only ever view the GL compressed
formats as write only.

Robert.
Robert Osfield
2011-06-20 11:38:34 UTC
Permalink
Hi Chris,
Post by Chris Denham
BTW. Does this reliance on NVTT mean it would only work in NVidia hardware?
NVTT provides software implementations that are not dependant on any
particular hardware of GL drivers.

I would add that the new ImageProcessor functionality is meant for
compression data rather than uncompressing.

Robert.
Ralph Kern
2011-06-20 14:24:30 UTC
Permalink
Hi Chris,

why don't you just render the texture to another RTT / offscreen buffer
and read out the pixels... should be hardware accelerated

regards Ralph
Post by Chris Denham
Hi,
I have a question about extracting images from an IVE with compressed textures.
I have a some IVE format files that have been created using a command line e.g. "OSGCONV --compressed input.flt output.ive"
This works fine, but the problem I have is that I want to be able to reverse the process, e.g.
"OSGCONV -O OutputTextureFiles input.ive output.osg"
The problem being, the original JPG texture images referred to by input.flt can not be written out because the OSG JPG writer only seems to support image pixel format GL_LUMINANCE, GL_ALPHA & GL_RGB. That is, it doesn't convert from the compressed DDS type images that are embedded in the IVE file when using the "--compressed" option.
My question is, can anyone provide any tips on how to extract JPG images from an IVE with emeddeded compressed textures? In other words, is there a way to reverse the compression applied in osgconv by its CompressTexturesVisitor code?
Thank you!
Cheers,
Chris
------------------
http://forum.openscenegraph.org/viewtopic.php?p=40679#40679
Torben Dannhauer
2011-06-20 16:39:11 UTC
Permalink
Hi Robert,

thanks for your statement, that was new to me. So you suggest NOT to integrate a decompressen feature? WEnlll then we should'nt do it ;)

Thank you!

Cheers,
Torben

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=40694#40694
Robert Osfield
2011-06-20 16:54:44 UTC
Permalink
Post by Torben Dannhauer
Hi Robert,
thanks for your statement, that was new to me.
Which statement of mine? About GL compressed being
Post by Torben Dannhauer
So you suggest NOT to integrate a decompressen feature? WEnlll then we should'nt do it ;)
Not for 3.0.0. After that, we'll I won't be implementing, but others
are welcome to if they find it useful. However, I can't see it being
that useful as GL compression really isn't meant as an interchange
format.

Robert.
Chris Denham
2011-06-20 17:01:07 UTC
Permalink
Hi Robert,

Thanks for the clarification. I hadn't realised the compression was particulary lossy as viewing the IVE files we are using (with compressed textures) seem to have an acceptable quality for our purposes. But you are right, ideally it would be better to keep the original textures, but it is also nice to avoid file management headaches. The problem is that our clients create catlogues of models using IVE files, and once they are happy with the results, we need to pass the catalogue through a conversion process to allow it to be used in a non-osg based application. Hence the need to extract the embedded textures. We can tell them not to compress the textures, but then that would make their catalogues at least twice the size.

Cheers,
Chris

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=40697#40697

Continue reading on narkive:
Loading...