RE: [rp-ml] Colour STL files?

Well, before you fall off your high horse:-

- Hindsight is a wonderful thing.
- The world is full of stupid standards (does anyone really think
DVDs are any good?), those that prevail are those that get used most
- not those that are most sensible
- Aside from the detailed description regarding the misinterpretation
of the stl format (very interesting by the way - I wasn't aware there
was that much thought put into it), you're not telling us anything
the majority of us don't already know. I recall a debate over 10
years back lambasting the stl 'standard' from the perspective of
direct slicing.
- Maybe 'modified' or 'misinterpreted' are better words than
'abused'. As far as I know you are correct, the process was along the
lines of your discussion that someone thought the two bytes were
'spare', with no obvious intended use.
- Incidentally, isn't colour an attribute?
- My recollection on the colour coding of stl (and I could be wrong
here) is that one was developed by a lab in Japan, whilst the other
came from a lab in Europe (Holland, I think). Note that both of these
hailed from labs, where people are generally more interested in what
they, themselves are doing rather than adhering to software standards.
- stl is described as a defacto standard for a reason. I know, it's
horrible, but since it will only take 2 minutes of your time why
don't you jot something down on the back of an envelope and see if it
will still be used in 20 years time?
- Why don't you also have a go at those who defined two colour
standards (RGB and BGR) as well? Where did RGB come from anyway? At
least BGR is alphabetically correct.

Anyway, colour stl is fundamentally flawed because the triangles are
supposed to represent geometry, not colour. So other than it being an
interesting 'oddity', why should people spend so much effort in
defining it as a standard? As far as I know it was just there to show
people that it could be done.

IG

At 22:45 23/11/2006, you wrote:
>Several people leaped to my aid with information about colour STL
>file variations - and the Wikipedia article entitled "STL (file format)" now
>includes all of that information.
>
>Thanks to the MANY people who sent me this information.
>
>Sadly, the two variations on colour STL are horribly incompatible
>because one company put the colours in the order R, G, B
>and the other in B, G, R.
>
>There can be no technical justification for doing that. This
>kind of thing just shouldn't happen.
>
>Even software and machine vendors who are competitors should have
>a responsible attitude to the community and design data formats
>that are inter-operable. Especially as (in this case) it would
>have been quite utterly trivial for the two companies to have
>been compatible on this score.
>
>Both variations abuse the original binary STL "standard".
>
>In the standard there are two bytes at the end of each triangle's
>description that are supposed to indicate the number of ADDITIONAL
>bytes of 'attribute' data included after the vertices. This number
>is generally zero because there are no attributes defined yet.
>
>So, theoretically, if you wanted (say) a three byte Red/Green/Blue
>colour per facet, you'd have set the the two attribute length bytes
>to say '3' and tacked on three extra bytes for each facet. That way,
>a correctly written existing STL parser (that doesn't expect colour)
>might be expected to skip those three bytes.
>
>However, both variations abuse that mechanism by using the two attribute
>length bytes to directly store the colour. It is clear that the reason
>for this is that both vendors believed that those two bytes were
>'padding' to round out the binary data size to 50 bytes (although
>why the heck anyone who works with computers would think 50 was a
>more 'round' number than 48 is a complete mystery - especially because
>those two extra bytes mis-align the 'float' data records which makes
>programming the reader harder, not easier). Ignoring the
>many versions of the binary STL specification out there (which
>clearly states the true purpose of those two bytes) - clearly someone
>assumed they were spare and could be used to store the colour directly.
>
>Hence, both variations of the format use the most significant bit
>of those 16 bits as a flag that indicates whether this facet has
>a colour or not, then they pack the three colour components into
>the remaining 15 bits as three five bit numbers.
>
>OK - well, I guess that works...but, oh - wait...
>
>Unfortunately (if my information is correct - and I have multiple
>sources that agree on this point), one format stores the colour
>components in the order Red/Green/Blue and the other in the
>order Blue/Green/Red!
>
>This means that not only is it impossible to write a loader that
>correctly figures out which varient of the STL format you've got - but
>if you guess incorrectly, your colours look exceedingly weird!
>
>Neither version is reverse-compatible with a correctly written loader
>for the original binary STL format.
>
>Aaaaarrrggggghhhhh!!!!!! Stupid, stupid, stupid!
>
>The STL format really is a piece of junk - that this could have
>become the de-facto standard across the entire industry is horrifying.
>
>We could have come up with a vastly better standard in about 2 minutes
>flat and fitted the description on the back of an envelope.
>

Dr. Ian Gibson
Associate Prof.
Dept. Mechanical Engineering
National University of Singapore

tel: +65 9277 7343
Received on Fri Nov 24 03:24:39 2006