CEGUIColourPicker

[Ident]

I would like to implement a colour picker as a CEGUI window type, with fully integrated colour picker functionality, for the CEGUI library. I think this is very useful to have in a library like this.

It should work similar like the typical colour pickers in most image-processing and editing tools (Like Adobe Photoshop), thus in a very "professional" way and using a variency of typical and for different purposes useful colour spaces.

I would imagine the functionality like this:
The CEGUIColourPicker provides in its initial form just a window displaying the currently picked colour - so basically it would be just a staticframe with a coloured quad on its inside. This way you can choose to have multiple windows if you need to have 2 ColourPickers, each saving seperate colours, and align them as you want using common CEGUI functionality, e.g. a Listbox containing numerious colourpicker windows.

If clicking the colour picker window, a window will open displaying a colour map for picking a colour using a coursor and a pointer set to the currently picked colour on the map.
It should offer 3 different map types: RGB (not sRGB), and the colour spaces CIE L*a*b in D65, and HSV

The feature set would be similar to that of the Photoshop colour picker, but Lab and HSV(or similar) are very important colour spaces in the professional environment and there is not really another or a "better" option for those kinds, so i would propose those. The Lab colour picker ( as i have currently implemented in OpenGL) is not really an intuitive picker just by itself if you want a specific colour, HSV is quite intuitive and still as "accurate", but they are both constructed for different purposes and just as useful for their relative purpose.

The colour picker map would be in 2D, each axis for an attributes of a colour space, the 3rd attribute ("depth") is being set in form of a slider. Also the colour picker would provide fields to display and manually set the values for the different colour spaces / RGB directly, and each change on the map/slider/textfield updates the others immediately and as correctly as possible.

For the colour map, like I said, I want to have RGB and CIE L*a*b* and also a third colour space to pick colours from. I don't know which one is best, options would be HSB(adobe photoshop), HSL (gimp), HSV, which are all closely related.
On this matter - A nice collection of different colour pickers (HSL/HSV):

http://upload.wikimedia.org/wikipedia/en/e/ea/Hsl-hsv-colorpickers.svg
I like the one in a), because of the pseudo 3dimensionality


Here the gimp one



Another option would be the following colour space as a picker, which does not seem to be often used for colour pickers - I haven't found a screenshot of such a colour picker:




HSB on a mac:



And the photoshop one which gets closest to what i want to make, for all those who live in some sort of time capsule in an a thermo- and air-isolated cave on the dark side of the moon and have never seen Adobe Photoshop before:



My final idea on this would be to replace RGB colour picking (which is kinda useless in my opinion) and implement HSB(or similar), CIELab and CIELuv (wanna know how this one looks ).

Making this whole colour pciker thingy not really difficult per se, but still kinda complex because of the colour space algorithms and conversions and the many GUI elements that interact and need to be updated. Also the colour map has to be created on the fly - otherwise I would have to store 24*mapwidth*mapheight*mapdepth bytes for each colour space in memory, which would be some megabytes of data (!). I guess this is not desirable. So i will create it on the fly whenever it changes.

I would make the whole popping up colour picker window in fixed dimensions and fixed layout. I can't think of a situation anyone would need to re-align or re-size it interface specifically for their program, unless it is too big. ( I will try to make it about 400x400).

The design of the colour picker will be very close to that of the one in Adobe Photoshop because it is pretty extensive, professional and good to use. Also there is not really many ways to implement this anyways. So if you can think of anything you do not like or would want to have additionally to that one, you are welcome to post them here.

Any special feature ideas, wishes, suggestions, ideas improvement are welcome and should also be posted here. DO IT!

[Mikademus]

Hi!

I think this is a very nice idea! Given that I often write tools and I often find I'd like to have a colour picker but can't take the time to make one I for one would certainly find good use for it. I would assume that colour picking in itself would be a matter of gaining access to the render context and querying for the colour under the cursor position?

Out of personal experience it is my perception that most people find the Photoshop-styled RGB picker the easiest to understand and use, and though RGB isn't very useful in production of prints, RGB is what all games use.

