Quality in Image API v3: Replace color with full

[tomcrane]

Following the discussion that developed on IIIF/trc#19, the editors propose that potential ambiguity about whether a server should offer color, and what it should do with requests for color, could be resolved by using the term full to avoid the implication that a color quality image should contain non-gray-shade pixels, or use particular color encodings.

Therefore (wording provisional):

• bitonal: The image returned is bitonal, where each pixel is either black or white.
• gray: The image is returned in grayscale, where each pixel is black, white or any shade of gray in between.
• full: The image is returned with as much color information as available.
• default: The image is returned using the server’s default quality (e.g. full, gray or bitonal) for the image.

Observation:
A full image may contain only gray shades, if that is all that is available: it is legitimate for the server to list full in this case even if the response would be identical to that for gray.

[beaudet]

With respect to bitonal and gray - is this a perceptual rendering only or does it imply the use of one of a limited number of color spaces in the response and / or a limitation on color depth? e.g. with gray, only one channel of color data; with bitonal, 1 bit per pixel only. I have always interpreted it as a perceptual intent rather than an intention to produce images with particular constraints in how color information is encoded in the image.

[jpstroop]

I like where this is heading. Reading as explained above, I wonder if we need full at all, i.e. is it ok to assume that default is always the version with the most color information available?

[tomcrane]

I have always interpreted it as a perceptual intent

Yes, I think the avoidance of color makes this easier to comply with without being unnecessarily prescriptive about implementation.

It's a good idea to return bitonal or gray with an appropriate and optimised color space, but it's not an error if you don't.

Here's another use case, going the other way. Inspired by @ahankinson's comment - IIIF/trc#19 (comment) - are they scores, maybe?

Let's assume they are scores, and the master image is bitonal. Let's also assume that they are really high resolution bitonal images.

If the server offers gray as well as bitonal for these, then I could get some really nice looking results if more shades are introduced through anti-aliasing when delivering an image derivative with reduced dimensions but more bits-per-pixel. It would not be an error for the server to do this. This works nicely for engravings etc, especially for thumbnails.

[tomcrane]

@jpstroop -

@mikeapp had a use case where default could be grayscale even though full is available - photo library, b/w images mounted on card of varying colours. The colour info in these images is important, for some audiences, but you might wish to normalise the appearance to grayscale for general use.

[azaroth42]

@jpstroop that was my initial reaction as well, but default allows for the case where the server chooses a preferred quality that is not the most colors, per @mikeapp's use case. There's no real cost that I can see to leaving both full and default as the processing is very easy in the general case, and allows for the interesting case that would otherwise not be possible.

[jpstroop]

per @mikeapp's use case.

OK...

[azaroth42]

Editors propose to take to TRC

[zimeon]

This proposal to change color -> full IIIF/trc#25 did not get super majority support. Ex officio members decided to reject pending further research and discussion. PR implementing the change #1842 closed

[zimeon]

We decided not to do this is v3.0. Not worth consideration until/unless there is another major release. Closing