I am not sure this is the expected behavior but I am getting a positive foreground area size when image is all -nan, as in the example below:
> gmic -v -1 10,10 -div '{iM}' -area_fg 0,0 +echo '{iM}\n'
2
the division by iM is what causes the -nan. I bumped into this by accident when processing a blank image which was not supposed to be blank. Is this a bug? Area image is below.
Does area_fg not count the area of shapes? In your case, that shape is 2 pixels, so each pixel is given the value of 2.
It isn’t suppose to happen. I tested, and a sea of nan should remain the same everywhere in area_fg. It’s a island everywhere or not.
Sorry folks for introducing a false memory or fact.
Not really a bug. NaN often comes with undefined behaviors in C/C++, particularly when aggressive optimizations (like -O3) are used when compiling (which is the case for G’MIC).
I can’t tell exactly what is going on here, but if you use label_fg (native function) in a 10x10 image of -nan, you get indeed consecutive pixels with the same value, at the location of the small segment you see on the right:
$ gmic 10,10,1,1,-nan label_fg 0,0
This is hard to see in a first glance, but this command does not generate an image going continuously from 0 to 99.
See, top-left pixel is 1, which is the min value, and bottom-right pixel is 99, which is the max value. Pixels located at (8,4) and (9,4) have the same value 49.
labe_fg implements a forward/backward scanline pass over the image and do some tricky computations to mix the two passes. not sure what is going on, but as long as NaN is involved in a math operation, you cannot expect something very precise 