Hello @AntiCompositeNumber.
I am working on the BE solution to make it possible to configure the DPI option for PDF files. It is the sub-ticket T256959 of this one.
As I understood correctly you proposed that we have these configuration options already put in the structured data tab on the file page. And then thumbor will take possible configuration options and use them to generate the file on a case-by-case basis.
Did I get your point? Could you please share your ideas with me?

I worked within the Per-file control ticket. I researched the following subtasks: PNG thumbnail..., TIF less focused..., Allow PDF's to be rendered... I found several useful comments and links to the related Phab tickets.
There is an idea to create a new URL scheme for getting thumbnails. From my point of view, it is not a blocker for us to add an opportunity to configure creating thumbnails, but the status of this ticket should be controlled since a new URL scheme can influence the logic of per-file control for thumbnail generation parameters based on the plan below. This comment describes a valuable approach of using structured data and checking the header which Thumbor will process and decide what to do with one or another user config parameter.
Here is the short plan which can help to add per-file control for some thumbnail generation parameters:

1. The community should define a standard for how file configs information is stored. As mentioned by @Tgr it could be a new property that needs to be proposed on Wikidata or could use some existing property.
2. We also need a Mediawiki side logic which will detect when some config parameter of a file is changed in structured data, and push the info to a Swift header.
3. This information would have to be stored in Swift alongside the original object as a special header, as access to the database from the thumbnailing layer is undesirable for security reasons.
4. It should be also possible to configure only per file not per thumbnail because it helps to do this without inflating storage needs. There needs to be a mechanism to keep those particular flags in sync in Swift. Switching the flag on and off would need to purge all thumbnails. Once one of the flags exists in Swift, it's trivial for Thumbor to generate thumbnails accordingly.
5. And at the end, Thumbor should check the header and apply a config parameter appropriately.

It seems like a lot of work should be done there.

Hello @Tgr @hnowlan. Could you please share your thoughts about this plan and its validity?

I can see two approaches:

• encode the information in the thumbnail URL (similar to how e.g. the thumnail URL of a low-quality JPG would be something like qlow-123px-Example.jpg)
• encode the information in Swift headers

Encoding in the URL has the benefit that

• it works in vanilla MediaWiki (which stores thumbnails in a file so it cannot store headers) and thus works on third-party installations and is easier for Wikimedia developers to work with locally;
• there is no need to invalidate old thumbails;
• there is no state stored outside MediaWiki that could get out of sync and cause hard-to-debug errors;
• the code interfaces for it are well-established;
• and it also naturally enables overriding these parameters on a per-thumbnail basis (which I guess you can see as a good or bad thing depending on how much you worry about it getting misused) and providing different settings for e.g. in-article thumbnails vs. MediaViewer vs. download.

Using Swift has the benefit that you don't need to worry about old not-relevant-anymore thumbnails littering Swift and possibly requiring a custom cleanup script. Also, changing image properties could have an instantaneous effect, if you go the extra effort and purge the old thumbnails from Varnish; if not than the URL-based approach will be the more testable one (as you can change file properties and then purge some HTML page to update it to the new URLs, which is something editors already know how to do).
On the whole, I'd go with URLs.

If you go with URLs, it would look something like this:

• Provide an interface in MediaWiki core for structured image metadata, as core cannot depend on the WikibaseMediaInfo extension. It also needs to be able to access Commons structured data on other wikis which use a Commons file (ie. the ForeignApiRepo and ForeignDbRepo classes no to handle fetching the data from Commons). A similar example is how the GetExtendedMetadata hook was created so core does not have to depend on the CommonsMetadata extension. This is not a small task but very valuable beyond this specific use case - e.g. it would allow replacing CommonsMetadata (which is an ugly pre-Wikibase hack where Commons templates output metadata as HTML and the file handling logic extracts it), and it's also needed for T213585: Images (on articles, on file/category pages, and in the media viewer) should default to use their structured data alt text when available
• In JpegHandler & co modify the makeParamString() method to access this data and add it to the URL, and modify normaliseParams(), validateParam() and parseParamString() to expect this parameter. Preferably make the default implementation use the new parameter (e.g. have JpegHandler::transformImageMagick() pass the appropriate option to ImageMagick) although this is not strictly required.
• Optionally define a magic word for the parameter and add it to getParamMap() - this will allow overriding the value in wikitext on a per-thumbnail basis.
• Update Thumbor to do the same string decoding as makeParamString() and modify the output appropriately.

