Hugo v0.162.0 Released

Announcements
1
3

Hugo 0.162.0 packages

Brew - Hugo Brew package for macOS and Linux - updated :white_check_mark:
Snap Package - Hugo Snap package for Linux - updated :white_check_mark:
Docker/CI Image - Hugo Docker image for Continuous Integration - updated :white_check_mark:
FreshPort - Hugo FreshPort package for FreeBSD - not yet updated :x:
Debian - not yet updated :x:
Ubuntu - not yet updated :x:
Fedora Copr - Hugo RPM package for Fedora and CentOS - not yet updated :x:
Chocolatey - Hugo Chocolatey package for Windows - updated :white_check_mark:
Scoop - Hugo Scoop package for Windows - updated :white_check_mark:

4

I have a question about the security change regarding text/html, specifically this mention in the docs:

By default, the HTML content format (media type text/html) is denied. Hugo emits HTML file content verbatim, which could allow arbitrary JavaScript execution. See the classification table for a mapping of content formats to media types.

. . . does this mean that HTML included (or “hand-authored,” as the 0.162.0 release doc called it) in Markdown like the following example will be denied by default?

<span class="red">Note</span>: This is a really important note.

(And I do realize that a Markdown file by definition is not text/html, but just want to be sure I understand.)

5

HTML mixed with Markdown in a .md file is not affected by this change.

6

Thank you for that confirmation.

7

Very excited about the AVIF support. That may let me move image processing away from the NodeJS/gulp tools I’m using presently, which is a big deal for me. Thank you.

8

Me too. When you’re doing so, I would read imaging: Add quality setting per image format · Issue #14957 · gohugoio/hugo · GitHub

Testing this it seems that the quality scale (default 75) isn’t directly comparable, so e.g. WebP with quality 75 may be similar in quality to AVIF quality 60. Knowing that may help reduce the file sizes. The above issue is about allowing per format quality values in the config, but you can currently set it when processing each image.

9

Thank you. Yes, quality scales are pretty much arbitrary and — in my experience, at least — aren’t consistent between formats or even tools (i.e. one tool’s 60 quality may be another tool’s 70).

With my JS-based tools, my configs had per-format quality settings, but also different quality settings for different output sizes. My feeling was that with some output sizes, I could get away with lower-quality settings while, conversely, others seemed to demand higher-quality. I don’t have any real heuristics for what works; it was mostly just a matter of looking at some sample images and seeing how they looked at different settings.

With that in mind, being able to set the quality per-image (or rather per-output-image-size) might even be more useful than having a global setting in the config.toml file.

10

You can do that today, see e.g.

11

This new AVIF capability allowed a quick switch/upgrade from WEBP in my Hugo responsive image generation :magic_wand::clap:t3:

And thank you for the confidence inspiring companion demo site: GitHub - bep/hdrsdr.com: Testing out AVIF (with HDR) support in latest Hugo ¡ GitHub

I noticed this all smoothly handles and resizes 10 bit rec2020 HLG exports from Darktable raw photo edits, and modern browsers (Chrome, …) render it all nicely for “HDR” displays.

But handphone OS, Instagram, some browsers(?) etc still seem to choke/lack true AVIF 10-bit HDR colorspace handling, and still can only handle “metadata HDR” 8 bit SDR formats like ‘UltraHDR’ jpg. Picture/source templating patterns with img fallbacks are likely a requirement for Hugo sites moving forward with native HDR media capabilities.

12

The HDR version of the demo site looks weird on FF 151.0.2/macOS Sonoma. “weird” in the sense of “every image is far too dark compared to the SDR variant, nearly nothing to be seen”.
There’s this issue from 2022 mentioning the phenomenon.
Also on Safari 26.2, the SDR images are noticeably darker than the HDR images (again on macOS Sonoma).
Only Chrome seems to show the HDR/SDR images in remotely similar colors.

13

The (main) reason we went for true-HDR and not e.g. SDR + gain maps is that the latter wouldn’t work (or it would require a big change) with Hugo’s processing filters.

14

I’m on macOS Sequoia v15.7.7, M1 Mac Mini, Floorp (Firefox fork v151) and the HDR is all very dark whereas the SDR version is “normal looking”. I’m excited with the new support of AVIF, it bodes well for photo heavy sites like portfolios. Thanks for all the work!

15

Yea, I see that too, it looks normal on Chrome, Brave and Safari. This smells like a HDR bug in Firefox – note that the large HDR AVIF on the demo site are exported from Adobe LightRoom (no Hugo processing involved), and they also look dark. I will try to do some research on the subject.

16

A quick Google for “firefox dark hdr avif” suggests that Firefox just don’t support HDR very well. It should be possible to do something ala:

<picture>
  <!-- HDR-capable displays -->
  <source srcset="image-hdr.avif" type="image/avif" media="(dynamic-range: high)">
  
  <!-- HDR with PQ transfer function (optional for specific mastering) -->
  <source srcset="image-hdr-pq.avif" type="image/avif" media="(color-gamut: p3) and (dynamic-range: high)">

  <!-- Standard (SDR) fallback for all other displays -->
  <img src="image-sdr.jpg" alt="A beautiful landscape image">
</picture>

Not sure if the above would tackle the Firefox case on HDR displays, though …