Am 26.02.2016 um 05:44 schrieb clipka:

> The following look noteworthy to investigate:
> 
> changeset:   94:8e40f1a50cfd
> parent:      92:e995e1ab7beb
> parent:      93:a07181fe86db
> user:        Christoph Lipka <c-l### [at] usersnoreplygithubcom>
> date:        Thu Jun 19 10:24:56 2014 +0200
> summary:     Merge branch 'master' into refactor
> 
> and then:
> 
> changeset:   96:f2d948f2a077
> bookmark:    hotfix/photons_eca922a2
> tag:         default/hotfix/photons_eca922a2
> user:        Christoph Lipka <c-l### [at] usersnoreplygithubcom>
> date:        Wed Jun 25 16:42:36 2014 +0200
> summary:     fix photons bug introduced with commit
> 'eca922a2819fabbadd82c31e4bfadaa0c425b5b5'
> 
> In between these, we have a change in how photon colour/brightness data
> is stored.

I think I'm up to something here.

The changes between these two commits are all about the encoded storage
of photons in an RGBE format, which is an adaptation of the floating
point idea to the domain of colours, using three independent mantissas
for the colour channels but a single shared exponent. This idea is also
at the core of the Radiance HDR image file format.

Photon storage and the Radiance HDR image file format use virtually the
same variation of the format, using 8-bit unsigned integers for both the
mantissas and the exponent, with the one exception that for photons an
exponent bias of 250 was chosen, while Radiance HDR uses a bias of 128.

Originally, the data type for photons storage was a simple C-style
4-element unsigned char array, with associated C-style global functions
for encoding and decoding. The Radiance HDR file format handling used
its own independent functions doing virtually the same thing.

Now in the aforementioned changes, this was refactored into a common
C++-style template class type for both photons and Radiance HDR code.

Having looked again at that changed code, I noticed some peculiarities
about the code that I didn't quite understand (yes, I know I wrote the
code myself ;)), and which I currently consider inferior, but I also
wasn't quite sure what that "photons bug introduced with commit
'eca922a2819fabbadd82c31e4bfadaa0c425b5b5'" was that had to be fixed
back then, and whether those peculiarities were there for a reason, so I
decided to revert those changes to revive that bug again.

I immediately recognized the resulting "optics.pov" render as the thing
that prompted me to implement the fix, so I'm sure again what it was all
about: In the process of refactoring I had made a slight "improvement"
that turned out to add a little bit of white light to otherwise pure
colours.

Now this doesn't look anything like what ThH has reported, nor what
you're seeing in your tests; but there is someting intriguing about it
that hadn't caught my attention back then:

It doesn't affect /all/ the rays.

As a matter of fact, it affects /exactly/ the very same subset of rays
as the issue now under investigation.


I think this is very strong evidence that the current issue is also
rooted in the RGBE handling code.

Post a reply to this message

Attachments:
Download 'optics.png' (284 KB)

Preview of image 'optics.png'