I don't think any other savers have the same issue.

This is a bit more complicated than you'd think because colourspace("srgb") on a float image can give a float result, rather than forcing uint8.

For example:

$ vips colourspace k2.jpg x.v scrgb
$ vips colourspace x.v y.v srgb
$ vipsheader y.v
y.v: 1450x2048 uchar, 3 bands, srgb, jpegload

The float scrgb image becomes uint8 srgb, so precision is lost. But:

$ vips cast k2.jpg x.v double
$ vips colourspace x.v y.v srgb
$ vipsheader y.v
y.v: 1450x2048 double, 3 bands, srgb, jpegload

Now it stays float.

This seems unpredictable and is probably a bad idea. What do you think? Should colourspace conversion to srgb always output uint8, and conversion to rgb16 always output ushort?

There's a potential loss of precision, but if you want high precision srgb you should probably be using scrgb.

1. colourspace now always outputs the expected format for each colourspace, so sRGB is always uint8, XYZ is always float, and so on. I also sorted the colourspace table so it uses the same ordering everywhere, hopefully it's a bit easier to read now.
2. The PNG savers let you use the bitdepth arg to select rgb16 output, though I'm not sure how useful this is since it's just an 8-bit image shifted up.