RE: [rp-ml] Colour STL files?

From: Deelip Menezes <>
Date: Thu Nov 23 2006 - 19:02:27 EET

Sounds familiar. The same thing has happenned to the IGES file format. If
you are interested see my blog at The article is "Should
Autodesk keep the DWG format a secret?"


-----Original Message-----
From: [] On Behalf
Of steve
Sent: Thursday, November 23, 2006 8:16 PM
To: Rapid Prototyping Mailing List (
Subject: RE: [rp-ml] Colour STL files?

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.
Received on Thu Nov 23 17:54:55 2006

This archive was generated by hypermail 2.1.8 : Tue Jul 21 2009 - 10:27:52 EEST