scott <sco### [at] scottcom> wrote:

>
> A gamma 1.0 colour picker needs to know how your monitor is calibrated
> to function correctly.  It can assume sRGB, but if your monitor is not
> sRGB you will run in to the same problems as just using the srgb keyword.
>
> So IMO it easiest (and just as correct) to simply pick colours from
> Paint/MS Office etc and then use the srgb keyword.

I use a little Adobe stand-alone app called "Adobe Gamma" to tweak my monitor's
gamma (2.2); I looked at the ICC profile there, and it *is* sRGB. (Same in
Photoshop itself, BTW.) So if I understand it all correctly, I guess I'm good to
go, with *either* of the two ways of picking the colors.

Ken

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

> I'd say, a dialog in the POV-Ray GUI would be best for such a purpose.
> [clip]
> ...a built-in color picker in the POV-Ray GUI, giving colors in the
> fitting range, with "auto-paste" functionality, would be nice anyway.

Built-in to Windows POV-Ray?!  WONDERFUL idea. I didn't dare to even suggest
that; but I have to admit that it was on my mind. ;-) Glad to see it mentioned
by someone else!

>
> Note however that various versions of Photoshop
> do not exactly default to a gamma 2.2, but to sRGB color space...

I keep forgetting that the two are not quite identical; I need to re-read all of
your WIKI material.

Do I understand that sRGB and 'vanilla' gamma 2.2 are different ICC profiles?
Sorry if that's a rather 'newbie' question; it's just difficult to keep track of
some of this arcane stuff. If they're different, which one is better for
rendering with POV-Ray using assumed_gamma 1.0?

Ken

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> But a built-in color picker in the POV-Ray GUI, giving colors in the
> fitting range, with "auto-paste" functionality, would be nice anyway.

That would be awesome!

Regards,
Dave Blandston

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> schreef in bericht 
news:web.4d2d3693c140d037196b08580@news.povray.org...
> I downloaded Sven's v2.0 Color-Picker, but it seems to be bug-ridden on my
> Windows XP system. (Hard to tell, actually, because it has an 
> unconventional
> user interface; but its behavior seems odd.) And AFAIK, it doesn't have a
> gamma-changing feature. Do you use this app successfully? Is there a newer
> version?

I have used it for years without any trouble. My version is 2.0; no newer 
version
 afaik It has no gamma setting, so results are slightly off in POV-Ray 3.7.

> If my memory serves me, I may have tried downloading Vanderburg's POVColor 
> app
> in the distant past; but couldn't even get it to run.
snip
> Looks interesting on first glance, if a bit complex; but it *does* have a
> gamma-changing feature. I haven't worked with it enough yet to know if 
> that
> feature works as I envisioned. I'll play around with it.

It works alright for me although I have not used it much. Results are 
slightly better in 3.7 than Sven's app, probably due to the gamma 
correction.

Thomas

Post a reply to this message

> Do I understand that sRGB and 'vanilla' gamma 2.2 are different ICC profiles?

"gamma 2.2" only defines how output brightness relates to the raw pixel 
values, it is not a colour space.  sRGB specifies the exact physical 
colours that are represented by the RGB primaries, and in addition the 
function to convert from pixel values to output brightness.  That 
function is very close to gamma 2.2, but not quite.

http://en.wikipedia.org/wiki/Srgb

Post a reply to this message

Sorry for the delay; I was working on an idea.

If there's even the slightest chance of having a gamma-1.0 GUI color-picker
built-in to POV-Ray, some initial concepts might be useful.

Here's my first-thought idea (a mock-up based on the COLRSCR32 app.) It may or
may not be the best way to do this, or even visually appealing (perhaps a
PAINTER-like color wheel would be more appropriate than sliders); but it
embodies some structural ideas that I think might be important. These are
debatable, of course; comments/criticisms/alternative ideas are welcome.

1) This model assumes that we will use either assumed_gamma 1.0 or assumed_gamma
2.2 in POV-Ray--no other in-between values. At this point in POV-Ray's
evolution, I don't know whether that's good or bad. ;-)

2) Meant to be simple, straightforward, no 'bells and whistles', no fancy
out-of-the-ordinary GUI interface. (Perhaps my own example isn't simple enough.)

3) It's fundamentally a *visual* color picker, by moving the sliders; but also
allows values to be entered.

4) It shows the color in both gamma 1.0 space AND the 'typical' gamma 2.2 space.
The two sets of sliders and data boxes are to make it easy to choose the values
in *either* color space, and get the gamma 1.0 equivalents. The gamma 2.2
color-picker may seem unnecessary, but it's there for those not wishing to use
assumed_gamma 1.0; and if nothing else, this dual set-up might prove useful as
an 'instructional comparison' between the different values. The basic idea is
that you can choose a color from EITHER square--whichever you feel comfortable
with--and the app automatically figures out *visually identical* gamma 1.0 and
gamma 2.2 colors. Ditto entering values instead (in either set of boxes.)

5) The 'gamma 2.2' stuff is always active, but purposely grayed out slightly (at
all times) and maybe smaller overall--simply to signify that the 'gamma 1.0'
color-picker is the *recommended* one.

