I am trying to display in a text display object the values of r g b in the same way as the color picker.
How can I do that?
You can set Rich Text in the Text Display Options Panel and then use it in the Formula. Here is an example:
"<color:FF0000>Red <color:00FF00>Green <color:0000FF>Blue <color:AB6F03>Brown"+cr()+"<color:000000>Black"
This produces this result:
Not sure I’m following you on this but the Hex Color # shown in your picture above as CF0500 is the converted Red (207=CF hex), Green (05=05 hex) and Blue (0=00 hex). Beyond that I don’t know what else you may need. Maybe to add these values into your rich text formula converting to hex. Here is a simple example using your figures from above:
"<color:"+hexstr(207)[-2,-1]+hexstr(05)[-2,-1]+hexstr(0)[-2,-1]+">Your color"
This produced the following in a Text Display Object:
There’s a color picker in the Font Awesome window, it uses HSB rather than RGB, which I think is more sensible for adjustments. The RGB color is shown as hex values at the top, and could be displayed as separate values if you wanted. This window is not locked down, so you can go in and “borrow” the code and artwork yourself if you wish to.
Im probably missing something obvious, which is usually the case. This is for a print work flow, which is usually cmyk but in some cases rgb is better to start with. Ultimately lab color is how our industry measures color accuracy with what is called a delta e variance. So, I was hoping to mimic the image I uploaded so I could key in rgb values to adjust the color of the image display object. Then I will print, then measure to see if the color is with in the tolerances we have to achieve. For each rgb value, I will be using a field to track each iteration of rgb values so I can keep track of what color rgb settings I have already used.
Hopefully this explains it better.
How are you going to make this adjustment? The image display object doesn’t have facility for adjusting color.
Panorama supports RGB or HSB colors, it does not support CMYK. You can input a number as RGB and then output it as HSB, or vice versa. You can also ask for a dialog to be displayed with the standard system color picker – that might be the easiest bet for you.
I’m not going to say constructing an RGB picker in a form is impossible – I think it could be done, but that is not a standard feature and it would be a considerable project.
But I think the biggest question is “adjust the color of an image” – Panorama is not capable of doing that.
Actually not adusting the color of an image. Im creating just 1 record for every color that is critical to the client. Just image display showing a color. with the rgb values displaying in the same way the color picker does. Instead of 44718.1028,59110 I was hoping to have it show.
In the Color Picker it shows
Red - 173
Green - 2
Blue - 230
the formula rgbstr(AE04E6) shows
Red - 44718
Green - 1028
Blue - 59110
You need to divide each value by 256.
Using radix( on each 2 digits of the hex color with this formula:
"Red - "+radix(16,"AE04E6"[1;2])+cr()+
"Greesn - "+radix(16,"AE04E6"[3;2])+cr()+
"Blue -"+radix(16,"AE04E6"[5;2])
produces…
Not exactly what the Color Picker shows but very close.
Actually, the ratio seems to be 257 (65535/255)
"Red - "+int(44718 / 256)+lf()+
"Green - "+int(1028 / 256)+lf()+
"Blue - "+int(59110 / 256)
seems to do it. Result is
Red - 174
Green - 4
Blue - 230
which is consistent in this example to the system color picker. Ill test some more. Thank you very much gentlemen.
174*257=44718
4*257=1028
230*257=59110
Dave, I think you are correct, it needs to be 257
No, the ratio is 65536/256 = 256. There are 256 possible values from 0 to 255.
That’s the number of possibilities, but it’s not the conversion factor.
174*256=44544
174*257=44718
4*256=1024
4*257=1028
230*256=58,880
230*257=59110
256 and 257 both give the right answer when you are doing integer division, because they get rounded to the same integer, but 257 is the one that works when you are going the other way.
As you already know… you are correct Dave. Thank you
That Dave is correct is always a safe bet, and yet I disagreed. So silly of me. After really digging into it, yes, 257 is really the correct answer. The rest of this post is the technical explanation I figured out for my own sanity as to where the number 257 came from, feel free to ignore this. All values below are in hexadecimal unless stated otherwise.
Where I went wrong was thinking this conversion was just an 8 bit left shift (which is the same as multiplying by 256 decimal). An 8 bit left shift produces results like this.
00 -> 0000
01 -> 0100
02 -> 0200
...
FE -> FE00
FF -> FF00
But actually, it’s not just a shift, the upper byte is actually a copy of the lower byte, like this.
00 -> 0000
01 -> 0101
02 -> 0202
...
FE -> FEFE
FF -> FFFF
It turns out this is the same as multiplying by hex 101, which is decimal 257. Voila!
Now I was wondering if Panorama was doing this wrong internally. There is no constant of 257 in Panorama’s Objective-C code. However, it turns out that’s because there’s no place that the ObjC code directly converts from 8 bit to 16 bit colors like this. Internally, AppKit classes use floating point values from 0 to 1 for colors. So it turns out, Panorama has code for changing from 0 to 1 to 0 to FF, and from 0 to 1 to 0 to FFFF and the reverse conversions as well. All of those are done correctly, so if you chain those to convert from 0 to FF to 0 to FFFF the calculation is done correctly. Whew!