Great initiative!

[Ident]

Hi!

I think this is a very nice idea! Given that I often write tools and I often find I'd like to have a colour picker but can't take the time to make one I for one would certainly find good use for it. I would assume that colour picking in itself would be a matter of gaining access to the render context and querying for the colour under the cursor position?

Out of personal experience it is my perception that most people find the Photoshop-styled RGB picker the easiest to understand and use, and though RGB isn't very useful in production of prints, RGB is what all games use.

Great initiative!

Thanks for your posts.

I did not plan to query the render context but just access my colourmap data array which I would use for creating the texture to render. I see no benefit in accessing something on the GPU that i have locally accessible 1:1. But maybe i misunderstood the concept with which you would make the colourmap - or wanna access the data - could you explain?

RGB is the outcome of any of those colour pickers i suggested. Everything that is displayed on the screen is just the RGB values that were computed. The difference between the colour spaces for use in a colour picker is just the way those colours are aligned. I will not calculate the data to CMYK (which is really only needed for print etc.). By RGB picker in PS do you really mean the RGB picker and not the HSB picker which is default in photoshop when you open the color picker? The HSB one is very intuitive to me, especially in the H-Setting, but I find the raw RGB one kind of useless. I think it is more intuitive to first select a colour and then adjust the lightness, luminosity, or similar, which is how all other colour picker types (not the RGB one) work. Please check if you really meant RGB. Else I will reconsider also implementing that one - it is by far the simplest one anyways.

[Mikademus]

Well, "colour picking" also often means that you can sample a colour from anywhere on the screen, and it is common that you can do so when a colour picker widget is active. So musing about how to accomplish that was my train of thought in my message above.

And yeah, you're right, the default PS colour picker is indeed a HSB picker and works very well and is what I meant.

[Ident]

Great, thanks for confirming that. So i will leave the RGB one out.


Yes the term "colour picking" is confusing, as well as "colour map" is a confusing term because that could also mean there is a set of 50 pre-defined colours to choose from, for example. And no I didnt mean to sample colours from the screen. Although that would be a possibility, too. At least in OpenGL it doesn't seem difficult to do this, of course only for the current OpenGL context so anyone using multi-context has bad luck. But first, ofc, the colour picker.

[Kulik]

I like the a) picker as well. The question is how are you going to draw the colour area. Putting just an image there seems wrong because resizing it would make the image pixelised. And AFAIK you can't draw it via just fixed function calls from OpenGL/DX. Let us know what rendering features you will need so we can incorporate them into 0.8.

[Ident]

I like the a) picker as well. The question is how are you going to draw the colour area. Putting just an image there seems wrong because resizing it would make the image pixelised. And AFAIK you can't draw it via just fixed function calls from OpenGL/DX. Let us know what rendering features you will need so we can incorporate them into 0.8.

An image? Dude, you got a scrollbar to specify the 3rd variable, you would need a pre-generated 3D texture of some size (too much size)...it is not a static 2D-image, it changes.

Why can't i draw it with fixed function calls?
Take OpenGL - > All i need is to create a texture inside the context via glGenTextures(...), fill the texture with data via glTexImage2D(...) and finally draw the texture on a quad binding the texture and using texture coordinates for each vertex. At which point during this procedure do I need shaders? I can even do this with shitty glBegin() glEnd() way of drawing (ugly). I've already implemented all this in an application, not using shaders. I don't know how it works in directx, but I guess not very different.

So basically all the features i need are the functions listed above and being able to draw a texture on a quad or on 2 triangles, with the same outcome. So it's not any different from what CEGUI already does when drawing images.

If i misunderstood you on this, clear me up, be more specific.

[Kulik]

Yeah you can't put an image there, pardon my naive self

The best solution would be to use CEGUI's facilities to draw it. If you use OpenGL, your colour picker is not usable in Ogre, Irrlicht and DX. That's why I want to know how you are going to draw it to make sure 0.8 can make it happen.

[Mikademus]

