Comments (17)
Thanks @tomcrane
bitonal and grayscale are interesting cases, as it's possible to derive these from a colour image. So asking the server for bitonal when the original is colour is possible, but asking the server for colour when the original is bitonal should result in an error.
If a client can only work with or wants a colour image, and they specifically request that, then I think they should receive an error when the server is unable to respond with one.
I'm OK with having a full
parameter, in addition to default
, but I'm also not really sold on removing color
. If anything, having full
would give us the opportunity to make the interpretation of color
stricter.
from trc.
A few thoughts & questions:
The spec says:
A request for an image with an unsupported quality value should return a 400 (Bad Request) status code.
If a server cannot respond with a colour image, will this change have an undesired effect on the ability for a server to respond appropriately? Or will clients need to inspect the images they return to figure out the colourspace? Would there ever be a time when full
would return a 400?
Both bitonal
and gray
are explicit about what colourspace is being requested. color
is as well, but replacing it with full
would make this less explicit. We would have two parameters that can return a variable colour response (default
and full
), and two that return a specific colour response (gray
and bitonal
). This change would seem to have the counter-intuitive result of reducing support for colour images, rather than increasing it.
Imagining a scenario:
A client wishes to work with colour images only to feed into a machine-learning workflow built specifically on the need for colour images. If the client can't get a colour image, they expect to catch a 400 response and move on. Most services respond with a colour image with a request for full
, but one service provides a variable response for full
of either colour or bitonal. In this scenario it seems like the client has no mechanism to inspect the specific types of image, pre-download, and are forced to download every image and discard the ones they can't use.
Of less importance: full
is a quite loaded term in the Image API. By my count it can mean "All pixels in an image in all dimensions", "All pixels in an image at the largest unscaled size", and now "The most complete RGB values available for each pixel in an image".
https://example.com/{ident}/full/full/0/full.jpg
Is full
in danger of being overused? Or has it become the default value for "give me everything" in the Image API?
from trc.
Hi @ahankinson
A client wishes to work with colour images only
The issue with the current 2.1 spec is that it's not clear whether asking for color
every time (assuming the image service declares it available) means that any image returned for this quality will have at least one non-grayscale pixel in it. I don't think it does mean that, I think it means that the server won't transform the image to reduce it to bitonal or grayscale, and instead will return it with as much color information as it has (or wants to make) available. Which for some images, will mean a response that has no non-grayscale pixels in it, because there simply aren't any in the source.
So by renaming the quality color
to full
, it makes it clearer what is being promised and what is being asked for.
It does mean that your use case would require the client to inspect the image to see whether it actually does contain non-gray pixels, but I think that is also the case with 2.1, it's just not clear (what do Loris, IIPImage etc do?)
On the overloading of full
- I personally am OK with that, as it always make sense in context (vague echo of items
in Presentation 3). And the canonical request for the biggest image you can give me without me taking a look at the info.json is now in Image 3 /full/max/0/default.jpg
, so only one full
parameter. (The size
parameter no longer permits full
- it was deprecated in 2.1 and shown the door in 3).
Also, I think we have to be careful about the phrase "color space", and be clear that the spec isn't mandating anything about the technical implementation of your returned images, other than the color values of pixels. For discussion later, maybe:
Is it valid for a bitonal
request to return an image that only has black and white pixel values in it, but uses 32 bits per pixel to encode them?
I think the answer is yes.
If a client asks for .../bitonal.png
it's up to the server to be efficient in encoding it.
See also @beaudet's comment - IIIF/api#1839 (comment)
from trc.
I agree that full
is a bit loaded, but it does not dissuade me from including this. In fact, it is a sort of fixed vocab we're using to say (within the API) "give me the most you have". This may be size, spectrum, or crop and is not imprecise in its meaning.
from trc.
One question that may complexify the problem space, or provide a litmus test for these parameter values and how they should be interpreted and used: what should be the value for a colorized image? 'full' or something 'more than full'? (or should it should be treated as a different image?)
(I'm trying to understand how much 'full' means 'original' or something else)
from trc.
A client wishes to work with colour images only to feed into a machine-learning workflow built specifically on the need for colour images. If the client can't get a colour image, they expect to catch a 400 response and move on.
Using/retaining color
here may be useful, but I only imagine this is helpful when getting a 400. The concept of color is way to broad to rely on just the image path instead of other image metadata for cleaning a set for processing.
from trc.
I think I understand the problem this issue is trying to address, but keeping 'bitonal' and 'gray' in the spec, while removing 'color', will lead to further behaviour inconsistencies about how servers can be expected to respond.
While a variable response from 'default' can establish a sensible global response (that is, services can set a sensible default for their responses), 'full' will give services the ability to respond with variable image types and no real guarantee that what the client will receive will be what is expected. For example:
- Does 'full' mean that a client can request the lossless version?
- Does 'full' mean that the server can respond with the 16-bit version of the image, rather than the 8-bit? Or with RGBA instead of RGB?
I think if the goal of this change is to clarify the behaviours of image servers and make it consistent, then we need to further clarify what the expected behaviours are. Without a definition of what 'full' actually means, I'm not sure that this change has that effect.
from trc.
It seems to me we could use any of full
, native
, max
and such and they all are kind of overloaded in meaning. If we interpret the quality labels as request for "best effort" match, as in @ahankinson's example (during the call) of a greyscale
version delivered from a bitonal
source image (or color
from greyscale
or bitonal
), the current color
might just work, that is, we don't seem to gain much from using full
instead.
from trc.
I think there are two overlapping issues being discussed here. One is about commands, the quality
param advertising what transformations the server will allow you to request, and then in making the request using a valid supported quality instruction, the client telling the image server to make that transformation.
The other is about information: does there exist in this image at least one pixel whose colour value is not R==G==B?
Which is not a supported command, but an additional piece of information, like an extremely minimal palette service. Something an image server could support in some other way, to be defined.
I agree with @ahankinson's use case, it's a valid scenario, and the proposed spec change clears up the ambiguity about whether it's possible to meet that use case by inspecting supported qualities in the info.json (it isn't).
For the use case, information about the range of values present in the image's palette would then allow the client to request full
quality for one image, or skip another image because it isn't colourful and therefore not suited to the machine learning task. But that info doesn't belong in the list of supported quality "operations", I think.
On a different note the proposed spec change includes this:
The quality parameter does not determine the color space or impose other technical constraints on the returned image, other than the color values of the pixels it contains. It is valid for a server to return an image with gray or only black and white pixels in response to a full quality request, if that is all that is available.
The "color values of the pixels it contains" could be clarified some more. What it's trying to say is, regardless of the bits per pixel, RGBa or whatever nature of the returned image:
bitonal
=> give me an image in which only black and white can be seengray
=> give me an image in which only shades of grey can be seenfull
=> give me an image with as many shades/colours as you can
from trc.
As a point of order: Is this the right place for the conversation? I'm happy to continue it, but I seem to remember there being an agreement that TRC issues aren't the place to hash things out, and should be restricted to voting and minor clarifications. @hadro ? @glenrobson ?
from trc.
I have no strong feelings about this particular change, but a few notes below.
Your use case would require the client to inspect the image to see whether it actually does contain non-gray pixels, but I think that is also the case with 2.1, it's just not clear (what do Loris, IIPImage etc do?)
Loris makes a half-hearted attempt at checking if color
is an appropriate quality..
When it receives a request, it checks the colour model of the original image (RGB, CMYK, LA, etc.). If the colour model supports non-grey pixels, it allows the color
quality, but it doesn’t check to see if the image actually contains non-grey pixels.
If you try to request an image in a quality that the colour profile doesn’t support, Loris returns a 400 error. Examples:
https://iiif.wellcomecollection.org/image/M0000701.jpg/info.json (default, gray, bitonal)
https://iiif.wellcomecollection.org/image/M0000701.jpg/full/full/0/color.jpg
I don’t have details to hand, but Wellcome’s use case could make an argument in both directions (or for having both parameters, which is no decision at all).
Some of Wellcome’s images have embedded colour profiles that popular browsers ignore, so in Loris we convert every image to sRGB before sending it as color
or default
. You’re not getting the original colour palette because most of the time that’s probably not what you actually want. We did that for a while, and got complaints that a bunch of images looked wrong (they did, it was yucky).
In favour of full
: AFAIK, there’s no way to get the image with the original colour profile. You have to email somebody and ask for the original file.
In favour of color
: The term “full” carries a suggestion that you’re getting the original, unmodified colours, which in our case would be the not-sRGB, icky-looking image. How does somebody ask for a colour image that’s been tweaked to look right in their browser?
One subtlety in “does this image contain at least one non-grey pixel” is that it can vary on a per-transformation basis. If I have a massive image that’s entirely grey except one red pixel, eventually resizing will cause that red pixel to be lost. You could certainly work that out on every request, but I don’t think IIIF has a way to convey information about specific transformations? The info.json
is transformation-agnostic.
e.g. You can’t say “quality color
is supported if dimensions are greater than 800x600, but unsupported otherwise”
from trc.
@ahankinson Sorry for my delay, but here's my take: While these issues aren’t exactly the preferred place for lengthy discussion, as TRC process has evolved we've seen it a fair bit, and almost always helpfully. Here these seem like comments and clarifications useful to deciding the issue, and so while we won’t be changing the item being voted on the discussion may inform future issue creation
from trc.
I appreciate the perspectives voiced in this discussion as well as the issue that is being addressed. However I think there is potential for confusion in avoiding the use of plain language. One expects the term 'color' to be present when considering image attributes--especially if the plain language terms 'bitonal' and 'gray' are used in the same context. In the context of a greyscale image, would not 'full' also refer to the full spectrum of non-colour pixels to be returned? It strikes me that the definition 'The image is returned with as much color information as available' inherently implies that a colour images is requested; if so, then why not say so with 'color' instead of the ambiguous term 'full'?
from trc.
@hadro ok, thanks!
from trc.
I agree that using full
in multiple places is not an issue; it actually makes things consistent. "Full" can be interpreted as "unmodified": for region
, no cropping; for quality
, no color transformation; etc.
I'm also in favor of leaving color
in because a client may require, for consistency, to process a batch of images as RGB, regardless of what the source color model is—e.g. to perform color analysis.
from trc.
Issue 25 (Quality in Image API v3: Replace color
with full
)
+1: 14 [azaroth42 beaudet cubap emulatingkat irv jpstroop markpatton mcwhitaker mikeapp mixterj rentonsa scossu tomcrane zimeon]
0: 11 [aisaac andrewgunther dismorfo gigamorph jbhoward-dublin jtweed julsraemy regisrob rsinghal sredick tpendragon]
-1: 2 [ahankinson joshuago78]
Result: 14 / 27 = 0.52
No super majority, issue is referred to ex officio for decision
from trc.
The ex officio members of the TRC have decided to reject this proposal for now, pending further research and discussion (see TRC process)
from trc.
Related Issues (20)
- Georeference Extension HOT 9
- Recipe #0068: A basic newspaper - rewrite HOT 7
- Recipe #0306: Linking external Annotations targeting a Canvas to a Manifest HOT 8
- IIIF Authorization Flow API 2.0 HOT 6
- Recipe #318: Locating an Item in Place and Time HOT 3
- Recipe #317: Image in annotations HOT 6
- Recipe #261: Annotation with a Non-Rectangular Polygon (update) HOT 4
- Recipe #0135: Annotating a specific point of an image HOT 2
- Proposal for adding 'timed-text' in the Text Granularity Extension HOT 4
- Migration of Selectors from Annex to Registry HOT 1
- Annotation Motivations TSG Charter HOT 2
- Recipe #283: Missing images in a sequence HOT 9
- Re-charter of the Authorization Flow TSG HOT 2
- Recipe #22: Redirecting from one Canvas to another resource (Hotspot linking) HOT 5
- Recipe #32: Simple Collection HOT 3
- Recipe #434: Multiple Choice of Audio Formats in a Single View (Canvas) HOT 8
- Recipe #466: Sharing a link to open a Manifest in a specific viewer. HOT 12
- Recipe #346: Annotating in Multiple Languages HOT 9
- Recipe #485 : Open a specific region of a canvas in a viewer
- Recipe #489 : Teaching with a Multimedia Canvas
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from trc.