NON CRITICAL - Colorspace conversion locked at window launch; no device colors
By [email protected] on April 14, 2011 07:08 (imported from Google Code)
At first I thought this was a bug. I now consider it less critical since I figured out what was happening, but I'd still suggest a possible change in future.
I spent a lot of time testing in iTerm2 and Terminal on OS X when developing Solarized and made the mistake of using the same testing procedure for each. This resulted in my assumption that iTerm2 color management wasn't working at all. It is in fact working pretty well, but I wanted to outline how it differs from Terminal/Safari.
Issue #1 (closed): Dropping a color swatch from colorpicker to iTerm2 converts it to Generic colorspace regardless of whether it was tagged or an untagged "device" color. Terminal preserves the Device color value, which seems preferable.
Issue #2 (closed): When opening iTerm2 the conversion from Generic colorspace to the display's current colorspace is locked in. If the colorspace is changed while a window is open the colors displayed in iTerm2 will still be locked to the space at the time the window was opened. (For what it's worth, Chrome displays similar behavior which is much more frustrating given image display is a core function.)
Both of these are decidedly non-critical but I really went nuts till I figured out exactly what was happening. I doubt many hardcore CLI junkies are going to be switching up colorspaces and testing color values, but if you happen to be replumbing the color system in iTerm2, it might be worth looking at.