5 comments

[ 2.2 ms ] story [ 24.2 ms ] thread
Seems like overengineering indeed. Additionally, it’s under-engineered also since Normed doesn’t store the transfer function (gamma) so you cannot use it pretending it’s just a fixed-point float!
What is a "fixed-point float"? That sounds like a contradiction.

And what sort of transfer function are you referring to?

Sorry, meant fixed-point fractional number of course.

Transfer function is the nonliner transformation used to more effectively use the limited resolution of integer values. Most typical is sRGB gamma (luminance ~ (value / 255) ^ 2.2) or Perceptual Quantization (PQ, smpte2084) for HDR videos. If you want to perform filtering in linear domain (i.e. for your color transformations to look natural) you need to linearize the signal.

The author is mistaken, there is nothing imprecise or floating about https://github.com/JuliaMath/FixedPointNumbers.jl.

Representing values on a scale from 0.0 to 1.0 instead of 0 to 255 (say) is a good idea if you have to do things like DFT. Most software implementations use fixed point arithmetic for that.

+1. Further, when accounting for the fact that images can be represented in arbitrary color spaces, the representation in Julia images seems quite thoughtful given that Julia has no problems doing fast loops through the structs (unlike Python), or equivalent exposing an array like view on demand.

Storing images as arrays of unsigned 8-bit integer seems quite primitive in comparison!

> ” Sorry, I don’t like using floating-point numbers to represent pixels. Call me old-fashioned, I know how imprecise non-integers are.”

WTH does this even mean?!