Community Wishlist Survey 2021/Multimedia and Commons/embedding crop, creating sub images, and possibly other file formats, while retaining reference to the original context

From Meta, a Wikimedia project coordination wiki

embedding crop, creating sub images, and possibly other file formats, while retaining reference to the original context

  • Problem: Using parts of Images (compiled documents such as newspapers, Government gazette or otherwise any big images (Tabula Peutingeriana) are such examples) is needed when pointing to an article for example, or even pointing to a typeface or an advertisement, and additional data can be associated with the part (article or other "cropping") that are not applicable to the whole document, or at least not directly; but would still "inherit" information of the "parent" document and preserve the context it came from/within. a crop of a picture of multiple people might also be a good example.
  • Who would benefit: The use case in GLAM related projects would be extremely useful, this would also move the use of commons as a much cleaner digital repository steps ahead, reducing fragmentation and enriching those commons. Without limiting the significance of the current usefulness to wikipedia, the use in other related projects in line with the foundations 2030 vision will be enormous.
  • Proposed solution: Similarly to notes, or even as an extension to it, areas of pages can be marked and data added to it, and a "cropped" view added, this might also be a separate document that is automatically generated (as it might get separate categories for example, annotations, referenced from wikidata, ...etc).
  • More comments: this will make the usability of those files and the value of their presence in any MediaWiki repository exponentially more. the concept of Using parts of files (namely images, and multi-page images (pdf, tiff)) is also to be considered in the audio/video context, important parts of speeches or clips from much longer videos and so on. an ideal solution would be more computational where changes to the parent document file would cascade down to those partial ones; but in the vast majority of the cases, the scale does not change and it will not be a problem unless BOTH the document is heavily "cropped and annotated" and the file radically changes (dimensions, duration) which all can be worked around by uploading it as a new file.
  • Phabricator tickets:
  • Proposer: Uwe a (talk) 15:40, 25 November 2020 (UTC)[reply]

Discussion

  • @Uwe a: the toolforge:croptool can crop images and PDFs and upload the smaller versions as new files. Is this sufficient for your use case? This doesn't work for audio or video of course, but those are generally edited with desktop software anyway. —SWilson (WMF) (talk) 05:17, 2 December 2020 (UTC)[reply]
    @SWilson (WMF): the thing is that "sub documents" are many and "fluid", and what they have in common is their common "Parent" document or compilation so to say, and the connection made to that parent document, more often than not, are "to be" inherited to documents with this "child" relation, apart from the obvious date and place, the publisher or author...etc, the relation between different parent documents, or indirect relation between them give valuable context to the sub-documents, on the other hand, the sub-documents themselves add to the parent document, by annotations for example. So basically creating different files/documents by merely cropping scatters those documents, also finding a better version of a certain document would allow better versions of the subdocuments that might be defined dynamically with coordinates or with timestamps in case we are including audio and video in this discussion.--Uwe a (talk) 20:20, 8 December 2020 (UTC)[reply]

Brilliant idea. Not sure how feasible it is at the moment, but it's worth serious development. It means designing a system that encourages the creation of many different takes on each item; collects all those takes under their common parent, without drowning the general view; and allows each take to act independently and form connections in other relevant contexts (categories relevant only to that specific version etc.). All this without looking cluttered or confusing. Commons already indicates "other versions" in file pages, and these can be easily created with toolforge:croptool. However, there's no way of knowing about the existence of "other versions" without checking the page, and when creating new versions there's always the fear that creating too many would over-flood the category. So basically I assume that one way to start would be adding a small icon that indicates how many versions a file has. Maybe even a preview of all versions on hover? In that case, the solution to "flooding" would simply be not to categorize new versions; they would all be accessible under the main file. If all versions are grouped together and displayed as one item, there's no reason not to create dozens of versions and display them all as a gallery on the original work. --Joalbertine (talk) 19:42, 19 December 2020 (UTC)[reply]

Voting