Eric, Did your update or changes make it into the current tree? I'm still having the same problem of clamping when trying to capture an FP16 image. If not, what changes did you make? This is really a show stopper for me, since I need unclamped values to get the real statistics from my HDR scene.
Thanks, Brad --- RSC BDC > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:osg-users- > [EMAIL PROTECTED] On Behalf Of Eric Sokolowsky > Sent: Wednesday, July 05, 2006 2:48 PM > To: osg users > Subject: Re: [osg-users] OpenSceneGraph-1.1 Release Candidate this week > > On Wed, 5 Jul 2006, Robert Osfield wrote: > > > Hi Eric, > > > > On 7/5/06, Eric Sokolowsky <[EMAIL PROTECTED]> wrote: > >> I have determined that when reading a texture back, Image::_pixelFormat > >> and Image::_internalTextureFormat should be set to the same value, > which > >> is obtained with a call to glGetTexLevelParameteriv(textureMode, 0, > >> GL_TEXTURE_INTERNAL_FORMAT, ...). That is fine. But I still haven't > >> found a way to get the pixel format from OpenGL. Perhaps we need to add > >> something to the osg::State to track this. > > > > I'm afraid I'm too cold on this topic to provide much insight. > > Well, the call to glGetTexImage() asks for a format and a type. The > format parameter can be obtained from OpenGL, but the type cannot be. > Therefore, it seems reasonable to add a "type" argument to > osg::Image::readImageFromCurrentTexture, instead of arbitrarily mandating > one type or another. The current implementation is buggy in that it > sets the type parameter to the same internal format that is used as the > format parameter. > > This should also help Brad Colbert with his texture read precision > problem. > > A changed file is forthcoming. > > > >> BTW, the set of images I was having trouble with were not a multiple of > >> four in size. OpenGL will report an error when trying to use a > >> compressed texture with glTexSubImage2D() if the subloaded texture is > >> not of a multiple of four in both dimensions. Is this something that > >> should be checked for by OSG? I have a workaround in my application > that > >> will disable texture compression on images that are not a multiple of > >> four in size. > > > > I believe the limit of a multiple of 4 is something related to the > > S3TC compression where it uses blocks of pixels as its block to do the > > compression. > > Yes, this is exactly the reason. The question is, is it worthwhile coding > a check for this condition in OSG? I don't want to code it if it stands > little success for inclusion in OSG proper. I already have a workaround > for > my application that deals with this situation, but the general solution > might be useful to others as well. The change would merely disable the > compression request for images that are not a multiple of four in either > dimension, when glTexSubImage2D() is called. > > -- > ____ __ Eric Sokolowsky (GST) NASA Goddard Space Flight > Center > / __/__/_/__ Visualization Programmer Scientific Visualization > Studio > / __/ _/ / _/ 301.286.3751 Mailstop 610.3 Bldg 28 Rm > E102 > /___/_//_/__/ [EMAIL PROTECTED] Greenbelt, MD 20771 > _______________________________________________ > osg-users mailing list > [email protected] > http://openscenegraph.net/mailman/listinfo/osg-users > http://www.openscenegraph.org/ _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
