Add scan intent / WSD content type selection

[alvinhochun]

WSD: Add content type selection

Handle the WSD device settings element ContentTypesSupported, present its values as an option, and pass the selection to the scan job as ContentType.

The actual identifiers in code are made to match eSCL's "scan intent" setting, except for content type values exclusive to WSD. The setting is presented as airscan-scan-intent.

On some devices, this setting affects how colour is processed, and the default mode when not specified can result in inaccurate colours.

eSCL: Add scan intent selection

---

I reference this option from https://learn.microsoft.com/en-us/windows-hardware/drivers/image/contenttypevalue and https://learn.microsoft.com/en-us/windows-hardware/drivers/image/contenttype . The Canon PIXMA TR4570 I tested with supports "Text" and "Photo". Without setting the ContentType parameter, it seems to default to "Text".

Example scans

This is a cropped scan of a Mario Kart 8 Deluxe game cover, scanned right from the box with the plastic cover on. Text: Highlights appears to be oversaturated and shadows are missing details.  Photo: 

I hacked this together in half an afternoon, so I don't expect this to be mergeable as-is. This PR completely neglected eSCL as the TR4570 doesn't seem to support eSCL so I have no way to test it.

[alexpevzner]

Hi!

I like this PR. This is what I planned to implement for a long time, but always was too busy to do it.

The eSCL protocol has a very similar parameter, called "scan intent". The following intents are defined as mandatory:

• Document
• TextAndGraphic
• Photo
• Preview

And the following as optional:

• Object (scanning of 3d objects)
• BusinessCard

In most cases it has an obvious mapping to the "content types", defined by WSD.

You can freely download the eSCL specification from Mopria (https://mopria.org/mopria-escl-specification). Intents are documented at chapter 5.

I would really prefer to have a consistent implementation for the both eSCL and WSD worlds, and I'd prefer to use eSCL wording for that. "Content type", as for me, has a strong association with the MIME content type, while "scan intent" is free from these associations.

For testing of the eSCL scanning, you may use AirSane server (https://github.com/SimulPiscator/AirSane), sane-airscan known to work with it.

So I propose to implement scan intent support in the eSCL part of the driver as well, and then proceed with merge.

What do you think?

[alvinhochun]

Thanks for the info. I skimmed through the eSCL spec and saw that, aside from Intent eSCL does also have a ContentType setting, which has the following values listed in chapter 7:

• Photo
• Text
• TextAndPhoto
• LineArt
• Magazine
• Halftone
• Auto

The spec states that setting "Intent" may cause the scanner to modify other settings. including "ContentType". On a quick glance I didn't see a similar setting in WSD. It looks like to me that ContentType in eSCL is the better mapping for ContentType in WSD with more compatible setting values.

That said, I am not completely against mapping Intent for it instead. I don't know the protocol and don't have experience with real-world implementations, so your judgement is better than my guess.

For testing of the eSCL scanning, you may use AirSane server (https://github.com/SimulPiscator/AirSane), sane-airscan known to work with it.

So I propose to implement scan intent support in the eSCL part of the driver as well, and then proceed with merge.

To be honest I don't really want to spend too much time fiddling with eSCL since I don't need it, so it would be nice if someone can help implement that part. (wink wink)

[alexpevzner]

eSCL's ContentType seems to be rooted in the set of the possible values of the input-content-type attribute from the IPP faxout service specification (https://ftp.pwg.org/pub/pwg/candidates/cs-ippfaxout10-20140618-5100.15.pdf, 7.1.1.6). But there it exists for the very specific purpose to hint scanner when sending faxes, not for the general scanning use.

Although WSD's ContentTypeValue has no exact 1:1 correspondence with the eSCL Intent, they are actually very similar:

eSCL	WSD
Document	Text
TextAndGraphic	Mixed
Photo	Photo
Preview	-
-	Halftone

The only exceptions are Preview and Halftone. Preview mode doesn't seem to have WSD mapping at all, and they have added Halftone but forgot to add Lineart which is opposite to Halftone and at least for some hardware has a meaning how to perform 1-bit B&W scanning, as a super-contrast black and white or as halftone approximation, using density of black dots.

So I still believe, eSCL definition of Intent is more suitable for our purposes.

To be honest I don't really want to spend too much time fiddling with eSCL since I don't need it, so it would be nice if someone can help implement that part. (wink wink)

I will help and I will give you a very good credit in the sane-devel and printing-architecture mail lists :)

[alexpevzner]

I have added some code comments, but when these are resolved, probably one more iteration will be performed

[alvinhochun]

I've addressed the comments. I also added a completely untested scan intent handling in eSCL, so you can test it if you have a supported printer. Please feel free to amend the commit directly.

[alexpevzner]

I have pulled it into the temporary branch. Will tweak it a little bit there, then will merge into the master.

Thanks for your contribution. I will ask you later to retest with WSD.

[alexpevzner]

And when I will be writing announce of the next release, I want to credit you for this PR.

How to name it there? Just by GitHub nickname?

[alvinhochun]

Thanks. Feel free to ping me to test WSD if needed.

As for crediting, either the GitHub handle or the commit author name is fine.

[alexpevzner]

Hi!

Now in the master. Please, retest with WSD.

[alvinhochun]

Working fine in master, thanks!

[alexpevzner]

Hi!

Now in the 0.99.30 release. The promised credits :)

https://alioth-lists.debian.net/pipermail/sane-devel/2024-November/040032.html https://lore.kernel.org/printing-architecture/1793857b-57b7-44c2-a1cd-a123c828e61f@apevzner.com/T/#u