Restrictions on screenshots and videos in snap listings

Regarding GNOME Software - we would implement this using a Web View for the videos. Based on previous discussions this is probably not going to be accepted upstream, so would have to be carried as a distro patch (and the videos wouldn’t show in other distros). The work is non-trivial but do-able.

1 Like

Thanks for writing that up @pheurton.

A couple of comments:

  • This should also mention that we support SVG for icons, but they are currently converted into PNGs when they are uploaded by the developer.
  • JPG/JPEG is the same format.
  • Would be good to see some kind of frame rate constraints for the Animated GIFs as well.

Thanks for the notes @jdahlin. Updated content based on our conversation over IRC:

Video

We will not host video media but will allow publishers to include links to media video from popular platforms in their snaps. Some platforms we discussed to introduce: asciinema.org (specifically for terminal-based snaps), youtube.com, vimeo.com (already allowed in the old dashboard).

Images

Right now we are only allowing users to upload image media related to Snaps but in the future, there will be public publisher pages which will allow users the ability to include their branding and perhaps some featured banner to be used in these pages.

There are 2 additional work streams that will help publishers to contribute with acceptable and great media types to the platform: be able to preview a Snap listing page and guidelines and rules for media types (i.e. safe zones for featured banners, guidance on what to showcase in screenshots, avoiding text as much as possible in screenshots…). These will be worked out once we have an agreed direction.

General details

  • Accepted media formats: PNG, Animated GIFs, JPG / JPEG, SVG (currently converts to PNGs)
  • Maximum overall file size: 2 Mb

Support for SVG for icons

Upload of SVG images is currently supported for icons which currently convert to PNG format after the publisher uploads them. We have discussed future native SVG support as the majority of clients could render and support this file format.

Limitations for animated GIFs

  • Minimum frames per second: 1 fps
  • Maximum frame per second: 30 fps
  • Maximum length: 20 seconds

Media images related to Snaps

General Number Required Allowed aspect ratio Min size Max size Recommended size Max. file size
{snap-name}-icon 1 :heavy_check_mark: 1:1 40x40 512x512 256x256 256 kb
{snap-name}-featured 1 2:1 640x320 3840x1920 1920x960 2 Mb
{snap-name}-shot-# Up to 4 :heavy_check_mark: 1:1, 4:3, 16:9 480x480 3840x2160 1920x1080 2 Mb

Description of items from the table above:

  • Snap icon: This image will be shown in search results, store pages and its details page.
  • Snap featured: Storefronts might decide to promote a given snap and this media type will allow them to feature a Snap
  • Snap shots: Any image/s from a snap that will be displayed on the given public listing page

Media images related to Publishers

NOTE: We are not currently working on public publisher pages but it is something that will be worth considering in this thread.

General Number Required Allowed aspect ratio Min size Max size Recommended size Max. file size
{publisher-name}-icon 1 :heavy_check_mark: 1:1 40x40 400x400 256x256 256 Kb
{publisher-name}-banner 1 2:1 640x480 3840x1920 1920x1080 2 Mb

Description of items from the table above:

  • Publisher icon: Refers to a brand image to be displayed in Snap details pages and (future) public pages from publishers listing additional information

  • Publisher banner: To be used in (future) public publisher pages in case they will be featured somehow in any of the storefronts or used as a background image for their (future) public pages

2 Likes

For screenshots, these are the allowed aspect ratios. What happens if I want to present a screenshot not of the entire screen/desktop (which would presumably match these ratios) but only of my application’s window, which may well not match the ratios? Moreover, what if my screen has a different aspect ratio? (it does - it’s 1920x1200 which is 16:10).

  • Daniel
2 Likes

Then you have to crop to one of the ratios

1 Like

Having discussed this with @jdahlin, @roadmr, and @pheurton last night, I am in favour of the proposed changes to better govern media constraints of screenshots but I have one concern.

My feeling is that enforcing screenshot aspect ratios will introduce a hurdle that will prevent publishers submitting screenshots to the store. Currently, ~75% of screenshots in the snap store do not adhere to the proposed aspect ratio constraints. Few are full “screen” shots, most being an arbitrary size window.