If you go with headers, your plan sounds right, with the caveat that there might be many thumbnails for a given file (maybe unlikely but certainly possible) so purging them might need to be an async operation (maybe? I have no idea how fast it is to do mass deletions in Swift; in any case this is also needed for image deletion or reupload so the mechanism probably already exists).
I once tried to add Swift file headers based on some MediaWiki property (but did not go through with it in the end), maybe that's useful although the code is pretty old now: T167400: Disable serving unpatrolled new files to Wikipedia Zero users

T66214: Define an official thumb API would be nice but it's an entirely orthogonal problem.

The ticket was moved to Blocked on the Thumbor Migration board since the ticket requires decisions from the WMF management/engineering staff related to MediaWiki core, Structured Data, etc.

T325948: Provide an API for accessing alt text (and possibly other structured data) stored with MediaWiki file uploads and T325949: Allow access to (some) structured image metadata across wikis is my vague idea of how to access Commons structured file metadata during thumbnail rendering. (The use case I'm personally interested in is alt text, but as I said above I think it is a fairly generic problem.)

In T253280#8500398, @Tgr wrote:

T325948: Provide an API for accessing alt text (and possibly other structured data) stored with MediaWiki file uploads and T325949: Allow access to (some) structured image metadata across wikis is my vague idea of how to access Commons structured file metadata during thumbnail rendering. (The use case I'm personally interested in is alt text, but as I said above I think it is a fairly generic problem.)

Hello @Tgr
Could you please clarify if solving these tickets will help to have a way for Wikisources to read for instance the future DPI value?
This concern was mentioned in the subtask of this ticket.

There is not currently a way for other wikis to retrieve structured data (statements/captions) from Commons other than calling the Wikibase action APIs on commons.wikimedia.org.

Yes, T325948: Provide an API for accessing alt text (and possibly other structured data) stored with MediaWiki file uploads & T325949: Allow access to (some) structured image metadata across wikis describe specific implementations similar to what'd be needed for T256959: Allow PDF's to be rendered at higher (or user specified DPI). Solving any one of them would get you at least most of the way there for the others.

They kind of boil down to:

• Create some point of access for files' structured data in core; this thing invokes a hook
• In another extension that is configured in a way that it's able to access that data on Commons, subscribe to that hook and fill it with the relevant data
  • The obvious place is Extension:WikibaseMediaInfo, but that one is only enabled on Commons
    • WikibaseMediaInfo would have to be modified to run be able to run in some sort of client-only mode where it doesn't force its UI on NS_FILE pages and whatever else it may do that isn't desirable on other wikis

Once the work to make structured data from Commons available on other wikis has been completed, the heavy lifting is probably done.
From there on, the difference between those tasks is essentially picking data from another property.

@Tgr does that match your view?

Sidenote: all of these tasks thus far describe implementing some form of API that would allow any wiki to access a Commons file's structured data from code, but it would also unlock this data from content/wikitext in other wikis in the form of Lua modules.

In T253280#8516612, @matthiasmullie wrote:

@Tgr does that match your view?

In general, yes. Specifically for the DPI task, I'm not sure if that's something that needs to be configured per-file (vs. just using different thumbnailing options in ProofreadPage). Can't the software just guess the right DPI?
Another alternative, mentioned in T256959, is to take the value from some ProofreadPage-managed metadata, which I think is conceptually the equivalent of having per-thumbnail parameters. Whether per-file or per-thumnail is better depends on the use case (does the value depend on something file-specific like the file format or the color scheme, or something context-specific like the size in which the image is displayed?), not sure which is the better in this case.

If it does need to be configured per-file though, I'd do it the way you said. And yes, that would solve a fairly generic problem with lots of potential use cases.