Hugo: On build: convert JPGs larger than 1M into WEBP

[vitaly-zdanevich]

And produced HTML for WEBP must contains picture instead of img for fallback:

<picture>
  <source srcset="img/awesomeWebPImage.webp" type="image/webp">
  <source srcset="img/creakyOldJPEG.jpg" type="image/jpeg"> 
  <img src="img/creakyOldJPEG.jpg" alt="Alt Text!">
</picture>

[bep]

Can you be more specific?

[RealOrangeOne]

Doing an implicit conversion feels like a bad idea, as if the person wants to embed the >1m JPEG in their site, and don't care about the WEBM, then it's an unnecessary conversion. Perhaps some generic image conversion functions would be better, and used in a shortcode to create the above tags (although maybe not internal to hugo)

[onedrawingperday]

Also WEBP is not supported by all browsers, so this couldn’t be implemented as things are now.

Maybe this file format will replace JPG or maybe not.

[vitaly-zdanevich]

Also WEBP is not supported by all browsers, so this couldn’t be implemented as things are now.

picture tag handle it - Firefox will show JPG.

Doing an implicit conversion feels like a bad idea, as if the person wants to embed the >1m JPEG in their site, and don't care about the WEBM, then it's an unnecessary conversion.

Ok I agree - better turn it off by default. But would be usefull to have this option. Now my build script on GitLab have - find . -type f -size +1M -exec cwebp {} -o {}.webp \; ...

[onedrawingperday]

No support in Safari (desktop and iOS), Edge.

https://caniuse.com/#feat=webp

[vitaly-zdanevich]

No support in Safari (desktop and iOS), Edge.

Safari and others support picture, please see this article.

[flother]

Quite unfairly, JPEG has picked up a bad reputation. With mozjpeg, Mozilla have shown that many of the assumed inadequacies of JPEG images are caused more by unoptimised encoders than the format itself. You can read more at Performance Calendar.

As a quick example, I took this 4896×3264 image and then resized and re-encoded it using libwebp, libjpeg, and Mozilla's drop-in replacement for the latter, mozjpeg.

$ cwebp -resize 800 533 339839-orig.jpg -o 339839.webp
$ convert -resize 800x 339839-orig.jpg TGA:- | cjpeg -outfile 339839-libjpeg.jpg -targa
$ convert -resize 800x 339839-orig.jpg TGA:- | /usr/local/opt/mozjpeg/bin/cjpeg -outfile 339839-mozjpeg.jpg -targa
$ ls -lS 339839*
-rw-rw-rw- 1 matt 5224595 May 29 09:22 339839-orig.jpg
-rw-r--r-- 1 matt   83957 May 30 09:22 339839-libjpeg.jpg
-rw-r--r-- 1 matt   68841 May 30 09:22 339839-mozjpeg.jpg
-rw-r--r-- 1 matt   67340 May 30 09:22 339839.webp

You can see that although the libjpeg file is around 20% larger than the WebP file, the mozjpeg file gets to within 2.2% of the WebP. That's just using the defaults. If I tweak the parameters a little:

$ convert -resize 800x 339839-orig.jpg TGA:- | /usr/local/opt/mozjpeg/bin/cjpeg -quant-table 3 -optimize -outfile 339839-mozjpeg-optim.jpg -targa -smooth 10
$ ls -lS 339839-mozjpeg-optim.jpg
-rw-r--r-- 1 matt 57857 May 30 09:22 339839-mozjpeg-optim.jpg

This gives me a JPEG that's 16.4% smaller than the WebP file. The visual differences between all four re-encoded files is barely noticeable — subjectively I think the JPEG output is sharper, but for Web-use there's really little in it.

Now that's just one example of one file, of course, but my point is that WebP isn't definitively, objectively, better than JPEG.

[carlmjohnson]

Now that resources exist, this can be revisited as something like {{ $img := resource.Get "big-picture.jpeg" | toWebP }}.

[StephenBrown2]

I would love to see conversion functions like toWebP, toPNG, toJPG, maybe even toGIF, etc, as some recommendations prefer certain formats: https://developers.google.com/speed/docs/insights/OptimizeImages and https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/image-optimization#selecting_the_right_image_format

