[cycles] svm/osl difference on classroom scene. #52887

New Issue

Ray molenkamp · 2017-09-24T19:16:43+02:00

Ray molenkamp commented

2017-09-24 19:16:43 +02:00

System Information
Win7/x64 Cpu render

Blender Version
Broken: 2.79
Worked: unknown.

Short description of error
when rendering classroom_cpu on both svm and osl there's some significant differences between the two

The map of europe on the left is different seems like osl is doing some filtering, while svm doesn't
The clock is darker with OSL
The edges of the blue book on the front desk have a highlight on osl
the blackboard looks kinda faded on OSL, probably same filtering that caused 1.

Exact steps for others to reproduce the error

Load up classroom_cpu (turn down the resolution to 25% to speed things up if you want)
Render with svm in render slot 1
render with osl in render slot 2
blink in between slot 1 and 2 to see the differences

svm:
osl:
idiff
( parameters used for idiff : --scale 10 -abs -o diff.png classroom_svm.png classroom_osl.png )

**System Information** Win7/x64 Cpu render **Blender Version** Broken: 2.79 Worked: unknown. **Short description of error** when rendering classroom_cpu on both svm and osl there's some significant differences between the two 1) The map of europe on the left is different seems like osl is doing some filtering, while svm doesn't 2) The clock is darker with OSL 3) The edges of the blue book on the front desk have a highlight on osl 4) the blackboard looks kinda faded on OSL, probably same filtering that caused 1. **Exact steps for others to reproduce the error** 1) Load up classroom_cpu (turn down the resolution to 25% to speed things up if you want) 2) Render with svm in render slot 1 3) render with osl in render slot 2 4) blink in between slot 1 and 2 to see the differences svm: ![classroom_svm.png](https://archive.blender.org/developer/F864506/classroom_svm.png) osl:![classroom_osl.png](https://archive.blender.org/developer/F864510/classroom_osl.png) idiff ![diff.png](https://archive.blender.org/developer/F864515/diff.png) ( parameters used for idiff : --scale 10 -abs -o diff.png classroom_svm.png classroom_osl.png )

Ray molenkamp commented

2017-09-24 19:16:43 +02:00

Changed status to: 'Open'

Ray molenkamp commented

2017-09-24 19:16:43 +02:00

Added subscriber: @LazyDodo

Sergey Sharybin commented

2017-09-25 09:16:10 +02:00

Added subscribers: @brecht, @Sergey

Brecht Van Lommel was assigned by Sergey Sharybin

2017-09-25 09:16:10 +02:00

Sergey Sharybin commented

2017-09-25 09:16:11 +02:00

OSL is doing proper mipmapping, so map and blackboard will be different at that number of samples. Packing images (which forces OSL to use ImBuf for file IO which doesn't have mipmaps) makes those look identical.

Not sure why book and clock are rendering differently, yet. Maybe @brecht can have a look? :) Otherwise assign back to me.

OSL is doing proper mipmapping, so map and blackboard will be different at that number of samples. Packing images (which forces OSL to use ImBuf for file IO which doesn't have mipmaps) makes those look identical. Not sure why book and clock are rendering differently, yet. Maybe @brecht can have a look? :) Otherwise assign back to me.

Brecht Van Lommel commented

2017-09-25 14:14:18 +02:00

Changed status from 'Open' to: 'Archived'

Brecht Van Lommel closed this issue

2017-09-25 14:14:18 +02:00

Brecht Van Lommel commented

2017-09-25 14:14:18 +02:00

Mipmapping is just biased and will give different result, nothing that we would consider a bug at this point I think, even if it's possible to improve.

If the footprint is big pixels from far away get pulled in, and if they are darker on average that will darken the result. This bias could be reduced by limiting mipmap levels, at the cost of efficiency. Note the clock has a texture applied with dark colors outside the UV island.
Filtering of these textures in OpenImageIO happens in sRGB color space instead of linear space. For that the suggested solution is to use linear half float .tx files. It would be nice to add support for that kind of workflow, but probably when we support mipmapping for SVM. Another solution is that the OpenImageIO texture cache could convert to linear on the fly when reading tiles, but it has no color space awareness currently.

Mipmapping is just biased and will give different result, nothing that we would consider a bug at this point I think, even if it's possible to improve. * If the footprint is big pixels from far away get pulled in, and if they are darker on average that will darken the result. This bias could be reduced by limiting mipmap levels, at the cost of efficiency. Note the clock has a texture applied with dark colors outside the UV island. * Filtering of these textures in OpenImageIO happens in sRGB color space instead of linear space. For that the suggested solution is to use linear half float .tx files. It would be nice to add support for that kind of workflow, but probably when we support mipmapping for SVM. Another solution is that the OpenImageIO texture cache could convert to linear on the fly when reading tiles, but it has no color space awareness currently.

Sergey Sharybin commented

2017-09-25 14:17:38 +02:00

@brecht, packing images (which forces OSL to bypass filtering) still keeps clock darker and book looks different.

Brecht Van Lommel commented

2017-09-25 14:23:14 +02:00

The clock and its texture are from a linked .blend, did you pack that one as well?

Sergey Sharybin commented

2017-09-25 14:40:24 +02:00

Ah, you're right. "Pack All" will not pack textures from linked materials, so ok. It's all caused by mipmaps...

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

[cycles] svm/osl difference on classroom scene. #52887