I’d prefer to see the aspect ratio constraint dropped.

3 Likes

I was in that call as well, I hope that the screenshot sizes that would be allowed would also be the ones provided by appstream so that snapcraft’s parse-info could consume from and reuse on the Snap Store.

1 Like

Hi folks,

AppStream is even stricter and only allows 16:9 aspect-ratio screenshots, also requiring that the smallest dimension is 620px, so that part should be covered.

The aspect ratio restriction was intended to prevent entirely nonsensical images (example: a screenshot of the top menu bar only would be e.g. 1920x32 which makes no sense, or a screenshot of the dock which could be 64x1200). But anything somewhat rectangularish should cause no problems, unless clients do expect a very strict set of aspect ratios and have presentation logic (CSS argh) to deal with those aspect ratios and no more.

Requiring an exact aspect ratio, as well as causing needless rejections, would result in a greater proportion of screenshots being full-screen. This in turn would result in a greater proportion of screenshots containing:

  • prominent bits of shells that a visitor might not be running (e.g. a screenshot taken on KDE)
  • launchers and panels containing icons of other apps, which their vendors might complain about, if they didn’t want to be associated with your app
  • bits of windows belonging to other apps, ditto.

I think my original proposal — from 1:3 to 3:1 — would achieve that.

Looking at the feedback from the replies here, we thought that instead of prescribing allowed aspect ratios which as @mpt and @Wimpress suggests could create needless rejections, we can allow a range of allowed dimensions from minimum to maximum with the caveat that the image should be at least 1:2 or 2:1. This can help us avoid strange situations of 1000x30, 300x50, 10x3000…

i.e. If a publisher uploads an image that is 500px wide, then height should be at least 250px tall

Thoughts?

4 Likes

Just bump on the new screenshot restriction with the following CLI screenshot:

Not going to complain it as it can be easily workarounded by resizing the window, or use screenshot generators like Carbon.

I wonder what is the optimal aspect ratio (LINESxCOLUMNS) for Asciinema clips?

Note that the snap banner and banner icons documented in Getting ready for stable are no longer upload-able due to this restriction.

I am unable to add screenshots to Wekan snap listings.

As of today this is fixed thanks @Lin-Buo-Ren :+1:

@xet7 This is due to the new media restrictions and the front-end not handling them properly, I’ve updated https://github.com/canonical-websites/snapcraft.io/issues/1663 with the current status :slight_smile:

Around 120 cols by 24 rows works pretty well :slight_smile:

1 Like

Based on our conversation, we decided to move away from featured and use the term banner instead as featured might imply additional consideration.

Video

We will not host video media but will allow publishers to include links to media video from popular platforms in their snaps. Some platforms we discussed to introduce: asciinema.org (specifically for terminal-based snaps), youtube.com, vimeo.com (already allowed in the old dashboard).

Images

Right now we are only allowing users to upload image media related to Snaps but in the future, there will be public publisher pages which will allow users the ability to include their branding and perhaps some banner to be used in these pages.

There are 2 additional work streams that will help publishers to contribute with acceptable and great media types to the platform: be able to preview a Snap listing page and guidelines and rules for media types (i.e. safe zones for banners, guidance on what to showcase in screenshots, avoiding text as much as possible in screenshots…). These will be worked out once we have an agreed direction.

General details

  • Accepted media formats: PNG, Animated GIFs, JPG / JPEG, SVG (currently converts to PNGs)
  • Maximum overall file size : 2 Mb

Support for SVG for icons

Upload of SVG images is currently supported for icons which currently convert to PNG format after the publisher uploads them. We have discussed future native SVG support as the majority of clients could render and support this file format.

Limitations for animated GIFs

  • Minimum frames per second: 1 fps
  • Maximum frame per second: 30 fps
  • Maximum length : 20 seconds

Media images related to Snaps

