Subject:
|
Re: LDraw.org Config File (was: Edge line colors on img.lugnet.com)
|
Newsgroups:
|
lugnet.cad.dev.org.ldraw
|
Date:
|
Tue, 29 Jul 2003 15:21:41 GMT
|
Viewed:
|
1404 times
|
| |
|
|
In lugnet.cad, Steve Bliss wrote:
> [XPFUT lugnet.cad.dev.org.ldraw]
>
> In lugnet.cad, Andrew Westrate wrote:
> > I've been thinking about this a little bit, and I'd like to propose a
> > solution. I think that with the next parts update, we should include
> > a "colors.lst" file.
...
> My suggestion for the file name is ldconfig.ldr. This seems to identify the
> file adequately. I happened to have a fairly extensive colors file lying
> around. I cleaned it up, and here it is.
...
I'm working on a Track Designer-like program; I'll be presenting it at
BrickFest. My program, TrackDraw, can read and write LDraw files -- I've also
created a color definition file (in XML) that is very much like Steve's -- so
I've been thinking a lot about this problem, too.
My comments:
- While dithering is not hard to implement, it appears to serve no purpose here.
All of the colors are the same in the last two groupings for all values of RGB.
The ones that appear different (the 'trans' colors) could be the same with no
loss, since the alpha is specified as zero, so the RGB values are irrelevant.
There's a more important reason to lose dithering: it is a display artifact, and
cannot necessarily describe a color well. This is because the dithered colors
need to lie equi-distant from the color on vectors pointing in opposite
directions. Taking gamma into consideration, the distance is neither linear nor
uniform. LDraw did it because on CGA it had to. Keeping it because it isn't hard
to implement ignores how color works. It's easy for a program to construct the
dithered values from a single value; it isn't easy to do the reverse accurately.
- The numerical values are a mixture of hexadecimal and decimal. For the colors,
I'd prefer to see 0xARGB to decimal R,G,B,A. 0xARGB is a standard used by HTML,
CSS, SVG and many others. The file already requires reading hexadecimal 32 bit
values, and is no more difficult to read by humans than R,G,B,A (and I find it
easier to read).
- The names are not consistant. The same way that LDraw parts have complete,
formal names, the colors should too. These names should not have abbreviations
and should be quoted to allow for spaces. So instead of "DkBlue" the name should
be "Dark Blue", and so on. I could see having a short name form in addition to a
formal name, although regular parts don't have short forms.
If you reject this idea, please consider making the abbreviations consistant.
Note only one color uses "Tran" instead of "Trans"; only one color uses a dash
in the name, etc.
- I couldn't figure out what the fifth column is for (e.g. 0x4601601).
- The table only includes flat colors: even if the RGB values are unchanged, it
would be great to include chrome, silver, etc. for the applications that can
render reflectance. Similarly, GlowDark should have a luminosity value.
- The most complete color reference I know of his here:
http://www.bricklink.com/catalogColors.asp
It currently contains 79 colors, with a reasonable choice of names. It would be
great to standardize the names -- I'd like to see good rationale when a
different name choice is chosen. In particular, I think it is a stretch to call
the color only available as a 1x1 plate as "LtGray".
- Black is 33,33,33? Why not 0,0,0? If it needs to be less black for printing,
that should be a print-driver concern. Is there any evidence that Black is
really dark gray but not truely black? See:
http://www.peeron.com/inv/colors
- LtPurple is the only color I see that has slightly different values in the two
dither color columns. Is that deliberate? Why?
Cary
|
|
Message has 2 Replies:
Message is in Reply To:
18 Messages in This Thread:
  
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
