grayifcolor quality (low bandwidth use case)

[eroux]

Here's the use case of my institution:

• we have a lot of important users in low-bandwidth area (and areas with high bandwidth but low peering to the US)
• we have a lot of important bitonal, grayscale and color pictures
• we want to have a low-bandwidth mode in our image viewer. It would take the gray quality for color images (but not for bitonal, which would make images bigger)
• we want to apply that process to images that are viewed in our image viewer but are not served by our iiif server (so we can't use a extension that's specific to us, we need the method to be achievable without custom extensions)

I think there are 3 possible ways to achieve what we need, I'll expose them by descending order of interest:

1. grayifcolor quality

In this proposal, a new value for quality would be added: grayifcolor, which would have the following original -> output function:

• bitonal -> bitonal (like default does)
• gray -> gray (like default or gray do)
• color -> gray (like gray does)

This would allow a low bandwidth mode to work on all images. I will start by implementing that as an extraQuality or our servers, but as I said, it would be helpful to have this mode handled everywhere for low bandwidth areas.

2. originalquality indication

In this proposal, there would be an originalquality field in the image information, it would have 3 possible values: color, gray or bitonal, and it would allow a viewer to choose the gray quality when the original quality is color. I know that there's been some great care not to put anything like that in the spec until now, hence my first proposal and this being the second, despite being conceptually more simple.

3. HTTP header approach

This is kind of an unusual pattern, but I thought it could be wort mentionning: if there was a standard IIIF-mode http header, that could have different values including defaulttograyifcolor, this could drive the server into serving a gray quality when the url requests the default one on a color image.

[jpstroop]

If the "original" image is bitonal (there's no such thing as an original image in the semantics of the spec, but let's use it as shorthand here) then a server should not list gray in the qualities it makes available. So, unless I'm missing something, it seems like you should be able to implement this with the data that is already available. You would check if gray is an option, and if it is, request it, otherwise request bitonal.

That said, two additional points:

• I would be surprised if many servers know whether an image is bitonal vs grayscale, so I'm not sure how accurate this approach would be. I suspect most servers assume that if an image is not color then it must be grayscale. You might be just fine asking for gray all the time because...
• ... I think, without running tests, that bitonal images could be bigger than gray ones, at least in some cases, depending on the content of the image and how bitonal is implemented--e.g. if graphically busy material is made bitonal via a dithering algorithm then the image is not going to compress well and you'll wind up with a much larger image than a grayscale jpg would be.

[eroux]

Thanks for your answer! You're right, with version 3 I can just look if color and gray are in the extraQualities... thanks, I think that solves the issue!

About your additional points: I don't know of many other implementations, but our server knows if an image is bitonal and sets the default accordingly, this is what led to #1786 (for our bitonal pictures, png is significantly more efficient than jpg)