PROBLEM RGB Tweet

[Interfaces]

I have trouble with RGB colors, they do not correspond with sketchup,
see attached example. please help me. I use sketchup 8 and octane1-05

thanks.

[TIG]

The two colors do correspond 'exactly'.
SKP uses RGB 0 .. 255
OCS uses RGB 0 .. 1.000
The exporter translates the SKP integer values into the OCS float format to 6dp.
In your example the R & G [V] are exact, and the B is to within 0.0000..., but 'exact' to the accuracy of 3dp for the input/display allowed in the OCS anyway.
R: 255/255.0==1.000
G: 153/255.0==0.600
B: 50/255.0==0.196[078431372549020]

Your display drivers 'gamma' settings might need correcting at each app's level ?

This might explain how the same color appears differently in the two windows, when the numerical values are actually the same, just shown in different formats...

Also a rendering 'material' might use other properties unavailable in the SKP, and 'ambient' lighting affects etc changing how a color 'looks'...
Try adjusting some of those other settings to see if the OCS 'orange' approaches that of the SKP ???
If you export a similar image from the SKP and OCS what do the same colored surfaces look like then when viewed in a third app ?

[Interfaces]

Excuse me, but for me it is not good I did a comparison of colors with Photoshop, see attached example. if you change the values ​​"HEX" as the photoshop colors is good!

thanks

[TIG]

BUT then by transferring the hex value you have set the G[V] to 0.325 which is not 153/255 [0.600] AND B to 0.028 which is NOT 50/255 [0.196[078431372549020]
Seems to me that Octane's colors as % RGB 0.000 .. 1.000 as opposed to the SKP's 0 .. 255 don't work right...
Raise this issue in their general forum as it's not directly Sketchup related, because surely you agree that a B of 153 in the SKP system is 60% of 255 NOY 35% and for G of 50 in the SKP system it is 19.6% of 255 NOT 2.8% ?
An OBJ's MTL passes color as % [0.000000... 1.000000] so the OCS needs to interpret those... Octance seems to be wrong in it's relationship of RGB % to hex! NOT the exporter...
Indeed if you make an orange-box in the SKP with those colors and export it as an OBJ then when you re-import it into the same SKP as an OBJ the colors are exactly the same ! So the conversion from 0..255 to 0..1.000 works for other apps... this suggests that Octane is broken !!!

[roeland]

This happens because the values displayed in Sketchup are specified in the screen color space, but Octane expects the values in the MTL file to be specified in linear space. Usually screen space means sRGB, and you can convert to linear space with a gamma correction of 2.2.

The following image illustrates this (*).

The middle part are black and white stripes, its brightness is guaranteed to be the average between white and black.
The left part is #808080. It should be much darker than the middle part (about 22% brightness).
The right part has #BABABA. This should have the same brightness as the center. (186/255)^2.2 is approximately 50%. The exporter should write (.50 .50 .50) for this color.

gammademo.png (690 Bytes) Viewed 5282 times

(*) If your display uses TN technology then you need to have your eyes exactly at the same height as the image. Despite what the manufacturers claim these monitors usually have a very narrow vertical viewing angle.

--
Roeland

PS. A lot of programs ignore all of this and assume all the color values are linear. Try resizing this image in any photo editing program to 50% of its size, or blurring the image, and see what happens to the middle part. Most probably it gets averaged to #808080 making it much darker.

[TIG]

@roeland

But isn't that being somewhat foolish of Octane ?
The standard OBJ exporters from most apps take x/255 NOT (x/255)^2.2...
The Sketchup Pro OBJ Exporter does exactly this and my Exporter simply replicates that.
Both exporter's MTL files are the same values for Kd.
If I manually edit the MTL file so that the Kd values ^2.2 an orange color in the SKP is much redder in the adjusted MTL [although it then looks OK in the OCS].
But making it useless for reimporting into apps like Sketchup as the color is then 'wrong' - the Sketchup OBJ importer expected x/255 values too...
OK it looks right in the OCS but little use elsewhere...
Why doesn't the Octane OCS importer do the magic to the standard MTL Kd values to suit Octane rather than the OBJ Exporter having to make a bastardized MTL file that only then suits Octane.
Until I made my Exporter there was no integration between Sketchup and Octane and Pro users had to make the OBJ/MTL files manually and them import using a console command... So the RGB>>Kd was screwed up way back then...
No one has mentioned it till now... I assume everyone messed on with other setting to make it 'look right'...
Do many other OBJ Exporters in other apps make this 'correction' to the Kd values ?
Sketchup never has, and expects what comes back into from an MTL file to be in the x/255 format too...
Online guides I found always convert RGB to MTL Kd values using x/255 - no ^2.2 in sight !
The SketchUp built-in DAE exporter also does the direct x/255 conversion from RGB to 0.0000 .. 1.0000 too...
This 'screen' versus 'linear' seems weird...

I can easily 'fix' the Kd values ^2.2 but somehow it seems counter intuitive...

[TIG]

I have updated the current Exporter and it now seems to make the MTL colors exactly suited to Octane's gamma correction needs [(x/255)**2.2]
See its new thread. viewtopic.php?p=122440#p122440

[roeland]

Some programs write the colors in screen space, others will write it in linear values. There is no standard specifying which one is correct. Octane assumes a linear workflow and picks the latter, so it assumes that Kd .5 .5 .5 means 50% brightness.

A display will normally display a darker color when it receives [128 128 128]. The response curve originally came from how CRT displays work (according to W3). The main benefit of using a gamma-correction in displays is less posterization in dark areas of images. The difference between 254/255 and 255/255 in a bright area is hardly noticable, but the difference between 1/255 and 2/255 in a shadow is quite visible. The effect of this non-linear response curve is slightly more posterization in bright areas, but much less in dark areas. With 8 bits per channel there are 31 steps from 0% to 1% instead of 3.

--
Roeland

[cyb]

Since this is apparently an issue why not allow user to select the color space?
Basically select obj and and have a toggle that converts the values on the fly. This way exporters would not have to be modified for different pieces of software.

[Phantom107]

Very informative, thanks.