Image Resizing and Cropping #1014

marcojakob · 2015-03-30T16:54:57Z

Dynamic image resizing is already on Hugo's Roadmap but I couldn't find an issue for it.

There is a discussion in the Hugo forum. Here are some aspects:

How it could/should work

An image file is put into either the static folder or in the content directory next to a page.
The final size of the image can be specified either in the content file (front-matter/markdown content) or in the template.
Hugo automatically resizes and crops the image based on the specified size.

We would need to figure out a good place to put the resized images.

Possible Syntax

Some ideas about the syntax:

Syntax 1

Size: image.s200.jpg (200 is longest dimension)
Width: image.w200.jpg
Height: image.h300.jpg
Width and Height: image.w200-h300.jpg
Size with Cropping: image.s200-c.jpg
Width and Height with Cropping: image.w200-h300-c.jpg

(this is somewhat similar to what Google App Engine implemented but did not document. I stumbled upon it by accident and added it in this issue comment. You can play around with the example link to bananas...)

Syntax 2

Similar as above but with query parameters:

image.jpg?w=200&h=300&c=true

Syntax 3

Yet another option:

image.jpg?w200-h300-c

The text was updated successfully, but these errors were encountered:

picnoir · 2015-03-31T06:28:54Z

I really need this feature, I am on it :)

marcojakob · 2015-04-15T22:55:43Z

High-resolution devices are on the rise. We might also need to think about providing a high-resolution image next to the normal sized image.

A common way is to add an image@2x.jpg next to the image.jpg. See retina.js for examples.

bep · 2015-04-15T23:00:28Z

Also see #1059

trakais · 2015-11-18T19:47:15Z

Any news about this, or the retina support for images?

anthonyfok · 2015-12-03T21:08:14Z

Some possible solutions and related links for image resizing, in random order:

https://github.com/nfnt/resize
https://github.com/bamiaux/rez
https://github.com/DAddYE/vips
- http://www.vips.ecs.soton.ac.uk/index.php?title=VIPS
- On Debian/Ubuntu: sudo apt-get install libvips-dev
Calling vipsthumbnail directly (sudo apt-get install libvips-tools)
https://github.com/gographics/imagick
https://github.com/oysterbooks/halfshell
Speed test: https://github.com/fawick/speedtest-resize

kujohn · 2015-12-16T18:02:28Z

Working on this in piecemeal @ here. Feedbacks welcome!

kujohn · 2015-12-22T06:53:30Z

I need a bit of a guidance here.

My branch has commits that uses the file handler setup for image resize and/or crop. The next step is to write the file out to disk but my problem is figuring out where the file should go.

Currently, File and Page are processed separately and I have yet to figure out a way to associate the images via s *site. Page's public destination is wrapped up in page name folder with index.html for example:

content:

content/post/golang/tips.md
content/post/golang/hero.w500-h300-c.png

after hugo:

public/post/golang/tips/index.html
public/post/golang/hero.w500-h300-c.png

One thought is to have the file use UniqueID as the filename and save them into public/static. Then when processing the template, it would look up the image and use the same UniqueID for html.

Thoughts?

Lynxiayel · 2015-12-22T15:27:31Z

I have an implementation using this tool for resizing pics and generating thumbnails.
IMHO, putting all images in static makes it hard to manage, especially when there are different versions of the same pic, like thumbnails. I suggest generating pics for a certain post at the same place, with a folder name like post_name_pics. In this case, the relative path will not change after hugo, the post should still find corresponding pics in need.

To save the trouble of writing the relative path, a shortcode like postImg can be given, so the pic folder name is prefixed automatcally.

…io#1014

key-notes · 2016-03-04T13:14:18Z

I really need this feature as well. I'd like to propose an even simpler syntax:

img.jpg?100x200

... where 100 is width and 200 height. This would also correspond with ImageMagick's syntax.

Has any progress been made on Retina image support in Hugo?

cathalgarvey · 2016-03-09T10:32:46Z

Hey @key-notes that's a great idea; local/relative URLs could be parsed for query data (make that explicit though, like ![Profile photo](/images/me.png?bounds=100x200), then passed to @Lynxiayel's suggested library, nfnt/resize to dynamically resize, and a copy could then be stored as /public/images/me_bounds100x200.png and referenced in the blackfriday output.

