Cover Aspect Ratio Discussion

[kruegp]

Description

This Github issue is to track further discussions related to the Maintain Cover Aspect Ratio Feature Request.

• This issue was created after recommendation from discord

Considerations / Uses

• thumbnails for covers (series, volumes, chapters, issues, ...) when displaying in library, search results, or within a series
  • Types of aspect ratios
  • portrait style
    • Within the Dune Series in Google Play Books, the covers range from aspect ratios (1:1.4 to 1:1.8)
  • square-ish styles
    • see example of Garfield Series in Google Play Books
  • landscape style
    • see example of Froggy Children's books in Google Play Books
  • Different genres (manga, western comics, newspaper comics, books, webtoons, ...) may all have different aspect ratios & notions of covers
    • ie: webtoons may have short height and long width strips as the first file
• thumbnails are used for generating combined image covers for collections

Patterns Other Apps Use

Displaying thumbnails for assets

• komga
  • Example
  • as mentioned in the original feature request, komga seems to have a fixed height and width for the asset overlay, and the cover image is scaled to fit within the asset overlay (keeping the aspect ratio) (ie: containing)
  • additionally, the overlay background can be seen since the cover does not fill the overlay
  • additionally, the cover is centered
  • I believe this is similar to object-fit: contain
• google search results
  • Example for Dune Series
  • Example for Garfield Series
  • seems to have a fixed height and width for the asset overlay, and the cover image is scaled to fit the entire asset overlay (keeping the aspect ratio) (ie: cropping)
  • I believe this is similar to object-fit: cover
• google play books
  • Example Garfield Series - Issues
  • Example Dune Series
  • seems to have a fixed width and a dynamic height (based upon the image height) for each asset overlay, the cover image is scaled to the fixed width (ie: fit)
  • additionally, the overlay background can not be seen since the cover is the same size as the overlay
  • additionally, the cover is centered horizontally and is justified to the bottom vertically
• Theoretical - Justify Vertically
  • although I haven't see an existing example, one could follow a similar pattern to google play books, but fix the height and allow the width to by dynamic
