I tried this code
{{ $imageResource := .Page.Resources.GetMatch "**/*.webp" }}
{{ $resized := $imageResource.Resize "180x" }}
{{ $resized.RelPermalink }}
but I get an error:
<$imageResource.Resize>: can't evaluate field Resize in type resource.Resource
The .ResourceType is correctly identified as image. If I replace that with a jpg version it works.
webp is currently not supported. I guess that is probably not crystal clear in the documentation, and we should eventually support it.
https://github.com/disintegration/imaging/issues/25
So, currently I think the best we could do is to encode it to "something differeng", e.g. JPEG, but we should probably have some syntax for that.
@bep do you plan to implement the conversion and webp manipulation? if not, could we agree on specs so I can suggest an implementation?
My guess would be to implement a Convert function on the resource where you can send a configuration string indicating how to convert. Assuming we'd go for https://github.com/chai2010/webp, we could have the following markup:
{{ $webp := (resources.Get "image.jpg").Convert "webp" "lossless=true" }}
Code-wise, we'd have to parse the second argument to match parameters for the library used, but this would allow using it for other conversions in the future.
@geoffreybauduin one the API side this is mostly about adding another MIME type / image format. But that just scratches the surface of this. The main problem here is that there is no native Go webp encoder.
Is having a native webp encoder a must-have for you or would you be fine with a C library?
what is the status of this feature? are you considering using https://github.com/chai2010/webp or will you be waiting for a native go library?
@libvips/libvips is a fantastic library that has a Go binding. It is not Go-native, though.
Does it help?
@robsonsobral I think it would enables implementing imageConfig, but not manipulation.
I invested some time to bring WebP encoding to work, via PR #7155. Let's see if the approach will be accepted. 😄
Supporting WebP is great. However, please be careful not to assume that WebP is always smaller than a JPEG. I was thrilled to see WebP crush certain JPEG photos, but was also surprised that sometimes WebP created larger files than the original JPEG. As a result, we may also need a function that serves the files in order by size -- not just format.
That's true. This might be easy possible in the moment when hugo is at least supporting WebP.
Once we're able to create all formats, we can for example create short codes which are can doing this for us. Before that we need at first:
the general support to create WebP images. Currently this seems to be stuck because the PR #7155 was closed with the reference that this issue here (#5924) needs at first be clarified. But unfortunately this seems to be stuck, too. 😞
Add a function to determine the sizes of page resources.
Create a short code that covers at least the cases where an image will be directly embedded in the content. This should following the logic as described in this article.
Optionally: It might be possible to create a format which we call optimal-photo where which we can use as follows:
{{ $image.Resize "600x optimal-photo" }}
instead of specific types:
{{ $image.Resize "600x jpeg" }}
<!-- OR -->
{{ $image.Resize "600x webp" }}
Having webp would be nice indeed.
I understand the concerns about not having it as native go library, and having to maintain the binding here as explained in #7155
What about declaring the feature experimental using https://github.com/chai2010/webp as @arthurchaloin proposed?
Having it experimental, disabled and not shipped by default, would allow restricting support for it, and even dropping the feature at any time if the maintenance burden appears too high.
In this branch: https://github.com/tjamet/hugo/commit/webp I have a proposal to do so, having webp users to build their own binary using go build --tags webp github.com/gohugoio/hugo
Finally, one thought about
a format which we call
optimal-photo
IMHO this settings of picture tags should be in the templating side, not in the engine. Picture alternatives has a big adherence with the outer page layout and trying to support all possible things with media selectors, tags, ids, among others would be a pain.
We already have the ability to re-use snippets, and it should be possible to create a snippet that generates the image with something similar to
<picture>
{{- $large := $image.Resize "2840x png" -}}
{{- $small := $image.Resize "1920x png" -}}
<source type="{{ $large.MediaType }}" media="(min-width: 1921px)" srcset="{{ $large.RelPermalink }}">
<img src="{{ $large.RelPermalink }}" style="width: 100%;">
</picture>
@tjamet I've also looked at https://github.com/chai2010/webp but the issues with this one is that this is not a pure GoLang dependency. Otherwise I might have used it already. It requires a GCC to be installed, which makes it quite challenging to use/compile/build on some systems.
What about: https://github.com/libvips/libvips
It points to Go bindings in the readme. It is not native Go, but maybe bindings are somehow easier to handle?
Plus it seems to handle every possible image format under the Sun…
From: Gregor Noczinski notifications@github.com
Sent: sobota, 9 maja 2020 20:30
To: gohugoio/hugo hugo@noreply.github.com
Cc: Pawel Urbanski pawel@pawelurbanski.com; Comment comment@noreply.github.com
Subject: Re: [gohugoio/hugo] Add image processing support for WebP image resources (#5924)
@tjamethttps://github.com/tjamet I've also looked at https://github.com/chai2010/webp but the issues with this one is that this is not a pure GoLang dependency. Otherwise I might have used it already. It requires a GCC to be installed, which makes it quite challenging to use/compile/build on some systems.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/gohugoio/hugo/issues/5924#issuecomment-626217410, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAWAEQBF2YMJXTANIOPJCUTRQWOLVANCNFSM4HKDHUUQ.
webp support would be dope. Wish I could be more help on implementation. Way over my head. But the fact that it's even a discussion has me excited. I'm working on simple themes for photographers/journalist to self publish, reduce hosting costs, and modernize their websites/portfolios. The only publication I really see using webp extensively so far is the Washington Post.
In almost all my tests I see compressions pushing photographs to 1/5 the size with next to no loss.
It is actually implemented. But my PR just was closed and this discussion stalled here. I might be happy to know what I can do instead nothing.
I would be happy to reopen #7155 again and change what needs to be changed...
Most helpful comment
It is actually implemented. But my PR just was closed and this discussion stalled here. I might be happy to know what I can do instead nothing.
I would be happy to reopen #7155 again and change what needs to be changed...