We’re in the final leg of devember and bugs are starting to crumble.
Today I took on the colour mapping bug and the gamma weirdness.
First lets talk about colour and assumptions about colour. When I originally coded the wavelength to colour algorithm I took the assumptions that the RGB components would be positive and used unsigned ints for the colour output. What programmers think of as colour sadly is an oversimplification of the matter, and has nothing at all to do with wavelengths of light. So in the original HQZ model of colour Negative vales are used to interpret the absence of a colour from a given wavelength.
I took HQZ’s model a step further by swapping all colour and pixel values to long floats. This has the twofold performance increase of removing a bunch of casts and conversions, and removing the u64 saturation checks. Also int 16 math is not a very optimized execution path on modern CPU’s.
Details aside I was pleased to find I gained speed by fixing the colour output.
But Just cos chroma was correct now didn’t mean I was getting a desirable image output; I had to tackle gamma, which had been behaving oddly since I implemented it. The symptom was a washed out image whenever the gamma was set. (by default it was infinite)
Debugging was easy, HQZ applies 1/gamma to an exponent function. I had made a mistake in the translation of the algorithm and substituted a minimum function between the base and the power, essentially making the exponent a minimum value threshold, washing out the darkest parts of the image.
Fixed all left to do was tweak the demos to get the desired output:
(Bluring of the relection is due to a change in the demo file, a feature of the work I am emulating missed in earlier renders.)
Dawn.rs Rendered Properly: