Enhancement: Clean up of Thumbnail workflow

[kalisp]

Is there an existing issue for this?

• I have searched the existing issues.

Please describe the feature you have in mind and explain what the current shortcomings are?

Current workflow for creating thumbnails (visible in Loader and Server UI) is a bit messy. (We sometimes call event review sent to Ftrack as 'Thumbnail' that doesn't help either).

Currently each DCC might generate thumbnail representation separately, there are 2 generic thumbnail extractors (extract_thumbnail.py, extract_thumbnail_from_source.py) which results in similar, but not same functionality (extract_thumbnail.py had updates recently to support color spacing, rest is in various state.)

Integration of Thumbnails is messy too. We most likely don't want to integrate 'thumbnail' representation as it is unnecessary polluting DB and Loader, but integrate_thumbnail_ayon.py depends on that representation to be published.

Other sources of thumbnail paths could be used in that integrator:
- context.data.get("thumbnailPath")
(instance must have "published_representations" for lower mentioned options)
- instance.data.get("thumbnailSource")
- instance.data.get("thumbnailPath")
- representation with 'thumbnail' name from "published_representations"
(All these fields are undocumented and for new developer totally unknown.)

How would you imagine the implementation of the feature?

• There should be new page in dev documentation describing what thumbnails are for. (And reviews too.)
• It should be described what options a developer has to pass thubnail to Ayon (and possibly Ftrack/Kitsu etc.)
• Integrators should be merged (and missing functionality as output resolution added - ExtractThumbnailFromSource should allow to set resolution #4091)
  • it seems that ExtractThumbnail has it now via _get_resolution_arg, so it means that ExtractThumbnailFromSource might be superflucous, it is actually been used only in Webpublisher and TrayPublisher where it might be possible to eradicate it
• All extractors of thumbnails should be slowly removed from separate DCC.
• One field on instance should be selected to highlight which generated file should be used for thumbnail creation. That and only that field should be set in DCC after reviewable files are generated.
• Integration of thumbnail should be revised if there is actually valid use case to create such representations in DB
• if it still valid, 'thumbnail' representation and its 'integrability' should be created in single extractor
• preintegrate_thumbnail_representation.py should be removed (this currently could be used as single point to control 'integrability' of thumbnails based on profiles - as creation of 'thumbnail' representation is disparate in each DCC.

Are there any labels you wish to add?

• I have added the relevant labels to the enhancement request.

Describe alternatives you've considered:

No response

Additional context:

No response

[cuID:OP-7603]