Image resizing/cropping #1728
Image resizing/cropping #1728
Conversation
|
This is fantastic work and very appreciated. I've been thinking a bit differently about the interface for it though. It doesn't make a lot of sense to me to name the file on disk with the intended manipulations as it's pretty trivial anyway to do that when you put the file there. The real benefit to this feature in my eyes is the ability for someone to specify those dimensions inside of the content and that triggers an additional version of the file to be created matching those dimensions. so I put a single file... then in a content or template file I would reference it... perhaps in a different file I reference it differently This would result in all three versions of this file created in the destination. I think the real power of this feature is the ability for template designers and content creators to be able to dictate image dimensions without having to worry about manipulating images. Does that make sense? Other than that I think this looks good. I support using rez for the resizing. Another idea that I've been thinking about a lot lately would be a notion of caching or avoiding unnecessary work. There's a lot of expensive operations that we needlessly do over and over today. Every call to asciidoctor could benefit significantly from caching. Image manipulations would as well. It would be ideal to have a single caching system rather than reinvent it for each component of Hugo. |
|
also join us on gitter (gitter.im/spf13/hugo) if you want to chat about any of the dev you are doing. We're a friendly bunch and happy to give advice or answer questions. |
|
Thanks for the feedback @spf13, that makes better sense to have the manipulation interface in shortcodes. Theme creators can rely and utilize images and specify their size. There could also be shortcodes in the future to generate thumbnail galleries based on this interface. I'll will give it a shot on implementing this and look into some type of caching. Thanks for the gitter tip as well! |
|
Would it make more sense to centralize images in And then have this set in the config to create on build... #config.yaml
resizeImages: true
imageSizes:
- 200X200
- 100X100Here are a few ideas of why this might help, in order of most to least important
---
title: My Name is Ryan Watters
main_image: author1.jpg
main_image_description: This is a photo of author Ryan Watters
description: Yada yada yada yada yada yada
---And then something to the effect of the following in the templating logic for <article>
<header>
<h1>{{.Title}}</h1>
<img src="{{.Site.BaseURL}}/{{.Section}}/200x200/{{.Params.main_image}}}" alt="{{.Params.main_image_description}}">
</header>
...Or whatever, I think you see what I mean. Then use that same idea of thumbs in list pages. Ultimately, Hugo will never replace a full-blown DAM. I get the feeling this might be too opinionated since the docs are very clear that Hugo has no opinions about how a person structures his/her content. Thoughts @spf13 @kujohn ? |
|
@rdwatters I think your solution makes sense, but would really just be a separate process. That would be something very easily added independent of hugo. The solution I've proposed is an integrated solution as by enabling content creators and template designers to declare size it requires a deeper level of integration that could only be done by Hugo. If we do implement your solution I think it's independent of this one, and really falls more into a DAM territory. |
|
@spf13 I see what you're saying. I have mixed feelings about the shortcodes. Yes, they make it easier to write more with less in markdown, but at the same time, they run the risk of muddying separation of concerns. The thing I love about SSGs is that I can write to any Thanks for this amazing tool. Everyone I've turned on to Hugo has definitely had their hair blown back. Cheers. |
I kind of agree -- but not with the "you have to configure the sizes in config.toml etc.". I would like a feature that signals to Hugo that I want a different size. If we hook this into the transformer chain that does link manipulation, this should be pretty cheap too (as in: we don't need another pass and the image processing can be executed in full throttle on all cores):
I haven't thought hard on this, but I agree with @spf13 that I would prefer convention before configuration on this. |
|
In agreement with @bep. A proper implementation in my eyes is one where the theme designer can specify dimensions as well as the content creator as a natural part of their workflow and Hugo just works. What if inline in the markdown I referenced this image.
I'll leave it up to the implementor to determine if the most efficient way to accomplish this is via short code or inline parsing of the content (or both). |
|
@bep Ah, yes, I see. Can't believe I got slapped with the CB4C hand. I should know better. I guess my thought (since I'm not a golang programmer) was that somehow adding dimensions to the config would make the resizing less expensive. @spf13, so the output HTML (ie, taking your example) would still look like... <img src="/images/hero.w400-h500-c.jpg alt="Riveting photo of Bonnie Tyler in 1986"/>And the markdown as follows... And the static folder as.... After the resizing has been run? @kujohn I feel like I'm speaking out of turn on these suggestions since you're the one doing all the heavy lifting. Are these approaches in conflict with what you've already worked on? |
|
Yes, something along like that. I do want to avoid using static for this The initial idea behind static was that files are placed there that won't I've been thinking through two potential solutions for this. One is fairly straightforward. A new directory called assets for things to The other idea is a new approach to content where a directory represents a I'm not altogether against static either as we technically aren't modifying The right answer is likely a combination of these approaches (using our
|
|
@spf Hmmm. So... <--/content/articles/my-article-name.md-->
<!--http://mysite.com/articles/my-article-name/-->
<img src="hero.w400-h500-c.jpg/ alt="Riveting photo of Bonnier Tyler">
|
Many people would want this, but I think what we are talking about now should work for "both". As to the assets pipeline, this is a concept we don't have yet. I think the main issue here is: These are build products and should not live inside my Git repo. The above may be true for LESS and CSS files, too, but less obvious. So without caching, Hugo could write them directly to /public (or whatever the destination is). But since this is a potentially expensive operation, we should store them in /temp and only do a rebuild for the changed images. |
|
@rdwatters No worries, I think the work for parsing filename props and transforming of images can be carried over to what we ultimately decide to do. I haven't done any additional commits besides that. Thanks for asking! :) I think if we had an asset pipeline, that would be the perfect home for image transformation. But like what @bep said, it doesn't exist yet. I could give it a shot (with advisors and pointers) to try implementing an asset pipeline for image first. But I get the feeling that I may be too green to hugo's internals. In terms of image location, having them along side the post in a directory seems less of a mental overhead for the user. If we're using a central
Any tips on where |
We use it for the remote files cache and the Highlight cache, but we should clean up that thought, maybe .. |
digitalcraftsman
force-pushed
the
master
branch
from
49b4f8e to
93e41a1
Compare
|
I'm sorry that I have not followed up on these old pull requests. I appreciate the work put into this, but we will in the near future introduce "resource bundles" in Hugo, where this feature will fit more naturally in. |
|
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Looking for feedback on this image resizing/cropping feature #1014.
The image should sit right next to the markdown files with the syntax instruction based on this:
Example Usage:
Content Folder:
Shortcode Usage:
The use of
resizedImageshortcode is necessary to relatively reach the photo one folder back. It is due to howPagewrite destination is wrapped inside it's own folder.Output Public Folder:
There's a few things I plan on implementing:
index.htmlPlease provide feedback and guidance, happy holidays!