If you convert a PNG with colors in it that not exactly match one of the mapped ones, it guesses what mapped color that might be. It does so by means of calculating the euclidean distance between every mapped color and the color of the pixel in the color space (RGB as coordinates). After running through that, it takes the mapped color with the shortest distance.
From all guessed distances, the maximum is displayed as "error distance". However, this distance is the quadratic one, so you have to take the square root of this to get the pixel distance. In your case, one of the colors was 18 away from the nearest mapped color.
I have changed that to a clearer text (and did the square root) already in my current work version.
In short I need to me more careful in selecting the colour I will use for the flat terrain of my base. I did use the eye drop tool mind.
So many thanks for the very fast response.
Added
I also wonder if it was also a colour created while changing the size of the file i.e. 259 by 259 to 512 for OBM. As pixels had to be "invented" ( calculated) so maybe colour was too.
I also wonder if it was also a colour created while changing the size of the file i.e. 259 by 259 to 512 for OBM. As pixels had to be "invented" ( calculated) so maybe colour was too.
Yes, it certainly can be that. If you manipulate height-maps like that, I'd recommend using the grayscale option "-g". However, you'd then need a tool that supports 16-bit grayscale. Gimp does not support them fully ATM, because it always converts them back to 8-bit grayscale.
If you don't get visual artifacts from the guessing, though, you can of course keep using that, too. It is not a real error, just an information that the system had to guess at one point.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.