Corrected AciColor color table:

[vsheveliov]

AciColor color table is incorrect. The same is with results of RgbToAci function (even with correct ACI table).

• indexRgb ACI dictionary replaced with function LookUpRgb, where most RGB values are calculated;
• for backward compatibility with added IReadOnlyDictionary AciColor.ColorDictionary for property AciColor.IndexRgb
• private RgbToAci function replaced LookUpAci function with results fully equals to Autocad functionality.

[haplokuon]

After a long hiatus, for personal reasons, I've able to take a look at your code. It seems that you know better than me how AutoCad actually builds its ACI color index to RGB values, and perhaps you can solve a problem with this issue. All the information I've found was just tables obtained directly from AutoCad.

The color equivalents changes depending on the background view color, but I still do not know how. The color table that your code builds is correct for Black (or very dark) background colors, but the AutoCad default color scheme is different, it uses RGB (33,40,48) and it changes the color table. The background color is not saved with the DXF so I've been using the one, besides a couple of errors here and there, found in the code.

Perhaps you know how the background color influences the ACI index to RGB conversion, and this way we can let the user decide how to make it.

In my opinion the ACI color index 0 should be left out of the final color table. It is not a color it is a reserved index as the 256, that depends on the color of the block.

[vsheveliov]

I tested my code against Autocad NET API and it seems match Autocad results. Autocad as very old leagacy software, and color table/palette is an example of such development. First 8 colors are rather random derivied from first Autocad releases. Remaining palette was added to later releases of Autocad and have some systematization in accordance with HSV. So it can be calculated on the fly.

Autocad stores color in 32-bit integer (MRGB - method, red, green, blue). First byte is color method (by layer, by color, by ACI, by RGB and some other "methods" such as layer frozen, etc). Remaining bytes - are RGB values. So I think having color as class in your code a little bit overkill. May be it should be struct? And get rid of Clone function. Unless you plan to support color books later (it will requre some string storage).

Good sample code comes from old Autocad R14 distribution - sample file COLEXT.CPP. Still can be found in internet. Another good try (with some bugs) is here in github.

[haplokuon]

While using true colors in AutoCad I can get consistent results when exporting to PDF or to BMP, when using indexed colors it is impossible. Just an example, for indexed color 99, in the AutoCad color picker dialog box it shows RGB(38,76,38) when the background is black, but when it is white it shows RGB(19,38,19). Now when exporting to a PDF it always shows as RGB(57,114,57), and for BMP it is the same as the AutoCad interface. Therefore it doesn't matter which are the internal RGB values, in AutoCad, for a given index if it doesn't correlate with you can see on screen and what the interface shows.

It doesn't matter how it decides to store it as three bytes, three floating point numbers in the range [0,1], or as a 32-bit integer value as it is in the DXF code 420 when writing true colors; different applications have different needs. The conversion between an index and its RGB equivalent is what gives me a headache, since I was unable to get consistent results, as explained in the previous paragraph. The DXF do not store the RGB values for indexed colors, so a color palette must be created, your code generates a color palette that corresponds to a black background and it seems to be the most consistent among other software. My question was if you knew how AutoCad generates those colors palettes for different backgrounds, since you knew the math behind the one with the black background.

I can understand that it needs to brighten or darken a base color when only working with 255 different colors. This comes from a time when displays were a lot more limited. At that time, I, almost, only used two colors for the plans, white and gray over a black background. Two indexes for two plotter pens one thick and one thin; and in rare cases a brown color. This was before the advent of injection printers when plans were not printed but plotted, a color index was a pen in the plotter. And now, I am deviating from the problem at hand, this is getting a little personal.

At the end, assigning RGB values to an index is an arbitrary decision, so perhaps I will include both color palettes, the two that, at least, I know AutoCad uses. And, maybe, open the option to assign a custom one. I don't know, I will need to think about it.

One more thing, about the decision of using a class or a struct, I favor the use of classes over structs, except, when dealing with mathematical quantities like vectors, matrices, quaternions, imaginary numbers,... that I always use structs. Java and Python, for example, do not use structs.