Negative clause in linearize-srgb and delinearize-srgb

[wasserwerk]

The cond in linearize-srgb have a negative clause for x < -0.040449936d0 (exactly: (* -0.0031308d0 12.92d0)). You make similar computation in delinearize-srgb. Why? I've never seen such a formula (negative term). Neither in wikipedia, nor Bruce Lindbloom, nor other sources (e.g. https://www.w3.org/Graphics/Color/srgb.pdf).

[privet-kitty]

Hi. As in docstring written, it is actually the same formula as bg-sRGB, that extends the range of sRGB ([-0.53, 1.68] instead of [0, 1]).
http://www.color.org/chardata/rgb/bgsrgb.xalter

[wasserwerk]

All right! Understood. I read the comment, but didn't know, what bg-sRGB means. And I didn't google for it. Sorry.

As you wrote earlier, you prefer multiple values over lists for better performance. But here you do one comparision more that necessary (for sRGB) - for each color once, which gives millions for a real color image. Would not it be better to have one pair of linearizer/delinearizer for sRGB and another for bg-SRGB. Although the code is largely identical.

[privet-kitty]

You might mean

(defun linearize-srgb-faster (x)
  (declare (optimize (speed 3) (safety 1))
	   (double-float x))
  (if(> x #.(* 0.0031308d0 12.92d0))
     (expt (* (+ 0.055d0 x) #.(/ 1.055d0)) 2.4d0)
     (* x #.(/ 12.92d0))))

Though in reality it makes little difference in speed when doing

> (dufy::time-after-gc (dotimes (i 50000000)
                          (dufy:rgb-to-lrgb (random 1d0) (random 1d0) (random 1d0)))) ;; mistake edited

or something alike. (Of course, it's because almost all values here are processed in the first case.)
One more cond matters little. (A much larger overhead in dufy is dynamic call of (de)linearizer.)

[privet-kitty]

Additional remark:
I adopted the (bg-sRGB-type) extension in every normal (i.e. the nominal range = [0, 1]) RGB space, since it's consistent with the extensions already in use (bg-sRGB, scRGB-nl, etc.).