This might have been said already, but basically, as I understand it, the facilities that would be needed are simple (1) getting access to the texture that is the surface of the window and (2) the ability to read and write a specific pixel from that texture. The colour picker is basically a matter of algorithmically generating a colour gradient on a rectangle, so the rendering of it is not magical.

[Kulik]

You already can "blit" pixel data to/from a texture so it should be possible as it is then. I was thinking about speeding it up a bit but I guess that isn't necessary and would require shaders anyways so it wouldn't be portable.

[Ident]

If you use OpenGL, your colour picker is not usable in Ogre, Irrlicht and DX

This is how to fill a Ogre Texture with manual data : http://www.ogre3d.org/docs/manual/manual_65.html#SEC297
One page back is how you create it. Doesn't blow me away. Looks very much like in OpenGL basically. And DX won't be much different.

So what else do I need that the CEGUI widgets (StaticImage) aren't already using? It is really, like Mikademus, only the possibility to manually create and fill a texture with data, that i need to do. The rest i can copy-paste from the CEGUI widgets so the created widget will render the same way how rendering is usually handled by CEGUI.

Directx can definitely do the same as OpenGL and Ogre on that matter, I ll only have to look up how exactly they do it but I guess it won't be killer difficult and I won't die trying it. And about Irrlicht I don't know, but it is an engine so it should be easier to get it to work there than in pure OpenGL, for example. I ll figure when i m done with the other 3 renderers.

You already can "blit" pixel data to/from a texture so it should be possible as it is then.

Explain, I don't understand this sentence. What do you mean by "blit" and where is this happening in CEGUI? Confusion.

Yeah you can't put an image there, pardon my naive self

Well you can. if you are willing to offer 20,280,000 bytes of gpu memory for it, which will still give you slightly inaccurate results ( altho that doesnt really matter for our purpose) compared to calculating it real-time.

@Kulik: But what will be so different about rendering in 0.8? It would be good to know this before starting to implement this, or I will implement it "old style" and it will have to be reworked later.

[Kulik]

Ident: I would like to "clean up" rendering of 0.8 but CE is currently slightly opposed to it. I would like to rework GeometryBuffer (which can render multiple batches) into RenderState and RenderBatch. This way we can implement extensive batching later. My idea is that widgets will queue up render batches when they are told to render.

Blitting is pretty much copying texture data. In this case RAM held data into GPU texture. CEGUI can already do that so I strongly suggest that you use it's facilities for it instead of doing a separate implementation for Irrlicht, Ogre, DX, GL, etc...

[Ident]

Blitting is pretty much copying texture data. In this case RAM held data into GPU texture. CEGUI can already do that so I strongly suggest that you use it's facilities for it instead of doing a separate implementation for Irrlicht, Ogre, DX, GL, etc...

Yes that is what i was talking about. I didn't know it was called "blitting". Of course I will use the facilities of CEGUI if they exist already - could you please tell me what classes/functions it consists of or what files I got to look at? I need names. GIVE ME THE NAMES KULIK.

Once we got this assured I will start implementing the following days.

[Mikademus]

I was looking around to try to find you some good pointers, but actually I came up empty. The Texture class contains no methods for pixel sampling, much less bitmap blitting, the Renderer interface too lacks this. I simply have no idea of how to access bits on a pixel surface controlled by CEGUI.

Kulik, since you seem to be watching this thread, I thought that we had these kind of rather basic facilities in CEGUI, but your original hunch seems right and we might have to implement some kind of pixel access. Hopefully I am wrong and I just didn't find it, then it might perhaps just be a question of making it more obvious.

The Texture class seems like a prime candidate for this of course. SFML uses a getPixel(x,y) const and setPixel(x,y,colour) pair which abstracts implementation but forces overhead on the client. Direct3D uses a lock() method that provides access to the memory bits and leaves handling the colour format to the programmer but is more efficient. I like the latter one since it allows us to access the entire surface at once and can be used to implement sub-rectangle blitting. What's your take on this?

[Kulik]

You can just use Texture::loadFromMemory repeatedly. I think I can implement a blit method with less overhead, both "blit-in" and "blit-out" if there is enough interst in that...