Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Creating article covers is a challenging task, especially when they are used to generate thumbnails with various aspect ratios. #1115

Open
wxjv99 opened this issue Jan 20, 2025 · 0 comments

Comments

@wxjv99
Copy link

wxjv99 commented Jan 20, 2025

Here, I use my native language Chinese to clearly and accurately describe this problem. I am still in process in learning English, translation software can help me. Everyone can reply in English, and I can understand it.

主题中简单的使用Fill方法来处理文章封面图,会导致图片内容缺失并让封面图的制作变得困难。应添加一些配置项或改用可被custom.scss覆盖的样式来实现对缩略图尺寸的控制。

首先,列举下存在的各种宽高比

文章通过md文件头部的image配置的原图,将用于生成以下这些宽高比的 封面/缩略图(以1080p屏幕为例)

  • 首页的文章列表:宽度1600px 或者 800px,宽高比约为 11:3
  • 文章底部的相关文章:宽度250px,宽高比为5:3
  • 文章(archives)页面的列表:宽度120px,宽高比为1:1

它们在图示中看起来是这样的。
Image

如何兼容11:3、5:3、1:1宽高比?这三种宽高比的图片均来至一张原图,为了让图片中的内容不丢失,或许只能将其放置在1:1的蓝色框中,两侧使用可被裁剪的无意义背景填充。在这样的图片上展示内容会相当的怪异,因为只有约27%的面积可供使用。

其次,Hugo图片处理在不指定锚点(anchor)的情况下,默认使用“智能(Smart)”模式

我设计了一张基于5:3宽高比的文章封面,并使其内容在11:3和1:1下不丢失。我希望是按图中这样裁剪。
Note: 这个方案也相当糟糕,你能看出可用面积仍然很小)
Image

然而"智能(Smart)"的算法实际会做如下裁剪。
Image

  • 基于5:3的原图(1600px),在处理为关联文章列表的缩略图后(同样的宽高比但更小尺寸),"智能"裁剪锚点偏左,导致内容不在图片中心,而是偏右。
  • 处理为 文章(archives)页面 的缩略图后,"智能"裁剪锚点偏右,导致左侧logo被切掉一部分。
    这也意味着通过在制作图片时调整内容位置来兼容各种宽高比不总是能得到完美效果,只能祈祷"智能"裁剪能够魔法般的输出合格的缩略图。

正在使用这个主题的人是如何处理这个问题的?

我访问了部分使用这个主题的博客网站,发现了以下三种解决方案

  1. 只保证最大尺寸的图案正常,即 首页文章列表(宽度1600px 或者 800px,宽高比约为 11:3),放弃其他页面。
    制作11:3的图片本身就是一种挑战,宽度几乎是高度的4倍😣

  2. 使用没有内容的图片,如自然风景、纯色图、虚拟艺术图等。
    文章封面图与文章无关,额...

  3. 无图模式,全部博客文章都不配置任何封面图。
    缺失图片会让博客的文章过于密集,我不喜欢这种感觉。比起放弃有问题的功能,我更希望能解决问题。

Note:这是固有的、公共的问题,其他人绕开、忽略了它。问题本身就是存在的,并不是由我带来的,我只是报告并详细描述了它。)

目前我是怎样做的

  • 首页文章列表通过custom.scss来调整图片高度,使用5:2作为封面图片宽高比
.article-list {
    article {
        .article-image {
            img {
                height: 35vh;
            }
        }
    }
}
  • 在将11:3 替换为 5:2 后,我得到了三种宽高比即 5:2、5:3、1:1,这三种宽高比的图示如下
    Image
    这样的文章封面图制作起来就轻松了不少。但是"智能"裁剪还是困扰着我,它总是抓不住图片的重点在哪儿,特别是将多张图片经过PS拼接后。

仍需处理的问题

  1. 兼容首页(11:3)和文章页(1:1)的缩略图宽高比十分困难,这意味着图片将丢失73%的面积
    Note: 即使我将首页的文章封面的宽高比改为5:2,想要达到兼容效果仍然是困难的)
    在文章(archives)列表中,当原图被处理为1:1的缩略图时指定了宽和高。如果改用Resize并只指定高度,那么我可以在不更改主题代码的情况下通过custom.scss解除掉1:1的宽高比,这样会保持原图片的宽高比,而且不会受到裁切时随机的中心点的困扰。
    {{- if (default true .Page.Site.Params.imageProcessing.cover.enabled) -}}
    {{- $thumbnail := $image.resource.Fill "120x120" -}}
    {{- $Permalink = $thumbnail.RelPermalink -}}
    {{- $Width = $thumbnail.Width -}}
    {{- $Height = $thumbnail.Height -}}
    {{- end -}}

    于是我将Fill改为Resize,并只指定目标高度,再移除相关的scss限制。得到下图的效果。下图看上去是协调的,但是需要注意,这建立在我的所有文章的封面图的宽高比都是一致的基础上。若文章的封面图的宽高比不一致,则列表中缩略图显示的宽度将会不一致。(可以通过在scss中指定宽度并设置object-fit: cover来统一宽度,但是这会带来与"智能(Smart)"裁切不一致的行为,即 算法裁切 ---> 中心裁切)
Image
  1. 原图通过Fill转为同样宽高比的小尺寸图片,也会存在内容丢失或改变
    在相关文章列表中,当5:3的大尺寸图通过Fill转为5:3的小尺寸图时,"智能(Smart)"的锚点居然不是在中心。可以明显看出处理后logo是靠右的,如果偏移量足够多,这可能会丢失内容。
    Image
    这个问题的解决较为困难,因为涉及到了一个公共组件article-list/tile,最好是能在公共组件外,即组件的入参上想办法。
    <div class="related-content">
    <div class="flex article-list--tile">
    {{ range . }}
    {{ partial "article-list/tile" (dict "context" . "size" "250x150" "Type" "articleList") }}
    {{ end }}
    </div>
    </div>

    {{- if .context.Site.Params.imageProcessing.cover.enabled -}}
    {{- $thumbnail := $imageRaw.Fill .size -}}
    {{- $Permalink = $thumbnail.RelPermalink -}}
    {{- $Width = $thumbnail.Width -}}
    {{- $Height = $thumbnail.Height -}}
    {{- end -}}

我熟悉go语言及hugo的主题模板语法,可以由我提pr来修复。但是在这之前,我认为需要经过一定的讨论,得出一个向前兼容的解决方案。因为目前该主题已被大范围使用,希望能够在不影响已使用该主题的博客的情况下解决图片处理上的问题。

Hugo version

0.141.0

Theme version

3.29.0

What browsers are you seeing the problem on?

Microsoft Edge

More information about the browser

Edge 132.0.2957.115, Windows 11 24H2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant