I am looking to include floating point support for an update to the IPLab coder (ipl.c). The code as it stands now is very clean and uses ExportQuantumPixels. For integer data during a normal Q32 build, this solution works fine. For float or double data, the procedure rounds down all fractional values. This is caused by inline function RoundToQuantum, which during a standard, build returns an integer (type Quantum).
Enabling hdri support fixes this issue with the caveat that scales get all messed up because it is an unscaled format. This can be tuned by adding a provision changing the scales if double Quantum is detected. So here is my question for seasoned IM programmers: Should I fix this with cpp routines, should I hardcode the solution, or should I make noise for a "--with-quantum-double" option in the configure script?
Sorry for the protracted posting. I hope I got my question across.
Best,
Sean
Non-hdri Float support?
Re: Non-hdri Float support?
Unless HDRI is enabled, pixel values are clipped and quantized to integer values between 0 and QuantumRange. We can think of no way around this other than enabling HDRI which was added to exactly handle this situation: floating point pixel values that may be inside or outside [0 .. QuantumRange]. Typically floating point values are [0 .. 1]. In that case scale them by QuantumRange * intensity and when exporting the pixel values use QuantumScale * intensity to return normalized pixel values.
What would be the difference between HDRi and your proposed --with-quantum-double option?
What would be the difference between HDRi and your proposed --with-quantum-double option?
Re: Non-hdri Float support?
If I understand it correctly, HDRI requires that all float values can be read/written to file. IM, on the otherhand, requires Float pixels to exist between 0.0 and 1.0 when the image is in memory. As far as I can tell, there is no way to write the values directly to file without multiplying through by the quantum range. According to the principle of confessional programming, this actually sounds pretty reasonable.
Perhaps "--with-quantum-double" should just operate like "--enable-hdri" in anticipation of more floating point formats. On my end, I'll write the coder to match this behavior.
Thanks!
Sean
Perhaps "--with-quantum-double" should just operate like "--enable-hdri" in anticipation of more floating point formats. On my end, I'll write the coder to match this behavior.
Thanks!
Sean
Re: Non-hdri Float support?
Float pixels are not 0.0 to 1.0. They are scaled to [ 0 .. QuantumRange ]. When exporting the pixels you scale to [ 0 .. 1 ] by multiplying by the QuantumScale constant.