[vitaly-zdanevich]

@carlmjohnson function "resource" not defined, hugo 0.44, looks like must be "resources", but next error:
function "toWebP" not defined :( oh this is not implemented, sorry.

[onedrawingperday]

@carlmjohnson @StephenBrown2 I think it would be best if you opened a separate GitHub issue with your feature request for these img conversion functions.

[StephenBrown2]

I was merely extending the suggestion @carlmjohnson made. I would prefer Hugo to not be biased toward one image conversion vs another.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help.
If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.
This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.

[cromozooom]

if possible, this feature will help a lot of us :)

[kylewelsby]

This certainly would save me from having to use external services such as https://cloudinary.com/

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help.
If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.
This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.

[westurner]

WebP encoding would be a helpful feature.

[kylewelsby]

:+1: Bump

[LeviSchuck]

would totes like this

[kylewelsby]

anyone got a clue on where one could start to implement this?

[dktue]

+1

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help.
If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.
This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.

[westurner]

This would definitely be useful.

On Thu, Sep 5, 2019 at 12:56 PM stale[bot] [e-mail] wrote:

This issue has been automatically marked as stale because it has not had
recent activity. The resources of the Hugo team are limited, and so we are
asking for your help.
If this is a bug and you can still reproduce this error on the master
branch, please reply with all of the information you have about it in order
to keep the issue open.
If this is a feature request, and you feel that it is still relevant
and valuable, please tell us why.
This issue will automatically be closed in the near future if no further
activity occurs. Thank you for all your contributions.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/gohugoio/hugo/issues/4780?email_source=notifications&email_token=AAAMNS54VEGMHXXLAB45MRDQIE247A5CNFSM4FB3R442YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD572U7Y#issuecomment-528460415,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAMNSY67HE3R3XOKLEHAATQIE247ANCNFSM4FB3R44Q
.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help.
If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.
This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.

[westurner]

Is there a different script that can be called while building that could
accomplish compress(img, config.compression_params) if stat(img).size >
config.compression_max_size and output a build message if size is still
greater than e.g. compression_max_size?

On Fri, Jan 3, 2020, 3:46 PM stale[bot] [e-mail] wrote:

This issue has been automatically marked as stale because it has not had
recent activity. The resources of the Hugo team are limited, and so we are
asking for your help.
If this is a bug and you can still reproduce this error on the master
branch, please reply with all of the information you have about it in order
to keep the issue open.
If this is a feature request, and you feel that it is still relevant
and valuable, please tell us why.
This issue will automatically be closed in the near future if no further
activity occurs. Thank you for all your contributions.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/gohugoio/hugo/issues/4780?email_source=notifications&email_token=AAAMNSZKA2IJMUYM3IVJVS3Q36PZZA5CNFSM4FB3R442YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEICBM7Y#issuecomment-570693247,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAMNS43CDQLK235XAHTLS3Q36PZZANCNFSM4FB3R44Q
.

[DrSensor]

This article might be handy for supporting all browsers by choosing appropriate fallback formats.
https://joshwcomeau.com/performance/embracing-modern-image-formats/

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help.
If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.
This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.

[carlmjohnson]

https://www.macrumors.com/2020/06/22/webp-safari-14/ WebP is going to be in every major browser next fall.

[westurner]

Looks like https://github.com/gohugoio/hugo/blob/master/resources/images/image.go doesn't yet have:

• [ ] support for encoding as WebP
• [ ] a file size filter
• [ ] a check for an already-encoded file.name._.webp
• [ ] broadly-compatible markup template

Would the implementation of this feature be similar to https://github.com/gohugoio/hugo/blob/master/resources/images/smartcrop.go ?

[carlmjohnson]

The auto-convert part of this feature request strikes me as a mistake. I don't want images to change formats behind my back for no reason. What I would want would be the ability to specify the format and use the picture tag to do swap outs. In the future (5 years?), IE11 will be dead, and everyone will be using a modern browser, and all modern browsers will support WebP, so you can just use everywhere. But until then, you're going to want to use the picture tag, which means there needs to be the ability to spit out both Webp and JPEG given the same source image.