Jump to content
arabellajones

Looking for documentation: "Color under Cursor"

Recommended Posts

I wanted to check what the four numbers are which are shown by the "Color under Cursor" function. The first three are RGB values. and all the third-party sources I can find say the fourth is an Alpha value, but when I made a box, with no transparency, completely opaque, default blank texture, the fourth component was reported as "65".

I can't see that making sense.

Part of the problem I am having is that, while every answer coming up from a Google Search shows the Alpha value answer, nothing comes up from Linden Lab. I've not found anything pointing to the Wiki, or anything else that could be called a reliable source. The LSL code for a color vector uses a float, range 0-1.000, other methods use 0-255 or the hexadecimal equivalent, but is this 1-100 or 0-100 or 0-99 or 1-99?

And then I am looking in the viewer, and the values go weird, apparently inverted. A dark blue has RGB values over 200, pale colours have low values.

Oh, and I checked. It's not behaving like an HSV set.

Since I use Linux, there doesn't seem any point in submitting a JIRA, there isn't any supported viewer, some jobsworth will just close it with a "not our problem, guvnor". But where is the documentation? Have we just been using a piece of buggy code for all these years and nobody has noticed? Have we all been passing around knowledge from the Viewer 1 era, and never noticed?

Share this post


Link to post
Share on other sites
23 hours ago, arabellajones said:

I wanted to check what the four numbers are which are shown by the "Color under Cursor" function. The first three are RGB values. and all the third-party sources I can find say the fourth is an Alpha value, but when I made a box, with no transparency, completely opaque, default blank texture, the fourth component was reported as "65".

The three first digits are indeed RGB values and as Fionalein said, it's the colour with the shaders, so unless it's set to full bright. it's not the colour set by the texture and tint of the objects.

I have no idea what the fourth number is for. It can be anything really. Remember that the functions in the davelop menu are all what the name implies: temporary (or rather intended to be temporary) functions added for Linden developers to check various parameters. There's no documentation and the names don't necessarily make much sense. Those functions were really added by some programmer for his/her own use only and they remembered what the function actually does.

 

23 hours ago, arabellajones said:

The LSL code for a color vector uses a float, range 0-1.000, other methods use 0-255 or the hexadecimal equivalent, but is this 1-100 or 0-100 or 0-99 or 1-99?

It's 0-255. The 0-100 scale is only used in the viewer's builder and (appearance editor) palettes, the 0.000-1.000 scale only for lsl. I think it's a misguided attempt to make things simpler for the user. Everything under the hood operates with 8 bit 0-255 values and everything in the debug menu is about what's going on under the hood.

Edited by ChinRey
  • Like 1

Share this post


Link to post
Share on other sites
3 minutes ago, ChinRey said:

Remember that the functions in the debug menu are all what the name implies: temporary (or rather intended to be temporary) functions added for Linden developers to check various parameters.

So the Firestorm developers decided to make it easily accessible for the users without any documentation....

I am not surprised. The latest version of Firestorm, the animesh beta, is misbehaving on Linux. Other viewers on the same version of Linux are not, and (I had to ask somebody to check it) the Win 10 version of animesh Firestorm is OK..

And JIRA as a bug-reporting tool is about as user-friendly as a rabid honey badger with a hangover.

  • Sad 2

Share this post


Link to post
Share on other sites
1 minute ago, arabellajones said:

So the Firestorm developers decided to make it easily accessible for the users without any documentation....

Not really. They just copied it all from the official viewer.

  • Like 1

Share this post


Link to post
Share on other sites
1 minute ago, ChinRey said:

Not really. They just copied it all from the official viewer.

So the official viewer has a quick preferences window?

I somehow doubt that's in the ancient Linux version they fob us off with.

Share this post


Link to post
Share on other sites
1 hour ago, arabellajones said:

So the official viewer has a quick preferences window?

Firestorm's Quick Preferences is just a selection of shortcuts to functions that already exist somewhere else in the UI.

It's in the debug develop menu in all viewers.

 

Edited by ChinRey
  • Like 1

Share this post


Link to post
Share on other sites

What I am getting from all this is that "Color under Cursor" is an unreliable, undocumented, unmaintained, hack. If I want to find out what colour is used in something, such as for matching a skin tone, I'd do better to take an in-world picture, save it to my hard drive, and check that image.

  • Confused 1

Share this post


Link to post
Share on other sites
12 hours ago, arabellajones said:

The latest version of Firestorm, the animesh beta, is misbehaving on Linux.

How so? It's running fine for me (Ubuntu 18 with Mate Desktop).

  • Thanks 1

Share this post


