HI Mathias,
On 11/6/06, Mathias Froehlich <[EMAIL PROTECTED]>
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.
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.
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.
> 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?
Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