I'm not familiar with Hugo's processing pipeline (yet) so I don't know whether hooking this into Blackfriday's workflow is trivial or easy?

bep · 2016-03-09T10:51:12Z

I'm not familiar with Hugo's processing pipeline (yet) so I don't know whether hooking this into Blackfriday's workflow is trivial or easy?

That is doable, but means BF only. I did a writeup about this somewhere, about hooking into the Hugo transformer chain.

cathalgarvey · 2016-03-09T11:50:29Z

Come to think of it, this functionality might be even more generally
applicable if it were pushed upstream as an optional mode in blackfriday
itself?

On Wed, 2016-03-09 at 02:51 -0800, Bjørn Erik Pedersen wrote:

    I'm not familiar with Hugo's processing pipeline (yet) so I
    don't know whether hooking this into Blackfriday's workflow is
    trivial or easy?
That is doable, but means BF only. I did a writeup about this
somewhere, about hooking into the Hugo transformer chain.

—
Reply to this email directly or view it on GitHub.

bep · 2016-03-09T11:54:58Z

if it were pushed upstream as an optional mode in blackfriday itself?

Maybe, but Hugo is more than Blackfriday. And Hugo would somehow need to react to the "decisions" made by Blackfriday, so we need something more than just the []byte output ...

oodavid · 2016-05-26T07:26:37Z

Could it be worth considering piping commands to imagemagick rather than re-inventing the wheel regarding notation etc? A huge bonus would be their extensive documentation.

cathalgarvey · 2016-05-26T07:30:46Z

There are Golang libmagick bindings out there IIRC, but also pure-go image mod libs that have great APIs and avoid C bindings issues (memory usage, cross compilation, obscure crashes..).

On 26 May 2016 08:26:55 IST, David King notifications@github.com wrote:

Could it be worth considering piping commands to imagemagick rather
than re-inventing the wheel regarding notation etc? A huge bonus would
be their extensive documentation.

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#1014 (comment)

Sent from my Android device with K-9 Mail. Please excuse my brevity.

driehuis · 2016-12-25T01:30:38Z

The content management toolkit I'm most familiar with is Alchemy, an RoR app. Image handling is one of its strong points. I'd suggest taking a few pages out of its book.