Link to post
Share on other sites
1 hour ago, arabellajones said:

What I am getting from all this is that "Color under Cursor" is an unreliable, undocumented, unmaintained, hack. If I want to find out what colour is used in something, such as for matching a skin tone, I'd do better to take an in-world picture, save it to my hard drive, and check that image.

I just set everything I want to examine fullbright... mod enabled bodies come in handy when designing stuff to match certain skins.

Edited by Fionalein
  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, arabellajones said:

What I am getting from all this is that "Color under Cursor" is an unreliable, undocumented, unmaintained, hack. If I want to find out what colour is used in something, such as for matching a skin tone, I'd do better to take an in-world picture, save it to my hard drive, and check that image.

It's entirely dependant on the Windlight you are using - so as already mentioned, you can either set it fullbright, or you can use one of the 'standard' colour-matching Windlights.

Nam's Optimal, [NB] Alpine-skinlight RGB, greyskymoon & Ambient Grey are all pretty flat.

All, however, are dependant on your monitor also being accurately calibrated.

  • Like 1

Share this post


Link to post
Share on other sites
15 hours ago, arabellajones said:

What I am getting from all this is that "Color under Cursor" is an unreliable, undocumented, unmaintained, hack.

That's a rather harsh way of putting it.

When you program, you often add some temporary code to test something. For example, if you are working on shaders, you may want to check how they affect the actual color of objects. Usually those test code snippets are removed from the final product but LL at least sometimes keep them. They're already there so no extra work is needed and who knows, maybe somebody else will find a use for it some day.

  • Like 1

Share this post


Link to post
Share on other sites
On 2/15/2019 at 2:00 PM, arabellajones said:

I am not surprised. The latest version of Firestorm, the animesh beta, is misbehaving on Linux. Other viewers on the same version of Linux are not, and (I had to ask somebody to check it) the Win 10 version of animesh Firestorm is OK..

What's happening? I have Firestorm 6.x on Ubuntu 16.04 LTS. It's been behaving pretty well, and I'm using animesh, pathfinding, and doing lots of fast region crossings on vehicles. The only viewer side problem I've been seeing is that the day cycle for EEP regions is out of sync, because Firestorm doesn't understand EEP yet.

  • Thanks 1

Share this post


Link to post
Share on other sites
7 hours ago, ChinRey said:

That's a rather harsh way of putting it.

When you program, you often add some temporary code to test something. For example, if you are working on shaders, you may want to check how they affect the actual color of objects. Usually those test code snippets are removed from the final product but LL at least sometimes keep them. They're already there so no extra work is needed and who knows, maybe somebody else will find a use for it some day.

Sure, it's there for testing, but nobody can point to any documentation. What the numbers even mean isn't clear, the first three are likely RGB, but the fourth? I see lot of different guesses. The alpha? That doesn't make sense, because how an a screen pixel be transparent? Yes, of course it's affected by lighting, but even on flat planes with unvarying textures there can be huge variations between adjacent pixels, with no visual difference. I think that can be fairly called unreliable. And if it was written as temporary code over a decade ago...

I suppose there might be comments in the code. It would be silly if there were not. Has anyone looked? I suppose I could download the source, but that's an alien language to me, which happens to be written in a character set I recognise.

I have tried to find if there is some obscure standard for representing colour with four numbers, which includes RGB. Yes, you do have CMYK in printing, it's a subtractive colour system, and the "K" is black ink. It's used because it is far closer to black than a mix of cyan, magenta, and yellow inks can be.

If some of you guys working on the actual viewer software are using it, and know what the numbers mean, OK. If you don't know what the numbers mean, what do you get out of it?

And if you can't be arsed to document it, why the hell did you put it in that easily-accessible Quick Preferences window for Firestorm?

(Yeah, I am picky about documentation. And I do know programmers who can do it.)

Share this post


Link to post
Share on other sites

     This looks like the right bit of viewer code.

 

  if (debugShowColor && !LLRender::sNsightDebugSupport)
        {
            U8 color[4];
            LLCoordGL coord = gViewerWindow->getCurrentMouse();
            glReadPixels(coord.mX, coord.mY, 1,1,GL_RGBA, GL_UNSIGNED_BYTE, color);
            addText(xpos, ypos, llformat("%d %d %d %d", color[0], color[1], color[2], color[3]));
            ypos += y_inc;
        }

GL_RGBA is Red, Green, Blue, Alpha

Then I read https://www.khronos.org/opengl/wiki/GLAPI/glTexImage2D & my brain exploded  :D

  • Like 1
  • Thanks 2

Share this post


Link to post
Share on other sites

As has been noted. It's a debug tool, it is pretty useless as a means of colour matching.