General Number Required Allowed aspect ratio Min size Max size Recommended size Max. file size
{snap-name}-icon 1 :heavy_check_mark: 1:1 40x40 512x512 256x256 256 kb
{snap-name}-banner 1 2:1 640x320 3840x1920 1920x960 2 Mb
{snap-name}-shot-# Up to 4 :heavy_check_mark: 1:1, 4:3, 16:9 480x480 3840x2160 1920x1080 2 Mb

Description of items from the table above:

  • Snap icon: This image will be shown in search results, store pages and its details page.
  • Snap banner: Storefronts might decide to promote a given snap and this media type will allow them to feature a Snap
  • Snap shots: Any image/s from a snap that will be displayed on the given public listing page

Note: Support for the old GNOME Software banner (1218x240 using -banner.jpg at the end of the file) will be temporary as we will transition to use the banner specified above.

Media images related to Publishers

NOTE: We are not currently working on public publisher pages but it is something that will be worth considering in this thread.

General Number Required Allowed aspect ratio Min size Max size Recommended size Max. file size
{publisher-name}-icon 1 :heavy_check_mark: 1:1 40x40 400x400 256x256 256 Kb
{publisher-name}-banner 1 2:1 640x480 3840x1920 1920x1080 2 Mb

Description of items from the table above:

  • Publisher icon: Refers to a brand image to be displayed in Snap details pages and (future) public pages from publishers listing additional information

  • Publisher banner: To be used in (future) public publisher pages in case they will be featured somehow in any of the storefronts or used as a background image for their (future) public pages

––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

@cprov let me know if you want to discuss further

@pheurton My only objection is trying to “formalize” the legacy banner support. IMO, we should leave the legacy banner support as is and promote the new banner experience across the ecosystem.

The legacy banner can coexist with the new banner, if necessary and under the current terms (fixed dimension and specifically named screenshot), but it will eventually be forgotten and die.

1 Like

It seems this post is now missing banner restrictions altogether!?

What I’ve implemented on the snapcraft.io publisher side for the new banner media type: Image type: PNG or JPEG File size limit: 2mb Aspect ratio: 3:1 Max dimensions: 4320x1440 Min dimensions: 720x240

@pheurton @kenvandine @cprov can we agree on these restrictions?

If so,

  • the front-end (uploading of assets) is ready to go :ballot_box_with_check:
  • the store binary-data API will need updating to the new restrictions
  • Snap Store snap, GS etc. will need updating to use the new sizes
2 Likes

The image type, file size and min/max dimensions are fine for GNOME Software; the aspect ratio is a big change.

Is the intention that the whole banner image be always visible? Banners are currently stretched to fit the screen width and cropped to fit the available space.

If we just updated the banners to the new aspect ratio then without any futher changes it would look like this:


If we fit them vertically it looks like this:


Note the text and icon would not be used - just showing these examples to give an idea of the GNOME Software behaviour. I used the currently promoted snap (krita) which has a much wider banner and cropped it to be 1:3.

If we accept the banner aspect ratio of 1:3 I see us as having the following options:

  1. Centering the banner as shown in the last two screenshots.
  • We need to work out what to put in the space either side of the banner (if anything).
  • Not a lot of work, and should be upstreamable.
  1. Showing multiple banners to fill the available space.
  • Resolves the whitespace issue from above.
  • Reasonable amount of work, but doesn’t align with existing banners used upstream so may not be acceptable.
  1. Use a new home screen layout in GNOME Software.
  • Allows us to place banners in any desired layout.
  • A lot of work and expected to be sufficiently Ubuntu specific that would not be upstreamable.

If we go with options 2 or 3 then we’d probably also need to do option 1 for non-Ubuntu users of GNOME Software to have an acceptable experience.

1 Like

The idea long-term is to remove the requirement of having an icon and snap name overlay and instead have publishers “bake-in” the logos or text.

Would that mean its possible to scale the image up with the window, to a maximum width, then center the image, without needing any magic to keep the icon and text over the background? This would probably need some design/ UX input /cc @pheurton.

Based on the options proposed I’d say option 3, is the preferred.
Option 1 is a sensible fallback if there is no banner.png and banner-icon.png. If those files are available they should be used - as they currently are - in place of option 1. You’ll have to advise on the potential of upstreaming that logic.

1 Like