Confirmed that osg seems to understand them, try it: osgviewer --image cirrus.rgba
So the format is ok, the question is where's the bug? It would certainly seem that it lies in the difference between these two variants of SGI images. It's probably within OSG itself. The other question is, what should we do about it? Obviously the best thing is for the bug to be fixed, but I've only ever got silence from the OSG devs. Maybe someone here can be a liason? Or maybe we would report the bug and take the pragmatic approach and convert our images to the safer format. On 7/25/07, Csaba Halász <[EMAIL PROTECTED]> wrote: > On 7/26/07, Hans Fugal <[EMAIL PROTECTED]> wrote: > > > > ImageMagick does not think these corrupted (identify(1) should return > > nonzero if it encounters a corrupted file), but some of them are > > obviously not being interpreted correctly by ImageMagick. Try "display > > cirrus.rgba" to see what I mean. Unfortunately this means we can't > > just use convert(1) or mogrify(1) to fix the files that are broken. > > I have looked at some of them, apparently gimp saves 2 channel > gray/alpha images when it feels like it. > This can be easily checked via the 'file' command. > The SGI image specification (link from the osg loader: > http://local.wasp.uwa.edu.au/~pbourke/dataformats/sgirgb/sgiversion.html) > does not explicitly list this format, but logically I see nothing > wrong with it, since the specification does allow 1 channel gray > images. Adding an alpha channel feels natural. > > Moreover, the osg loader seems to do the right thing: > > unsigned int pixelFormat = > raw->sizeZ == 1 ? GL_LUMINANCE : > raw->sizeZ == 2 ? GL_LUMINANCE_ALPHA : > raw->sizeZ == 3 ? GL_RGB : > raw->sizeZ == 4 ? GL_RGBA : (GLenum)-1; > > (raw->sizeZ is the number of channels) > > I have never seen a corrupted sky like in your screenshot and haven't > experienced any cloud-related crashes either (as far as I can tell). I > don't think the textures are corrupted (I assume they would never work > then). Rather, I think the different memory layout (due to the > different number of channels) might trigger an unrelated bug in the 2 > channel case, or there could be some error in the code path handling > such images. In the first case, converting the textures to 4 channels > might seemingly fix the bug, but it could still be lurking, waiting > for a chance to cause a crash. We should try to pinpoint the exact > cause so that it can be fixed. > > Of course I may be completely wrong... > > Greets, > Csaba > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Hans Fugal Fugal Computing ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