No magic filenames.
Specify sizing with a shortcode like resizeimage /images/image.jpeg "400x400>"
Spit out resized images in directories named after the size, e.g. /public/images/400x300/image.jpeg, and have the shortcode reference the resized output file. The size reflects the actual size, so this example could result from the "400x400>" spec in the shortcode example (but that's a "nice to have", saving it to 400x400 is acceptable if needed for performance reasons).
Use a subset of ImageMagick sizing commands. Document which ones are accepted and only accept those. Of note, make sure the ">" operator ("keep aspect ratio") is among them, and document that it is recommended but not the default. Using ImageMagick syntax has several advantages: it's the lingua franca of image sizing, and it allows a quick implementation feeding the image to ImageMagic, without blocking the path of a native Go resizer at a later stage.
Set options like JPEG quality globally, possibly with an option to override in the shortcode.

The Alchemy approach is very easy to understand and to explain, which is why I'm quite fond of it.

tech4him1 · 2017-02-13T19:14:43Z

What about using the figure shortcode that we already have?

Fixes gohugoio#3651 Closes gohugoio#3158 Fixes gohugoio#1014

This commit also improves on the following: * Symbolic links are now allowed anywhere inside /content Fixes gohugoio#3651 Closes gohugoio#3158 Fixes gohugoio#1014 Closes gohugoio#2021 Updates gohugoio#3757

alex20465 · 2017-12-21T15:48:24Z

If you use S3 as storage you can setup an bucket-event with prefix&suffix (media/*.jpg) and invoke a lambda-function for image processing.

AWS provides already a lambda bluebird "image-processing-service" I am not sure if this is compatible with an s3 notification event.

spf13 · 2017-12-21T17:30:49Z

@bep Congrats on a great feature. I wanted to give some feedback which (you can take or ignore). I think the API is a bit too heavy. I also like periods as separators vs _. Periods denote that it's not part of the file name more clearly and are easier to type. Dashes as separators is nicer as well as they don't require a shift to type them.

I almost think there's actually too many options right now. Realistically I think people should only be able to resize, crop and change quality. For cropping I'm fine with it always being center cropped. I also think you should only be able to specify one dimension as the system should always resize proportionally. I think that's what people nearly always want anyway. If they specify two dimensions then just ignore the larger one.

Is there a reason to not implement the simple syntax provided in the thread? https://discourse.gohugo.io/t/dynamic-image-resizing-via-shortcodes-roadmap/857/4

Size: image.s200.jpg (200 is longest dimension)
Width: image.w200.jpg
Height: image.h300.jpg
Width and Height: image.w200-h300.jpg
Size with Cropping: image.s200-c.jpg
Width and Height with Cropping: image.w200-h300-c.jpg

I think things like rotation and more specific cropping are best done outside of the website engine.

Thoughts?

bep · 2017-12-21T18:09:12Z

I think things like rotation and more specific cropping are best done outside of the website engine.

The thing is, Go's image library does not have any support for EXIF data, so there is bound to be situations where the image taken with the iPhone looks fine in some preview but gets the wrong rotation when viewed in Hugo. The user could take the round back to Photoshop, but ... Go image resizer services I have looked at have taken a similar approach.

The "specific cropping" is the thumbnail use case etc., and having an (optional) way to set the anchoring position is pretty powerful. This kind of cropping is my main motivation for this feature -- in my head, this has very little to do with galleries etc.

Width and Height with Cropping: image.w200-h300-c.jpg

That thread and that API has the "filename as the API", which isn't my approach. And I would say that "200x300" reads much better and simpler than "w200-h300". You need to explain a little as to why that simple syntax is better than my simple syntax.

As to the API size: This is the methods that I need. Which also means that many others will most likely also need it. Fit, Fill and Resize makes a pretty complete API, which also means that we don't have to answer all the exotic "how do I do this particular image thingy?" on the discussion forum. And the cost of that completeness is relatively small.

Also, note that this is fully implemented. I appreciate your input, but I would prefer if you could chime in when the discussion is active.

This commit also improves on the following: * Symbolic links are now allowed anywhere inside /content Fixes gohugoio#3651 Closes gohugoio#3158 Fixes gohugoio#1014 Closes gohugoio#2021 Fixes gohugoio#1240 Updates gohugoio#3757

This commit is not the smallest in Hugo's history. Some hightlights include: * Page bundles (for complete articles, keeping images and content together etc.). * Bundled images can be processed in as many versions/sizes as you need with the three methods `Resize`, `Fill` and `Fit`. * Processed images are cached inside `resources/_gen/images` (default) in your project. * Symbolic links (both files and dirs) are now allowed anywhere inside /content * A new table based build summary * The "Total in nn ms" now reports the total including the handling of the files inside /static. So if it now reports more than you're used to, it is just **more real** and probably faster than before (see below). Fixes gohugoio#3651 Closes gohugoio#3158 Fixes gohugoio#1014 Closes gohugoio#2021 Fixes gohugoio#1240 Updates gohugoio#3757

This commit is not the smallest in Hugo's history. Some hightlights include: * Page bundles (for complete articles, keeping images and content together etc.). * Bundled images can be processed in as many versions/sizes as you need with the three methods `Resize`, `Fill` and `Fit`. * Processed images are cached inside `resources/_gen/images` (default) in your project. * Symbolic links (both files and dirs) are now allowed anywhere inside /content * A new table based build summary * The "Total in nn ms" now reports the total including the handling of the files inside /static. So if it now reports more than you're used to, it is just **more real** and probably faster than before (see below). A site building benchmark run compared to `v0.31.1` shows that this should be slightly faster and use less memory: ```bash ▶ ./benchSite.sh "TOML,num_langs=.*,num_root_sections=5,num_pages=(500|1000),tags_per_page=5,shortcodes,render" benchmark old ns/op new ns/op delta BenchmarkSiteBuilding/TOML,num_langs=1,num_root_sections=5,num_pages=500,tags_per_page=5,shortcodes,render-4 101785785 78067944 -23.30% BenchmarkSiteBuilding/TOML,num_langs=1,num_root_sections=5,num_pages=1000,tags_per_page=5,shortcodes,render-4 185481057 149159919 -19.58% BenchmarkSiteBuilding/TOML,num_langs=3,num_root_sections=5,num_pages=500,tags_per_page=5,shortcodes,render-4 103149918 85679409 -16.94% BenchmarkSiteBuilding/TOML,num_langs=3,num_root_sections=5,num_pages=1000,tags_per_page=5,shortcodes,render-4 203515478 169208775 -16.86% benchmark old allocs new allocs delta BenchmarkSiteBuilding/TOML,num_langs=1,num_root_sections=5,num_pages=500,tags_per_page=5,shortcodes,render-4 532464 391539 -26.47% BenchmarkSiteBuilding/TOML,num_langs=1,num_root_sections=5,num_pages=1000,tags_per_page=5,shortcodes,render-4 1056549 772702 -26.87% BenchmarkSiteBuilding/TOML,num_langs=3,num_root_sections=5,num_pages=500,tags_per_page=5,shortcodes,render-4 555974 406630 -26.86% BenchmarkSiteBuilding/TOML,num_langs=3,num_root_sections=5,num_pages=1000,tags_per_page=5,shortcodes,render-4 1086545 789922 -27.30% benchmark old bytes new bytes delta BenchmarkSiteBuilding/TOML,num_langs=1,num_root_sections=5,num_pages=500,tags_per_page=5,shortcodes,render-4 53243246 43598155 -18.12% BenchmarkSiteBuilding/TOML,num_langs=1,num_root_sections=5,num_pages=1000,tags_per_page=5,shortcodes,render-4 105811617 86087116 -18.64% BenchmarkSiteBuilding/TOML,num_langs=3,num_root_sections=5,num_pages=500,tags_per_page=5,shortcodes,render-4 54558852 44545097 -18.35% BenchmarkSiteBuilding/TOML,num_langs=3,num_root_sections=5,num_pages=1000,tags_per_page=5,shortcodes,render-4 106903858 86978413 -18.64% ``` Fixes gohugoio#3651 Closes gohugoio#3158 Fixes gohugoio#1014 Closes gohugoio#2021 Fixes gohugoio#1240 Updates gohugoio#3757

erolabzait · 2017-12-25T20:12:03Z

Hello,

I'm new to Hugo and i can say it is awesome.
I come from the wordpress realm and i wanted to say a few things about resizing images.

This recent plugin made resizing images a breeze. It will be awesome if you take a look and maybe get inspired, if not imgix/gulp are always an option :)

Some key points

images are resized on demand
resized images are "linked" to the master image so when you regenerate all thumbnails/resized images they will be deleted and new ones are created on demand, this keeps the uploads directory clean from ghost images. (maybe a hugo image-regenerate option)
they also have a S3 uploads plugin to sync images from local (maybe a file to keep track of the resized images)

Thank you for the great work so far.

bep · 2017-12-25T20:59:35Z

@erolabzait that link shares many of my ideas in this area -- and I think you will be pleasantly surprised by my implementation. Only days away.

This commit is not the smallest in Hugo's history. Some hightlights include: * Page bundles (for complete articles, keeping images and content together etc.). * Bundled images can be processed in as many versions/sizes as you need with the three methods `Resize`, `Fill` and `Fit`. * Processed images are cached inside `resources/_gen/images` (default) in your project. * Symbolic links (both files and dirs) are now allowed anywhere inside /content * A new table based build summary * The "Total in nn ms" now reports the total including the handling of the files inside /static. So if it now reports more than you're used to, it is just **more real** and probably faster than before (see below). A site building benchmark run compared to `v0.31.1` shows that this should be slightly faster and use less memory: ```bash ▶ ./benchSite.sh "TOML,num_langs=.*,num_root_sections=5,num_pages=(500|1000),tags_per_page=5,shortcodes,render" benchmark old ns/op new ns/op delta BenchmarkSiteBuilding/TOML,num_langs=1,num_root_sections=5,num_pages=500,tags_per_page=5,shortcodes,render-4 101785785 78067944 -23.30% BenchmarkSiteBuilding/TOML,num_langs=1,num_root_sections=5,num_pages=1000,tags_per_page=5,shortcodes,render-4 185481057 149159919 -19.58% BenchmarkSiteBuilding/TOML,num_langs=3,num_root_sections=5,num_pages=500,tags_per_page=5,shortcodes,render-4 103149918 85679409 -16.94% BenchmarkSiteBuilding/TOML,num_langs=3,num_root_sections=5,num_pages=1000,tags_per_page=5,shortcodes,render-4 203515478 169208775 -16.86% benchmark old allocs new allocs delta BenchmarkSiteBuilding/TOML,num_langs=1,num_root_sections=5,num_pages=500,tags_per_page=5,shortcodes,render-4 532464 391539 -26.47% BenchmarkSiteBuilding/TOML,num_langs=1,num_root_sections=5,num_pages=1000,tags_per_page=5,shortcodes,render-4 1056549 772702 -26.87% BenchmarkSiteBuilding/TOML,num_langs=3,num_root_sections=5,num_pages=500,tags_per_page=5,shortcodes,render-4 555974 406630 -26.86% BenchmarkSiteBuilding/TOML,num_langs=3,num_root_sections=5,num_pages=1000,tags_per_page=5,shortcodes,render-4 1086545 789922 -27.30% benchmark old bytes new bytes delta BenchmarkSiteBuilding/TOML,num_langs=1,num_root_sections=5,num_pages=500,tags_per_page=5,shortcodes,render-4 53243246 43598155 -18.12% BenchmarkSiteBuilding/TOML,num_langs=1,num_root_sections=5,num_pages=1000,tags_per_page=5,shortcodes,render-4 105811617 86087116 -18.64% BenchmarkSiteBuilding/TOML,num_langs=3,num_root_sections=5,num_pages=500,tags_per_page=5,shortcodes,render-4 54558852 44545097 -18.35% BenchmarkSiteBuilding/TOML,num_langs=3,num_root_sections=5,num_pages=1000,tags_per_page=5,shortcodes,render-4 106903858 86978413 -18.64% ``` Fixes gohugoio#3651 Closes gohugoio#3158 Fixes gohugoio#1014 Closes gohugoio#2021 Fixes gohugoio#1240 Updates gohugoio#3757

cathalgarvey · 2017-12-28T00:11:41Z

Awesome! Thank you!

…

On 27 December 2017 17:45:33 GMT+00:00, "Bjørn Erik Pedersen" ***@***.***> wrote: Closed #1014 via 3cdf19e. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #1014 (comment)

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

wiradikusuma · 2017-12-30T07:32:38Z

Sorry, I saw that this issue is closed, so how do I implement image resizing and cropping in Hugo?

dmgawel · 2017-12-31T16:18:40Z

@wiradikusuma update Hugo to 0.32 and follow instrucions in: https://gohugo.io/about/new-in-032/ 🙂

kars7e · 2018-01-04T22:00:56Z

Hi, is there a way to use image processing feature without using resources? I looked at the link @dmgawel posted above, and I can't figure out how to do it with regular posts. I have plenty of posts under content/posts/, and images under static/. Now I would like to just add images to my post using resize/fit/fill, but without reorganizing everything. Is that possible?

It seems to me that even If I define the shortcode, it would still only work if the referenced image was part of post resources.This means I'd have to create a separate directory for each of my posts, move the post .md file and rename to index, and add images there to be able to use image processing feature. Is this correct?

derekperkins mentioned this issue May 15, 2015

Non-MD files in the content directory (like jpg's and png's) end up as html's #147

Closed

anthonyfok added Enhancement status/please contribute labels Dec 2, 2015

kujohn mentioned this issue Dec 24, 2015

Image resizing/cropping #1728

Closed

kujohn added a commit to kujohn/hugo that referenced this issue Jan 6, 2016

Register image handler for image transformations fixes gohugoio#1014

5457f14

kujohn added a commit to kujohn/hugo that referenced this issue Jan 6, 2016

Add helper type and func to parse image file properties, fixes gohugo…

e7843a9

…io#1014

moorereason removed the status/please contribute label Dec 28, 2016

This was referenced Jan 25, 2017

suggestion: offer rescaling / compression option to include_graphics() for external images yihui/knitr#1273

Closed

how to downscale, compress non-knitr images rstudio/blogdown#51

Closed

wildhaber mentioned this issue Mar 10, 2017

Image process handling (nice-to-have proposal) #3158

Closed

bep added a commit to bep/hugo that referenced this issue Dec 20, 2017

Implement Page bundling and image handling

8e0f6a0

Fixes gohugoio#3651 Closes gohugoio#3158 Fixes gohugoio#1014

bep added a commit to bep/hugo that referenced this issue Dec 20, 2017

Implement Page bundling and image handling

a581667

Fixes gohugoio#3651 Closes gohugoio#3158 Fixes gohugoio#1014

bep closed this as completed in 3cdf19e Dec 27, 2017

dependencies bot mentioned this issue Dec 31, 2017

Update https://github.com/gohugoio/hugo in repo_dependencies.yml from v0.31 to v0.32 matrixik/dobek.pro#5

Closed

gohugoio locked as resolved and limited conversation to collaborators Jan 4, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Image Resizing and Cropping #1014

Image Resizing and Cropping #1014

marcojakob commented Mar 30, 2015 •

edited

picnoir commented Mar 31, 2015

marcojakob commented Apr 15, 2015

bep commented Apr 15, 2015

trakais commented Nov 18, 2015

anthonyfok commented Dec 3, 2015

kujohn commented Dec 16, 2015

kujohn commented Dec 22, 2015

Lynxiayel commented Dec 22, 2015

key-notes commented Mar 4, 2016

cathalgarvey commented Mar 9, 2016

bep commented Mar 9, 2016

cathalgarvey commented Mar 9, 2016

bep commented Mar 9, 2016

oodavid commented May 26, 2016

cathalgarvey commented May 26, 2016

driehuis commented Dec 25, 2016

tech4him1 commented Feb 13, 2017

alex20465 commented Dec 21, 2017 •

edited

spf13 commented Dec 21, 2017

bep commented Dec 21, 2017 •

edited

erolabzait commented Dec 25, 2017 •

edited

bep commented Dec 25, 2017

cathalgarvey commented Dec 28, 2017 via email

wiradikusuma commented Dec 30, 2017

dmgawel commented Dec 31, 2017

kars7e commented Jan 4, 2018

Image Resizing and Cropping #1014

Image Resizing and Cropping #1014

Comments

marcojakob commented Mar 30, 2015 • edited

How it could/should work

Possible Syntax

Syntax 1

Syntax 2

Syntax 3

picnoir commented Mar 31, 2015

marcojakob commented Apr 15, 2015

bep commented Apr 15, 2015

trakais commented Nov 18, 2015

anthonyfok commented Dec 3, 2015

kujohn commented Dec 16, 2015

kujohn commented Dec 22, 2015

Lynxiayel commented Dec 22, 2015

key-notes commented Mar 4, 2016

cathalgarvey commented Mar 9, 2016

bep commented Mar 9, 2016

cathalgarvey commented Mar 9, 2016

bep commented Mar 9, 2016

oodavid commented May 26, 2016

cathalgarvey commented May 26, 2016

driehuis commented Dec 25, 2016

tech4him1 commented Feb 13, 2017

alex20465 commented Dec 21, 2017 • edited

spf13 commented Dec 21, 2017

bep commented Dec 21, 2017 • edited

erolabzait commented Dec 25, 2017 • edited

bep commented Dec 25, 2017

cathalgarvey commented Dec 28, 2017 via email

wiradikusuma commented Dec 30, 2017

dmgawel commented Dec 31, 2017

kars7e commented Jan 4, 2018

marcojakob commented Mar 30, 2015 •

edited

alex20465 commented Dec 21, 2017 •

edited

bep commented Dec 21, 2017 •

edited

erolabzait commented Dec 25, 2017 •

edited