There are actually no hard constraints on the value range of input/output images. G'MIC reads/writes a file just as an array of values, so if your input is 8bits RGB, you'll get values in range
[0,255]. If your input is 16bits, value range will be
[0,65535]. Float-valued images (as some
.exr files) are not constrained to be in a certain range, so you cannot expect values to be in
[0,1] or whatsoever (e.g. having
+inf value happens sometimes in certain
.tiff files). We assume the user has to know what kind of images he is loading/saving.
For instance, if you want to save a
.jpg file, you'll have to ensure the data you want to save fits the range
[0,255] before saving, otherwise you'll get some glitches in your saved picture.
Having said that (there are no hard constraints on image data), there are anyway 'conventions' followed by most of the G'MIC commands. For instance, the convention for commands applying on RGB images is that the value range of the R,G,B values should be in [0,255] (this doesn't mean 8bits, as values are expressed as floats). That's the case for instance when you convert between colorspaces (
-rgb2hsl,...). Another convention for defining 'masks' of any type (opacity masks, inpainting masks, etc...) is having values in range
Most of the time, the commands try to follow all the same conventions for the same kind of data.