Indigo 0.9 test 4

[mrCarnivore]

Yup, the gamma value should be one.
The gamma is pretty much there for one purpose, to transform RGB colours picked in a 3D modeller to intensity-linear display values.
For all other cases, such as using absorption values from Jensen's paper, or Henyey Greenstein g-values, each RGB value is already correct, and doesn't need to be raised to the power of gamma. Therefore gamma should be left on 1 so that the value is not affected.

Could that be the problem with sss and absorbtion having different magnitudes to achieve the same result in 0.9 and 0.8, as I mentioned in another thread?

[OnoSendai]

Yes.

[suvakas]

Thanks Ono !
Good info. Will have to change the gamma values in Maxigo too.

[Vulture]

Yup, the gamma value should be one.
The gamma is pretty much there for one purpose, to transform RGB colours picked in a 3D modeller to intensity-linear display values.
For all other cases, such as using absorption values from Jensen's paper, or Henyey Greenstein g-values, each RGB value is already correct, and doesn't need to be raised to the power of gamma. Therefore gamma should be left on 1 so that the value is not affected.

Thank you. That was it. The following picture shows version 0.9t5 rendering a yellow glass. Blendigo exported all materials with a gamma of 2.2.
Again, thanks.

[Kram1032]

now, try to find out, how red it has to be, to be not green, anymore

[Whaat]

slight green may be due to white balance setting.

[Kram1032]

I never thought of this, yes, could be possible...
But the bg looks pure grey -> no wrong Whitepoint was used, I'd say...
Blue, as already said, also comes out too red...

If I think about it, like this...
could it be, that the greenpoint is a bit wrong in Indigo?
yellow things look too green,
blue things look too red (missing green)

I could be wrong, though^^

[carbon]

here is more or less color ballanced and unballanced comparison, but only if the background was shade of gray

EDIT: ah, color values are only for comparison and informational, i just picked two spots, with nearly same brightness..

EDIT #2: you should use 5500k emitter and D55 camera white ballance

[Wedge]

Yup, the gamma value should be one.
The gamma is pretty much there for one purpose, to transform RGB colours picked in a 3D modeller to intensity-linear display values.
For all other cases, such as using absorption values from Jensen's paper, or Henyey Greenstein g-values, each RGB value is already correct, and doesn't need to be raised to the power of gamma. Therefore gamma should be left on 1 so that the value is not affected.

Hi, I do not understand clearly what gamma values should be fixed to 1. I have gamma tags in all of these areas:

1. <absorption_coefficient_spectrum> (listed in your quote?)
2. <scattering_coefficient_spectrum>
3. <henyey_greenstein> (listed in your quote?)
4. <diffuse_albedo_spectrum>
5. <albedo_spectrum>
6. <spectrum> (rgb meshlight)
7. background environment color

Gamma should be fixed to 1 for which areas? 1, 2, and 3? If they need to always be 1, I will remove them as variables and write them in fixed to 1 so that users will not end up with incorrect colors. Thanks!

[OnoSendai]

Hi Wedge,
The general problem of setting physically-based spectral parameters using traditional input methods is an open one, and one that I don't have all the answers to.
If you're trying to match values given in a paper, then gamma should be 1, so as to not change the values.
for albedo spectrum, emission spectrum etc.., then if the user is expecting the emitted light to look like their RGB-picker colour in the 3D-modelling program, then gamma should be set to ~2.2.

[delic]

Thanks, works fine for small renders, but when I want to render 2k wide images it begins to crash just after Initial warmup done, and this only when two threads are launched ... it seems to render big formats with one thread.

The scene I tested with is big, 1.3 gigs ram usage total in windows.

I saw this by testing the scene with test4 release, it launches the render with one thread .

[Zom-B]

Thanks, works fine for small renders, but when I want to render 2k wide images it begins to crash just after Initial warmup done, and this only when two threads are launched ... it seems to render big formats with one thread.

The scene I tested with is big, 1.3 gigs ram usage total in windows.

I saw this by testing the scene with test4 release, it launches the render with one thread .

hmmm.... strange behavior

But you can try using the console build to save RAM, reducing super sampling also helps a lot.... forcing Bounding Interval could save some RAM too
(by reducing the "bih_tri_threshold" to 0)

[Vulture]

here is more or less color ballanced and unballanced comparison, but only if the background was shade of gray

EDIT: ah, color values are only for comparison and informational, i just picked two spots, with nearly same brightness..

EDIT #2: you should use 5500k emitter and D55 camera white ballance

Yes, the background is pure gray.

I made the lights 5500k emitters and used D55 for the camera for the next pictures. The only thing I varied was the rgb setting of the class absorbtion. By varing the g part the glass looks more red and less green. Klik the thumbnails for larger pictures.

rgb: 0 0 100 (original, posted before)


rgb: 0 .25 100 (little red, the best in my opinion)


rgb: 0 .5 100 (little more red)


rgb: 0 1 100 (again a little more red)


rgb: 0 5 100 (much more red)


I've attached the IGS file for the interested.

[Kram1032]

I'd say the .5 red is the best - the .25 still looks greenish...