I created a couple of patches, mostly for UI stuff, back in 2006. I finally found the time to merge them to the current version and have created patches for them in the SF patch tracker.
And due to browser silliness I’ve created the last patch twice. Looks like sf’s tracker could use some improvement.
Also, I would have loved to log in to sf before submitting the patches but it seems that I forgot my password and sf only has a very out-of-date email address of mine. Damn.
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.)
a) Gtk::ColorSelection lets you access a Gdk::Color object which stores its color channels in 16-bit values and can return doubles, if necessary.
b) Dividing by 255 (or 65535) is not black magic.
I looked at your color dialog patch, and I noticed the following:
The RGB spin buttons allow you to go over 100 or below 0.
The YUV spin buttons don’t seem to do anything.
I seem to able to move the carets (these triangles in the bars) outside of their bars.
So, apart from a discussion about whether we like the color dialog like this (it seem a bit crowed, all these colored bars). A few things need to be fixed as well.
I do agree that the current color dialog needs change…
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.
We’ve had this discussion before IIRC. I thought the < 0 and > 100 thing was a feature, not a bug. I agree that when that happens the triangles should indicate that rather than disappearing.
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).
So, after an interesting read on Wikipedia on everything about light and color (certainly worthwhile), I ended up at techmind.org/colour/
If I understand everything correctly, it does actually make sense to have negative or a values of more than 100%. Eventhough there are definitely not (directly) representable…
I’m not sure what we should do about it in Synfig, 'though…
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).
-G
I hope there is someone with experience in wrapping GTK+ widgets…
. The core treats values below 0 and above 255 (after conversion) as 0 and 255, respectively.