6)  The app itself (and the 'gamma 2.2' color square) naturally show up visually
on screen in gamma 2.2 space--i.e., the whole thing looks proper on a typical
monitor.  ONLY the 'gamma 1.0' color square shows up visually in gamma 1.0
space. But no matter which square you work with, the app automatically 'matches'
that color in the other square.

7) The rgb values should be presented as both 0.0-to-1.0 AND 0-to-255 (for those
more familiar with that way of working.)

8) After choosing a color and hitting the 'OK' button, the rgb(ft) <.......>
block is automatically placed into the SDL scene code--no need for saving to the
clipboard or cutting and pasting. (Obviously, your cursor would need to be in
the correct location in the scene for this to work.) *OR*, it might in fact be
be more straightforward for the app to simply save it to the clipboard, and ONLY
that. Then it could simply be pasted in *after the fact*--i.e., anywhere, not
necessarily where your cursor happened to be beforehand.

This code insertion is based on the assumed_gamma scene setting; if 1.0, then
the contents of the 1.0 boxes are inserted into the scene; if 2.2, then the 2.2
box contents are used.

9) The filter and transmit bars have on/off buttons; if they are off, only the
rgb<....> values show up and are used.  But if, for example, the filter slider
is active, then it would show as rgbf <.....>. Most uses of color are without f
or t, I would imagine--and this keeps unnecessary vector entries out of the
color vector, just for scene clarity. Why should most colors in a scene be
listed as <value,value,value,0.000,0.000> when only three rgb values are used?
Seems like unnecessary clutter.

10) Should the number of decimal places be more than the 3 as shown?  Each of
the rgb color components have only 256 levels--BUT, 1/256 = .00390625 Hmmm...

Perhaps the app could have *user-selectable* decimal places for the output? For
example, I never use more than 2 or 3 places when specifying a color; seems kind
of overkill. But the app could allow more if wanted. (Which means the value
entry boxes would have to be wider?  Or maybe you could simply scroll aross them
to see the entire value?)

11) The 'grayscale' buttons are to toggle between color and grayscale versions
of the chosen color--just to check brightness levels, maybe.  (And this would
change the values in the boxes as well.)

12) The static black and white alternating bars(?) are to give a brightness
comparison to the color/grayscale appearance--possibly useful in tandem with
#11.  Note that I left out a '50%-gray' bar--because I don't really know what
that should look like! Might confuse the issue.

13) The app's size on screen should scale itself to the monitor's resolution and
size--not just a 'set' size for, say, a 1280X960-rez monitor--so that, for
example, an 800X600 screen doesn't show it chopped off on the right. I guess it
would need a 'minumum' size, of course.

Ken

Post a reply to this message

Attachments:
Download 'gamma_1_picker_a.jpg' (250 KB)

Preview of image 'gamma_1_picker_a.jpg'

Am 17.01.2011 21:53, schrieb Kenneth:

> This code insertion is based on the assumed_gamma scene setting; if 1.0, then
> the contents of the 1.0 boxes are inserted into the scene; if 2.2, then the 2.2
> box contents are used.

That won't work. Due to how the POV-Ray SDL works, it would require 
parsing of the whole scene just to figure out the effective 
assumed_gamma setting.

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:

> 12) The static black and white alternating bars(?) are to give a brightness
> comparison to the color/grayscale appearance--possibly useful in tandem with
> #11.  Note that I left out a '50%-gray' bar--because I don't really know what
> that should look like! Might confuse the issue.

Oops, sorry; I removed those bars from the mock-up (they didn't look too useful)
but forgot to edit out this text.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 17.01.2011 21:53, schrieb Kenneth:
>
> > This code insertion is based on the assumed_gamma scene setting; if 1.0, then
> > the contents of the 1.0 boxes are inserted into the scene; if 2.2, then the 2.2
> > box contents are used.
>
> That won't work. Due to how the POV-Ray SDL works, it would require
> parsing of the whole scene just to figure out the effective
> assumed_gamma setting.

You're right. :-[  It didn't occur to me that the color-picker would somehow
have to 'magically guess' what was written in the SDL scene; the code is just a
text file, after all. (Hmm...maybe the app could do a quick text search, looking
for 'assumed_gamma'?? Kidding. Or maybe not...)

Post a reply to this message

Am 19.01.2011 07:33, schrieb Kenneth:
> clipka<ano### [at] anonymousorg>  wrote:
>> Am 17.01.2011 21:53, schrieb Kenneth:
>>
>>> This code insertion is based on the assumed_gamma scene setting; if 1.0, then
>>> the contents of the 1.0 boxes are inserted into the scene; if 2.2, then the 2.2
>>> box contents are used.
>>
>> That won't work. Due to how the POV-Ray SDL works, it would require
>> parsing of the whole scene just to figure out the effective
>> assumed_gamma setting.
>
> You're right. :-[  It didn't occur to me that the color-picker would somehow
> have to 'magically guess' what was written in the SDL scene; the code is just a
> text file, after all. (Hmm...maybe the app could do a quick text search, looking
> for 'assumed_gamma'?? Kidding. Or maybe not...)

I guess it will be much easier, much more reliable and sufficiently 
convenient to have an assumed_gamma input box in the color picker 
(remembering its setting) where the user will have to input the 
corresponding value. Presuming of course that they're using "rgb<...>" 
instead of "srgb<...>" format, as the latter is independent of 
assumed_gamma setting.

Post a reply to this message