Floating point overflow

Using a large number of floating-point (datatypes (float)? and/or (double)?) in a single statement can cause problems wherein the result will be unpredictable. Code will continue to run, but all floating-point calculations after the first occurrence of the bug will be unreliable.

Generally this will not occur but when some floating-point intensive functions are used (such as iget, rgb2lab, lab2rgb, rgb2hsl and hsl2rgb), problems may appear more quickly. The order in which these functions appear in the statement heavily influences this bug.

As a rule of thumb, always put the functions before the other parts. As such...

double value = iget(100., 100., 0, 0, 3) * 0.5; // This works

Instead of the following...

double value = 0.5 * iget(100., 100., 0, 0, 3); // This DOES NOT work

Image width of 1 pixel

If the image width is only 1 pixel an error occurs:

unexpected NULL outData

Signed / Unsigned operands

No difference between signed and unsigned operands of /,%,>>

A:x+y?a:Info("0x8000000u/2u %x",0x8000000u/2u) // unsigned: 0x40000000
A:x+y?a:Info("0x8000000u%5u = %i",0x8000000u%5u) // unsigned: 3
A:x+y?a:Info("-2>>1 = %i",-2>>1) // signed: -1

Click Drag

setClickDrag(1): (right mouse key)

Preview flickering when pressing right mouse key and writing text.

Pressing Alt-Key once slows down update frequency.

ctl(0): statictext
ctl(CTL_PREVIEW):preview (mousemove)
 return false;
 return false;


Does not work with selections or zooms other than 1 (100%)

Variables not updated

In the OnFilterStart: handler system variables like scaleFactor, X, Y, x_start, ... are not yet updated after changes and have still old invalid values.


(iget) correctly handles the 16-bit case when reading from the input or output image buffers, but it always accesses the 4 t-bufs as though they were 8-bit.