It would be nice to have a color wheel in there as well. Unfortunatey, it appears that the GTK+ widget for the color wheel (GtkHSV) is not made available in GTKmm, making that more difficult to achieve. I hope there is someone with experience in wrapping GTK+ widgets…
I have no real knowledge of GTK+ (or gtkmm) at all. So I just clicked through gtkmm’s documentation and found Gtk::ColorSelectionDialog. Why aren’t we simply using that one? Does it lack anything we need?
Well, that dialog and the underlying widget (Gtk::ColorSelection) don’t have our horizontal, colored selections bars (for RGB and LHSUV). With a color wheel, however, we might decide that these bars are no longer useful enough to keep… (Assuming that Gtk::ColorSelection provides us the necessary signals to dynamically update colors.)
Yes, you’re quite right. I thought about this a bit later, and didn’t come around to check it. This is a BUG in the current code.
The “caret” should also stick out, i.e. be dark on a light background and be light on a dark background. That’s another…
Yeah, well there are couple of things we might do. I guess the first thing is to determine what people would like.
We currently have RGB and combined HSL (or is it HSV?) and YUV. We could add a color circle (like in the Gtk+’s color selection dialog), a color rectangle, or CMYK. We could even move the color palette in there. I also don’t see to point of YUV, so we could also drop that…
I’m just wondering what the other guys are thinking… Genete, Pixelgeek, Pabs, …, any thoughts?
Yes. And no. When you’re converting between color spaces it can very well happen that a valid combination of channel values in one color space results in an invalid combination of channel values in a different one. Of course that does not really make sense as the underlying medium can not display those values.
I say, drop support for two-dimensional color selection entirely. It will always suck. Instead, require 3D glasses and show the people a color cube that they can manipulate using data entry gloves.
Other than that I’d recommend using the GTK+ color selection dialog. It works and it’s a standard dialog so people will know how to use it immediately.
My memory vaguely tells me negative colour and high colour are mathematically useful, especially when rendering to HDRI formats. Unfortunately I don’t remember the details, you’d have to check the forum, mail, irc, patch and tracker archives.
I can imagine this extended values range to be usefull for the color and light computations. It’s not obvious to me why this would also apply to the color selection, which only provides the inputs for these computations. Particlularly since the values are defined to be bounded (e.g., the hue goes from 0 to 360 degrees).
I have managed to show GTK’s color selection dialog yesterday. I only need to fix some event/signal management and some general bug testing (which will probably both take a while, I’m currently quite busy with moving) and then we’d be good to go on this front.
If my opinion counts, I think it’s a bug. I’ve discussed it in the past with Genete, and using values outside 0-100 causes studio playfield and final rendering show different colours in the render. And I think that Bombe or Zelgadis said that any undefined behavior is indeed a bug, and I have to agree . The core treats values below 0 and above 255 (after conversion) as 0 and 255, respectively.
I think that for “lightning calculation” on HDR it’s not needed to use colour below range, because when doing the operations with normal colors (in floating point) needed values appear, but I’m not sure about that. If you want more info, I think you can just check the NVidia paper about HDR, it’s very good (simple) although it’s for 3D, the principles are the same.
One thing is that colors reflected in studio are not the same than the rendered output and other is that you cannot use values outside the [0,100] range.
For me a color with one of its channels outside of [0,100] means that have different behavior when applied a determined blend method. The problem is that if it is used a RGB color as output it must be clamped to [0,100] (ie. 0- 255) to be a real RGB color. But what about if there is other color representation that allows any value in each channel?
For example, alpha> 100 is very meaningful to me because it changes the result of the antialiasing or the feather in a funny way. So I don’t only think in the final color representation but the blend method used to combine objects (colors).