Subject:
|
Re: LDraw.org Config File (was: Edge line colors on img.lugnet.com)
|
Newsgroups:
|
lugnet.cad.dev.org.ldraw
|
Date:
|
Wed, 30 Jul 2003 04:06:20 GMT
|
Viewed:
|
1332 times
|
| |
|
|
In lugnet.cad.dev.org.ldraw, Cary Clark wrote:
> - 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.
As you pointed out, dithering is a historical artifact with LDraw. As I
don't see it doing any harm, I'd rather leave it in for now, even if it
is generally unused. Call me misguidedly sentimental. ;)
> - 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).
As to the order and format, I was sticking with the LDLite definition of
the statement. I think you are correct about 0xARGB.
As for the decimal, I was being pragmatic -- by skipping the required 0x
prefix for the 8 RGBA parameters, each line ended up being slightly
shorter.
> - 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.
Formal (or 'official') would be good, I think -- whether the names are
short or long. Long names are good, as long as they serve a purpose.
If we think programs will use the information from these color
definitions to display information for users (like on a color dialog),
then I'm all for long names.
Otherwise, considering that LDLite allows these color names to be used
in place of color codes, I don't think allowing spaces is going to be
likely.
> 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.
Good points.
> - I couldn't figure out what the fifth column is for (e.g. 0x4601601).
The fifth column is the edge color. The hex values are LDLite direct
colors. LDLite direct colors use a 12-bit RGB color space; the leading
hex digit in the value specifies something (solid/trans?), the trailing
6 hex digits are two pairs of RGB values. I don't really expect LDLite
direct colors to survive as an official standard -- what's the benefit
over straight (A)RGB?
> - 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.
(Sorry, I accidently left ShinySilver and ShinyGold out of the file)
Good points.
Unfortunately, including chromes could possibly confuse/frustrate
people, since they wouldn't actually 'work' in most LDraw-compatible
programs. But the advantage you describe may outweigh the drawback.
> - 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.
(Where is the print going to get its colors from?)
> - LtPurple is the only color I see that has slightly different values in the two
> dither color columns. Is that deliberate? Why?
Sorry, that was an error.
Steve
|
|
Message is in Reply To:
18 Messages in This Thread:
  
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
