Page MenuHomePhabricator

TIF less focused than JPG equivalent (due to conditional sharpening applied to JPEGs and not TIFFS)
Open, Stalled, MediumPublic

Description

Author: M8R-udfkkf

Description:
It appears that TIFs are slightly less focused (more blurred) than their JPG equivalent.

My bot uploaded these two files:

https://commons.wikimedia.org/wiki/File:071017_NRCS_Sterling_003_-_Ohio_%28717110%29%28NRCS_Photo_Gallery%29.tif

https://commons.wikimedia.org/wiki/File:071017_NRCS_Sterling_003_-_Ohio_%28717110%29%28NRCS_Photo_Gallery%29.jpg

The JPG one was converted from the tif with imagemagick (python):
call(['convert', 'currentfile.tif','-quality', '97', 'currentfile.jpg'])

Although the jpg is 97% of the tif quality, it appears to have better quality.

Am I mistaken or is there a reason for this?


Version: 1.21.x
Severity: normal

Details

Reference
bz45212

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:13 AM
bzimport set Reference to bz45212.
bzimport added a subscriber: Unknown Object (MLST).

In the thumbnails of those images?

(In reply to comment #1)

In the thumbnails of those images?

And do you mean the png or the jpg thumbnail of the tiff (we support both. Jpg is the default).

Its possible that different sharpening is applied to tiffs than to jpgs (not sure off the top of my head. I would be surprised though). Its also possible that different scaling algorithms may be used for the different formats or something like that.

mcdevitd wrote:

*** Bug 18014 has been marked as a duplicate of this bug. ***

mcdevitd wrote:

This is also true of .jpg thumbnails of PNG uploads, I assume for the same reason (see duplicate bug report).

(In reply to Dominic from comment #5)

This is also true of .jpg thumbnails of PNG uploads, I assume for the same
reason (see duplicate bug report).

We dont do jpg thumbs of png files (png files get png thumbs), but yes, pngs are not sharpened. Only jpgs get sharpened.

I believe comment 2 is incorrect...

mcdevitd wrote:

(In reply to Bawolff (Brian Wolff) from comment #6)

(In reply to Dominic from comment #5)

This is also true of .jpg thumbnails of PNG uploads, I assume for the same
reason (see duplicate bug report).

We dont do jpg thumbs of png files (png files get png thumbs), but yes, pngs
are not sharpened. Only jpgs get sharpened.

Yeah, I misspoke. I should have said JPG versions of PNGs.

The current tiff thumbnails are of such poor quality that Commons users are uploading duplicate jpegs. This is a lot of extra work and puts and extra strain on the Commons community because everything needs to be done twice. Raising the priority of this bug.

I would like to fix this bug at the same time as bug 52045, since we're be changing the rendering config with that bug, so might as well do it all at once.

This is due to conditional sharpening (depends on the ratio of the resize), which is applied to JPEGs and not TIFFS.

The history there is that sharpening is harmful for diagrams but helpful for photographs. Since the Commons community is good at making sure that diagrams aren't uploaded as JPGs, it's safe to apply sharpening to all JPGs, which is why it was introduced. It isn't safe to apply to TIFFs, however, since people upload scans of maps, diagrams, etc. as TIFFs, which would suffer from this sharpening in terms of quality. Basically, applying the same logic to TIFFs would be beneficial for some TIFFs, harmful to others.

There is no good solution here in the status quo, because the thumbnailing pipeline isn't told which TIFF is a photograph which isn't. Maybe this could be possible in the future with structured data and user tagging. When Mediawiki can know semantically that a given image is a photograph, it can ask the thumbnailing backend to conditionally sharpen the thumbnails, otherwise to skip that step.

Another potential solution would be to use machine learning/OpenCL detection to figure out what is a photograph and what isn't. However our thumbnailing pipeline is constrained by the fact that thumbnails are rendered on demand, and it would be quite taxing on performance to do this check on demand, even if we store the result after the first thumbnail. I think it would be better for the determination to come from the wiki anyway, as it would let users override the behavior on a case by case basis.

This would also depend on an evolution of the thumbnail parameters, as the conditional sharpening is currently hardcoded and not part of the thumbnail URL. As such, we might want to wait for the project to have a new URL scheme: T66214: Define an official thumb API

Aklapper renamed this task from TIFs appear less focused than JPG equivalent to TIF less focused than JPG equivalent (due to conditional sharpening applied to JPEGs and not TIFFS).Mar 29 2019, 5:38 PM
Aklapper lowered the priority of this task from Medium to Low.
Aklapper removed a subscriber: wikibugs-l-list.
VirginiaPoundstone raised the priority of this task from Low to Medium.Oct 25 2022, 1:51 PM

Change 863399 had a related patch set uploaded (by Vlad.shapik; author: Vlad.shapik):

[operations/software/thumbor-plugins@master] WP: Add ability to specify filters such as sharpening and etc. for TIFF format

https://gerrit.wikimedia.org/r/863399

Change 863399 had a related patch set uploaded (by Vlad.shapik; author: Vlad.shapik):

[operations/software/thumbor-plugins@master] WP: Add ability to specify filters such as sharpening and etc. for TIFF format

https://gerrit.wikimedia.org/r/863399

If there will be needed to add default filters for the TIFF format.
DEFAULT_FILTERS_TIFF config parameter helps to do it fast.

Added a request to create a property, that specifies if sharpness should be used, as per the discussions of this task and the sister tasks of this task. See https://wikidata.org/wiki/Wikidata:Property_proposal/thumbnail_sharpness. Chose an item type property given the available property types, https://www.wikidata.org/wiki/Special:ListDatatypes. The property will not allow other inputs than yes (Q6452715) and no (Q1814990). The logic here is if "sharpness = Q6452715" then sharpness should be applied. There will be at least 1 to 2 weeks until the property gets created.

Looks like the boolean [[ https://www.wikidata.org/wiki/Wikidata:Property_proposal/thumbnail_sharpness | mimic property proposal ]]is not getting support.

When Mediawiki can know semantically that a given image is a photograph, it can ask the thumbnailing backend to conditionally sharpen the thumbnails, otherwise to skip that step.

Are TIF files currently tagged using structured data to identify their medium? If they are, instead of creating the boolean property, should we set the conditional sharpening for TIFs that are photographs (but not diagrams, drawings, maps, etc) as automatic like we do for JPGs?

What level of sharpening should be applied? Same was the sharpening on JPGs?

Looks like the boolean [[ https://www.wikidata.org/wiki/Wikidata:Property_proposal/thumbnail_sharpness | mimic property proposal ]]is not getting support.

Does not matter that much. The main point was to figure out if the community wanted to store this in structured data and how it would be done. The result was that it would be in an existing property.

When Mediawiki can know semantically that a given image is a photograph, it can ask the thumbnailing backend to conditionally sharpen the thumbnails, otherwise to skip that step.

Are TIF files currently tagged using structured data to identify their medium? If they are, instead of creating the boolean property, should we set the conditional sharpening for TIFs that are photographs (but not diagrams, drawings, maps, etc) as automatic like we do for JPGs?

What level of sharpening should be applied? Same was the sharpening on JPGs?

No, TIF files are not currently using structured data to identify their medium. https://commons.wikimedia.org/wiki/Commons:Structured_data/Properties_table lists the current properties in use, it does list a property that is supposed to be created for that, but it does not exist yet.

The plan is to use the same sharpening as with JPGs, yes, 'conditional_sharpen(0.0,0.8,1.0,0.0,0.85)'.

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.

Atieno updated Other Assignee, added: Hokwelum.
FJoseph-WMF updated Other Assignee, removed: Hokwelum.
FJoseph-WMF added a subscriber: Atieno.