-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Image info response must include all qualities beyond default #1809
Conversation
Meaning that info.json would always need to list |
I went back and forth. It's such an edge-case quality, and the fact that it's only required at level 2; I think this just simplifies things. I can add "or bitonal at compliance level 2" if you want, but my instinct was otherwise. |
Also, think about the developer experience. Having all of the qualities in one place (beyond |
I agree about the ergonomics, it's just a change. The inconsistency is if we leave bitonal in the compliance doc at level 2, then it's repeated ... which we don't do in other places. We could make it optional at level 2, forcing the publisher to put it in info.json |
I would be OK with making it optional, but I assume then we're needing TRC review? |
I think bitonal is fine to be Optional at level 2. As an art museum with lovely paintings, I have a level 2 image server but I really don't want bitonal available. It's just silly. |
Yes, I don't think I've ever heard a real world use case for bitonal |
One possible use case is harvesting a huge amount of text-bearing images, for OCR or machine learning purposes. Although I suspect most people would want to manage the conversion of the images into training set material themselves. |
Yes, and we've actually never found bitonal to work as well as grayscale for OCR. |
So, if we're in general agreement about making bitonal optional at all levels, can we merge before TRC approval, or does this need to sit open? |
Closes #1754