Hi Robert,
On Monday 06 November 2006 18:10, Robert Osfield wrote:
> > It appears to me that the length of the run length encoding is wrong.
> > That change limits that to the min of the value from the file and the
> > remaining line length. May be this is suficient?
>
> I have just added some debug output to you workaround and get the
> following when reading the sun.rgba:
>
>
> RawImageGetRow -
> ok count - 44
> ok count - 40
> ok count - 44
> ok count - 0
>
> RawImageGetRow -
> ok count - 126
> ok count - 2
> Clamping count before - 3
> after - 0
>
> RawImageGetRow -
> ok count - 126
> ok count - 2
> Clamping count before - 3
> after - 0
>
> Now the size of the image is 128x128x4(rgba) and its run length
> encoded by why should there rows with extra pixels that run over the
> end of the line? Not all lines are broken though, many add up to 128
> just fine.
It would be interresting to see if lines beyond that line in question are
shifted by some amount?
I cannot see any problem with Flightgear but may be a 3 pixel shift in a huge
texture is invisible for the first cut.
Note that the 'after' printout is allways zero, may be we need to switch to
the next line not only at a zero length but also if the line end is just
reached?
> I have run other .rgb files that I have with run length encoding and
> they are fine, and always have a 0 at the end, which is what the OSG
> reader looks for.
>
> It looks to me like the file is not created in a proper form and other
> loaders are more easy going with it, checking for length of line.
That was my impression too.
> The code should possibly be changed to keep reading till the end of
> the line or a zero delimiter. The check should probably be elsewhere
> than you've added though, as if we are trying to catch dodgy files the
> file should really stop at the last byte in the row.
Ok. If you have an other fix for that. I would like to test that on our rgb
files.
When I tested the loaders with the Flightgear models I run a script doing a
osgconv to ive on any 3d model I could find in the data directiory. Just to
see that that it does not crash. If I remember well, this osgconv crashed on
about 20% of the 3d models due to crashes in the rgb loader. So there are
plenty of them out there.
Past that change in my private tree the models are converted without crash.
Not sure if they are also correct ...
> > > It'd also be interesting to load and save the problem RGB's via
> > > ImageMagic/gimp and then see if the OSG copes fine with the newly
> > > saved version.
> >
> > That works.
> > If I do a
> > convert sun.rgba SGI:othersun.rgba
> > the loader does not bail out.
> > Note that the resulting file is longer than the original one.
>
> This is another sign that perhaps the file is 100% ok.
>
> The question is what to do about it. Do you know the history of this
> file? Is there some export tool that is being used that is creating
> doggy .rgbs?
No I do not yet know the history.
Currently asking the one who checked that in where it originates. From the
checkin comment this is from a third person ... So finding out that may take
some time.
What I can say from the checkin log is that it is a relatively new checkin. So
it cannot originate from an 'too old' tool.
Well, I would like to have a rgb loader that does not bail out on files that
are displayed well with other tools. How this is achieved does not matter ...
Can you contact the one who wrote that loader? May be he knows what to do?
Greetings
Mathias
--
Dr. Mathias Fröhlich, science + computing ag, Software Solutions
Hagellocher Weg 71-75, D-72070 Tuebingen, Germany
Phone: +49 7071 9457-268, Fax: +49 7071 9457-511
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