• Amazon Kindle Store
  • Example Garfield Books
  • follows the same pattern as komga (with a different fixed width and height
  • seems to have a fixed height and width for the asset overlay, and the cover image is scaled to fit within the asset overlay (keeping the aspect ratio) (ie: containing)
• existing kavita behavior
  • seems to have a fixed height and width for the asset overlay, and the cover is scaled to fir the entire asset overlay (not maintaining the original aspect ratio) (ie: stretching)
  • I believe this is similar to object-fit: fill

Combined image collection covers

• google play books
  • Example for Garfield Series - (see the first series)
  • the individual thumbnails are stretched to fit a specific height and width (object-fit: fill) and then merged into the combined image cover

[majora2007]

Thank you for adding a detailed post. To regurgitate what was discussed in discord. The original intent behind the change was to:

1. Provide the ability to build merged covers (4 covers in a grid) for collections and reading lists
2. Fix some stretching I was seeing in Comics and Webtoons and ensure all images fit in the UI nicely

As we discussed in discord, I did not consider things like Landscape books, which will always then have a bad cover in Kavita.

In terms of design, what we see in Komga and Amazon are no go for me. In my view, they do not look good and is not something I would want Kavita to have. I am 100% open to discussion and making a change as long as it will work on the majority of user material (books, webtoons, manga, and comics).

I will leave this to some discussion from the community.

[Ark1369]

Hello, I would like to add my opinions to the same. The cover aspect Kavita features right now is sort of perfect when it comes to eastern literature in a way. While webtoons on 1st glance look obviously bad due to those extreme long strips, that is a lost cause - whats important is official covers/season covers for these webtoons, they fit snugly in 2:3/68:100/7:10 which is very close to what Kavita features Manhuas are same. (I have amassed roughly 1700 Volume/Manhwa Season covers officially to test)

So Kavita handles all the official covers of Manga (Full volume sleeves arent meant to be covers persay), Manhwa and Manhua rather well. As per my limited knowledge Comics usually share the 2:3 aspect ratio for majority of the contents too.

So ultimately what could be the solution is - Inbuilt cropper for Kavita if possible, it would allow you to crop the cover out of Manhwa or crop the front of Manga Volume sleeve. (And this could serve as base for eventual set any picture inside cbz as cover - much like Tachiyomi features)

What I would actually like to be seen is, giving users an option to preserve the real quality of covers they upload/cbz dimensions instead of heavy forcefuly resize to 220x320. As on bigger screens it just looks extremely bad. (Option instead default so those who just want speed more instead quality on covers can keep it).

Komga one is inded worse of due to seeing backgrounds and whitespace when it forcefully resizes to fit in window.

[kruegp]

In terms of design, what we see in Komga and Amazon are no go for me. In my view, they do not look good and is not something I would want Kavita to have. I am 100% open to discussion and making a change as long as it will work on the majority of user material (books, webtoons, manga, and comics).

Agreed. I think other options look better than those.

My personal preference would be to avoid stretching of the existing cover text / art

I think my top 2 choices would be:

• (1) the original aspect ratio (similar to google play books)

  • overview
    • could give a fixed width and allow the height to be dynamic (with a max height option)
    • the collection cover could then be generated by stretching or cropping
  • tradeoffs
    • this would be the most flexible option (ie: if a user wanted to stretch or crop to a standard aspect ratio, they could always upload a new cover to the ui with their desired aspect ratio)
    • this would retain the original cover image
    • however - different titles with slightly different aspect ratios may look non-uniform (Example Dune Series)

• (2) cropping (similar to google search results)

  • overview
    • could give a fixed width + height and crop images to fit that view
    • the collection cover could then be generated as is
  • tradeoffs
    • this would standardize the cover dimensions
    • this would not alter the original cover aspect ratio (of that displayed)
    • in a large number of cases, this would have minimal impact on the cover image since edges usually don't contain details (Example for Dune Series)
    • However - this may not be ideal for square / landscape books since it may cut off text from the title or key parts of the image (Example for Garfield Series)

---

There could also be opportunity to make this configurable (a global config)

• if the thumbnails are persisted in the original aspect ratio, then based upon configuration / css, different display options could be utilized

---

Since there may be different use cases, perhaps a discord poll could be created to see if there is consensus / preference from a wider audience in discord.

• If there is no consensus, that could imply exposing a global configuration for display options may be beneficial (or that users don't care much about this issue)

[howdy-im-david]

I know this discussion hasn't had input for a few weeks, but I wanted to chime in as primarily a western comic reader. I am also in favor of moving to keeping original aspect ratio intact.

@kruegp's Option (1) sums it up best, although I'll add that I don't personally feel that lack of uniformity is an issue. It could very well be artist/publisher intent to release something outside of the "standard" ratio for whatever creative reason and would be great to respect that as much as possible.

There's a few instances in Kavita's current UI where a fixed ratio creates a very undesirable result.

Reading lists highlight this best:

[takatak00]

Hi everyone, I would love to see a inbuilt cropper similar to Calibre for my Manga covers.

[majora2007]

So I took a look with the latest code from v0.7.10 and here is what I found:

• Garfield (Square cover)

• Dune (non-standard, tall image)

• Froggy (square cover)

• Horizontal (longer in the width than height)

Overall, I don't really see much of a problem here. The issue is only present when there is a horizontal image which can get skewed, but the other image types have minimal skewing.

[sdaqo]

I think as @majora2007 already said, it looks ok. I would still like to chime in with some ideas. Also, I would like to preface this by saying: I do not know if this is handled client or server side, if client side my examples are a little useless, but oh well.

1. For square (-ish) covers how about doing something like this This was generated by some python code from a project of mine:

   def process_cd_cover(path: str):
   cover = Image.open(path)
   cover = crop_image(cover, 270, 270) # Edit: There is not really a need to crop here if it was already determined that the cover somewhat resembles a square, should probably rather be squashed/stretched
   
   background = Image.open(path)
   background = crop_image(background, 270, 400)
   background = background.filter(ImageFilter.GaussianBlur(8))
   
   background.paste(
       cover, (0, int((background.height - cover.height) / 2))
   )
   background.save(path, "JPEG")

2. This may be a bit extreme but, how about using Seam Carving for ~cropping~ (Edit: I mean squashing/stretching) . I have no idea if this is feasable, but it looks cool :))

Example using https://trekhleb.dev/js-image-carver/: Garfield before (I am only using a screenshot so the quality is kind of shit, maybe with better quality this looks even better): After Seam Carving, this does look a little weird, but the text is way more readable then the squashed example from above.

Another example: Before: After:

3. Someone said it already, but I also think cropping is a good idea!

[GlassedSilver]

Not sure skewing images is something that is universally seen as acceptable in an app that otherwise prides itself with polish for its UI.

If the cover art is a given ratio that's just how it is. Comics and manga are often released in different aspect ratios and depending on what art is used the skewing can be less or very noticeable, especially with geometric forms.

I understand that nobody would insist on keeping a 299x102px image exactly like that, I think skewing (never cropping) that could be fine to fit into 300x100, but if we're talking different source aspect ratios rather than a suboptimally created file that's just a little off then skewing looks like a hack.

Just my two cents as non-developer though, so I voice this with upmost humbleness.

Edit: checked the linked PR. I agree that some cover art turns out better whilst other art won't. I thought of adjusting the grid layout for different aspect ratios, but I also realize that ai can't contribute code so back to my humbleness. :P