As it happens, it does exactly what the Firestorm provided documentation says it does. The fact that this is useless for the specific task of colour matching does not make the documentation incorrect.

https://wiki.phoenixviewer.com/fs_quick_preferences

The documentation is available by clicking the '?' on the quick prefs window.

Personally, I would not have added that to quick prefs, I don't know the history of those choices. It should be noted that it is an ancient setting that has become more and more irrelevant over the years as the shading technology has advanced. If you disable ALM you may get a slightly "better" result depending on what you are trying to do.

The code that Whirly posted is the correct code. 

roughly translated it says the following

IF "show colours under cursor debug is enabled" (and we don't have NVidia debugging running) THEN
    get the current cursor position in the screen image (note this a 2D location in the "bit map" you see in your window)
    read the pixel values of the colour at that point on the screen
    show the values as text

So what it is reading is the pixel data on the screen and showing the user the RGB and Alpha values stored by openGL for the pixel currently beneath the cursor. Exactly as it states it does, however, people interpret this as different things. to some extent this relies on the way that we process things in our own minds too, It is a distant relation to the object colour, having been blended, and lit based on the viewing angle, lighting, shadows, alpha etc. yet when we see a white cube in shadows, lit from above, we process that as "oh look there's a white cube over there in the shadows" If we didn't none of this tech would work!

https://www.khronos.org/registry/OpenGL-Refpages/es2.0/xhtml/glReadPixels.xml is a place to better understand the calls being used. 

some things to keep in mind, firstly it is a single pixel sample, so any dithering or blending happening in the shaders is not captured by this it is a point sample and nothing more. Furthermore, I doubt the alpha value has any valid meaning for a typical user use of this feature for while the alpha channel will exist in the framebuffer (the storage used for the screen) and alpha channels are processed by many of the operations that occur in the shaders, the alpha channel is disabled by default in the framebuffer and not used, and if you think about it, unless your desktop was showing through the window, the total sum alpha of that point on the screen render must be 0. This may further ask the question as to why it is shown, to which the answer is "its a debug setting" and just because that value may mean nothing when sampling a standard scene, it may be valuable when debugging and developing.

 

 

 

 

 

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites
2 minutes ago, Beq Janus said:

Personally, I would not have added that to quick prefs, I don't know the history of those choices.

I believe it was added to Quick Prefs to save users digging around in the Develop menu because it's pretty common for creators to include a notecard with their products explaining how to use "Show Color under cursor" for color matching attachments to skin tone.

  • Like 1

Share this post


Link to post
Share on other sites
4 hours ago, Whirly Fizzle said:

     This looks like the right bit of viewer code.

 


  if (debugShowColor && !LLRender::sNsightDebugSupport)
        {
            U8 color[4];
            LLCoordGL coord = gViewerWindow->getCurrentMouse();
            glReadPixels(coord.mX, coord.mY, 1,1,GL_RGBA, GL_UNSIGNED_BYTE, color);
            addText(xpos, ypos, llformat("%d %d %d %d", color[0], color[1], color[2], color[3]));
            ypos += y_inc;
        }

GL_RGBA is Red, Green, Blue, Alpha

Then I read https://www.khronos.org/opengl/wiki/GLAPI/glTexImage2D & my brain exploded  :D

It's how it goes from "Each component is clamped to the range [0,1]" to the displayed range that looks careless, and that doesn't get mentioned in any way I can understand. I'm guessing "llformat" is involved, and the "%d". And that's the detail that is totally missing from the Firestorm documentation. You can argue that GL_UNSIGNED_BYTE implies a 0-255 range, but nobody bothers to tell us. Likewise over what "alpha" means in this context. It's used in the ALM/materials settings for a different purpose than transparency, and that is defined. Transparency makes no sense for screen pixels, we're guessing that it's meaningless.

My brain hasn't quite exploded yet over that OpenGL wiki page. It's very inclusive, but details are there. I wouldn't call it user-level documentation, but it is documentation.

 

Share this post


Link to post
Share on other sites

I'm really failing to understand why @arabellajones makes it sound like this feature is somehow a "hack" or "very confusing" and "shouldn't be there."

The first three numbers are RGB, ranging from 0 to 255. This can be easily confirmed by checking a fullbright prim with a blank-white texture. White is 255 255 255, black is 0 0 0. While doing this, you'll notice that "alpha" for white is also 255 and black is 0. 50% grey (128 128 128) has an alpha of 132, which definitely seems odd at face-value, but the alpha value can be completely disregarded because you really only care about the RGB values. (And yes, GL_UNSIGNED_BYTE switches the range from [0,1] to [0,255], as explained here)

You as the user can't figure out why the alpha value is what it is. The simplest and broadest explanation is that it doesn't measure the transparency of what's on your screen, but what's in the corresponding "memory" (that you don't see). The reason for whatever the value actually is is hidden deep in the rendering code, which most won't dare to venture into. The solution for this "undocumented hack" would be to just not show that fourth value. Functionally identical, just no longer bothering some people.

As for llformat (source), that's just a common string-formatting function, it allows you to replace patterns with values, %d means decimal (aka integer). LL's version just has some platform-specific lines, it doesn't alter the input/output.

Edited by Wulfie Reanimator
  • Thanks 1

Share this post


Link to post
Share on other sites
5 hours ago, Whirly Fizzle said:

I believe it was added to Quick Prefs to save users digging around in the Develop menu because it's pretty common for creators to include a notecard with their products explaining how to use "Show Color under cursor" for color matching attachments to skin tone.

This I can believe. Which comes back to the simple facts that this feature is a debug setting that reads values directly from the image buffer. It then displays them in the most common normalised form for representing 8 bit colours, which matches that you would most likely use in setting RGB values into photoshop or similar. 

The problem here comes back to the fact that people continue to point users to functions that are not intended for their use, give poor advice and then we get blamed for it being obscure and hidden or (apaprently) too easy to find and not well enough documented. 

2 hours ago, arabellajones said:

It's how it goes from "Each component is clamped to the range [0,1]" to the displayed range that looks careless, and that doesn't get mentioned in any way I can understand.

The section you are missing is in the page I gave you  that documents the glReadPixels() call, where it mentions that they are converted to a value 0-255 (2^8-1). A more comprehensive list of conversions is giving on the OpenGL4 page https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glReadPixels.xhtml

1599adf4e6a840164f10241b71767fd4.png

I think the documentation is perfectly adequate given the intended purpose of the feature. We do not provide any guarantees as to what those values should be or can be used for. In this instance, such advice should be documented by whoever it is suggesting users do this ill-advised sampling. As I stated before, disabling ALM will give you more consistent results as it removes some of the nuanced lighting effects that will be at play, but I don't hold much confidence in the results being any better than doing this by eye. Colour matching is a poor relation to having a proper texture applier, modern skin textures are not a single tone and as such matches will always be at best approximate.

I do find it amusing that some users feel so strongly that they are entitled to make demands over where we (myself, other developers/testers/support staff/mentors, etc) should be spending the time we give freely. 

On 2/16/2019 at 9:28 AM, arabellajones said:

If I want to find out what colour is used in something, such as for matching a skin tone, I'd do better to take an in-world picture, save it to my hard drive, and check that image.

You'd do better to contact the creator you are trying to match to and ask them to provide a sampled average tone for an area around the joint that you are matching to based on the diffuse texture that they have.

  • Thanks 3

Share this post


Link to post
Share on other sites
2 hours ago, Wulfie Reanimator said:

I'm really failing to understand why @arabellajones makes it sound like this feature is somehow a "hack" or "very confusing" and "shouldn't be there."

Short answer: I am not a programmer.

And when this debug function got put into the Firestorm Quick Preferences, nobody bothered to explain what this "alpha" value was for. Alpha channels can be used for other purposes than transparency, but nobody seems to know what it does here.

It doesn't look all that difficult to make a duplicate of the function (is that what you call them) that is switched on by Quick Preferences and only returns the RGB data. But what do I know? I'm only a user.

  • Like 1

Share this post


Link to post
Share on other sites
6 minutes ago, arabellajones said:

Alpha channels can be used for other purposes than transparency, but nobody seems to know what it does here.

@arabellajones, just because you don’t like or don’t understand @Wulfie Reanimator‘s answer, doesn’t mean “nobody..[knows]..what it does here.”

3 hours ago, Wulfie Reanimator said:

The first three numbers are RGB, ranging from 0 to 255. This can be easily confirmed by checking a fullbright prim with a blank-white texture. White is 255 255 255, black is 0 0 0. While doing this, you'll notice that "alpha" for white is also 255 and black is 0. 50% grey (128 128 128) has an alpha of 132, which definitely seems odd at face-value, but the alpha value can be completely disregarded because you really only care about the RGB values. (And yes, GL_UNSIGNED_BYTE switches the range from [0,1] to [0,255], as explained here)

 

 

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, arabellajones said:

It doesn't look all that difficult to make a duplicate of the function (is that what you call them) that is switched on by Quick Preferences and only returns the RGB data.

Essentially: 

 

Edited by Wulfie Reanimator
  • Like 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×