RGB colour space in Vips

[alonit]

Hi,

I'm using Vips 8.4 C API on Windows 64bit OS.

My application scans tissues with a color camera and save all 3 channels (R,G,B) under single .tif file using OpenCV imwrite method, so that the output files can be 8bit per channel or 16bit per channel image files (depends on application configuration).

Under this application Vips is reading those files using vips_image_new_from_file and process them to output some pyramids.

The VipsImage objects:

1. 8x3bit file:
   

Type = VIPS_INTERPRETATION_sRGB
BandFormat = UCHAR

2. 16x3bit file:
   

Type = VIPS_INTERPRETATION_RGB16
BandFormat = USHORT

Using ImageMagic identify command line tool to get the properties of those images, I get:

1. 8x3bit file:
   

Color space is sRGB as reported also by Vips.

2. 16x3bit file:
   

Image magic identify thew color space as sRGB and not as reported by Vips (Vips report on RGB16 color space).

Is there an inconsistency in Vips color space typing? I think that vips should differentiate between 8bit sRGB and 16bit sRGB using the BandFormat (UCHAR or USHORT) and report the underlying color space which appears to be common for those cases (sRGB for both 8bit and 16bit).

By the way I've found a documentation on libvips color interpretation (https://fossies.org/linux/vips/doc/html/libvips-colour.html) which says:

VIPS_INTERPRETATION_sRGB -- the standard sRGB colourspace, see: wikipedia sRGB.

This uses three 8-bit values for each of RGB.

VIPS_INTERPRETATION_RGB16 is the same, but using three 16-bit values for RGB.

This explanation says that 16bit sRGB images get VIPS_INTERPRETATION_RGB16 and 8bit sRGB images get VIPS_INTERPRETATION_sRGB. I think Vips should separate the bit's (8bit, 16bit with UCAHR and USHORT accordingly) from the color space (sRGB in this case)

So When the scanner report that each image is sRGB color space, Vips report on different color space for the 16x3bit files although they are actually also sRGB with 16bit per pixel - This insert inconsistencyas our system expect sRGB for the 16bit images and get reported by vips as RGB16.

Thank in advanced.

[jcupitt]

Hi @alonit,

This is actually deliberate -- it's very useful to have the interpretation of pixels separate from their numeric type.

VIPS_INTERPRETATION_sRGB means black to white is 0 to 255, luminance is encoded with gamma 2.4 plus a straight line section near zero, and colour with the 709 primaries. It doesn't mean it must be stored as 8-bit data, though that is convenient.

For example, suppose you sum three 8-bit sRGB images. Now you need to store the values in a ushort image or you'll get clipping, but really the pixels still mean sRGB as defined above. If you now divide by three, you'll get proper sRGB back again, and you'll keep the full range of values.

Systems like ImageMagick which link the numeric type and the pixel interpretation find this very difficult. They need to implement a special image average operation, because if you just sum and divide, many pixel values will be truncated. Fortunately, the new ImageMagick 7 has changed tack here. They now use double as the only numeric type and keep interpretation as a separate field, so they have moved much closer to libvips (though sill not as good, in my opinion, of course).

libvips has five sRGB interpretations, in fact. They are:

• MONO (or B_W) is just like sRGB, but only the first band is used, and it's the weighted sum of R, G and B.
• GREY16 is just like RGB16, but again, one band and weighted.
• scRGB uses the sRGB primaries, but linear encoding and 0 - 1 for black to white. Formats like HDR and EXR use this. It's the type of sRGB used by GEGL as well.
• RGB16 is sRGB, but linear encoding and 0 - 65535 for black to white. You can't just change the numeric type and shift.
• ... and sRGB is the 0 - 255 gamma one.

For your scanner, I think you will need to treat the 16-bit images differently anyway to account for the gamma difference.

[alonit]

Thanks for this explanation

[jcupitt]

OK, I'll close.