Page MenuHome
Create Task
Maniphest T52887

[cycles] svm/osl difference on classroom scene.
Closed, ArchivedPublic
Actions

Description

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:


osl:

idiff

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

Event Timeline

Ray Molenkamp (LazyDodo) created this task.Sep 24 2017, 7:16 PM
Sergey Sharybin (sergey) assigned this task to Brecht Van Lommel (brecht).Sep 25 2017, 9:16 AM
Sergey Sharybin (sergey) lowered the priority of this task from 90 to 50.
Sergey Sharybin (sergey) added subscribers: Brecht Van Lommel (brecht), Sergey Sharybin (sergey).

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 Van Lommel (brecht) can have a look? :) Otherwise assign back to me.

Brecht Van Lommel (brecht) changed the task status from Unknown Status to Unknown Status.EditedSep 25 2017, 2:14 PM

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 (sergey) added a comment.Sep 25 2017, 2:17 PM

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

Brecht Van Lommel (brecht) added a comment.Sep 25 2017, 2:23 PM

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

Sergey Sharybin (sergey) added a comment.Sep 25 2017, 2:40 PM

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