visit
visit copied to clipboard
visit-dav
We're using "invert" incorrectly wrt color tables
Describe the bug
In VisIt, we have the ability to invert a color table. In VisIt, that means we reverse the orders of the colors in the table. I think a better name is reverse or maybe inverse.
I asked ChatGTP what "inverting" a color table means...
In the context of image processing or computer graphics, "inverting" a color table typically refers to the process of transforming each color in the table to its complementary color. The complementary color is found by subtracting each of the red, green, and blue components from the maximum value for each component.
For example, if you have an RGB color represented as (R, G, B), the inverted color would be (255 - R, 255 - G, 255 - B), where 255 is the maximum value for each color channel in an 8-bit per channel RGB color space.
This process results in a color transformation where light areas become dark, and vice versa. For instance, white becomes black, and black becomes white. All other colors are also inverted accordingly. This can be a useful technique for various purposes, such as creating negative images or achieving specific visual effects.
Keep in mind that the exact implementation may vary depending on the software or programming language you are using.
That is NOT what we are doing except when the table is just a gray scale. In that specific instance reversing the order of colors in the table is an inversion.
I think we should fix this naming or, better yet, do the actual correct thing and invert the colors.
If we implement this definition of 'invert', we should keep the current scheme with an appropriate name. I like the current version of 'inverting', eg turning it upside down.
It would also make me happy if inverting or reversing a color table (or both) options were intrinsic to the color table. Maybe that's not the best idea but we can discuss.
If we implement this definition of 'invert', we should keep the current scheme with an appropriate name. I like the current version of 'inverting', eg turning it upside down.
To be clear, in color science, the word "inversion" means to select the complimentary color. IDL, matplotlib, matlab use "reverse" or "flip" for what we do. There is no new definition of "invert" being proposed here. The proposal is to correct our terminology.
My claim is we are using this terminology incorrectly and inconsistently with other standard tools.
We can keep what we do but we should call it "reverse" or "fip".
We can add true color inversion but if we do, we should call it "invert" and stop calling what we are doing "invert".
It would also make me happy if inverting or reversing a color table (or both) options were intrinsic to the color table. Maybe that's not the best idea but we can discuss.
In matplotlib, all tables have a _r variant for the reversed table. That doubles our tables. With tags, we could simply add a reversed.
Our current invert knob is a modification of a table at the time the table is applied/used.
But, then can't the 10, 25, 50 and 100 color control point variants of many of the crameri tables I added be considered a modification of a table too instead of having to have multiple variants of those actually instanced in our list of tables? This reminds me a little of fonts. In many cases, bold, italic, strikeout, etc are treated as different instances isntead of just modifications of base font. TrueType fonts were an attempt to get away from having to instance all the variants.
I think the whole original idea of color control points was similar to TrueType fonts...to instance only the base descriptions and then allow for all sorts of variations at the time the color table is actually used. This could include number of discrete colors, inverting (reversing), lightening or darkening, discrete vs. continuous treatment, etc. This would have the effect of minimizing the number of tables we actually instance and expanding how any table is applied to any given plot. I think it is conceptually simpler for users but probably harder to implement.
I was thinking instead that, for a given color table, there could be a reverse button in the color table manager, which would produce a color table where all the control points have been reversed. Then we don't need to provide options anywhere for reversing tables, since it would be trivial to create a new table that is reversed if you so desire.
I was thinking instead that, for a given color table, there could be a reverse button in the color table manager, which would produce a color table where all the control points have been reversed. Then we don't need to provide options anywhere for reversing tables, since it would be trivial to create a new table that is reversed if you so desire.
Sure. I get that. I was thinking the polar opposite of that approach. Why? No particular or defensible reason other than to observe that if we view a color table as sort of scheme or pallete, the role of the manager is to manage different schemes or pallets whereas when those are actually applied, we may have additional knobs that have nothing to do with the scheme or pallet and instead have to do with how we interpret that pallet for a given plot or visualization goal. Maybe we choose to reverse the pallet or to invert it, or to lighten or darken it, or to discretize it to just N colors, etc. All of those are modifications of a given pallet and are relevant when the pallet is applied, not when the pallet is created/defined.