search

calibreapp / image-actions

A Github Action that automatically compresses JPEGs, PNGs and WebPs in Pull Requests.
https://calibreapp.com/blog/compress-images-in-prs
GNU General Public License v3.0
1.42k stars 67 forks source link

Add support for resizing images #60

Open kaycebasques opened 4 years ago

kaycebasques commented 4 years ago

On web.dev we never need images larger than 1600px. I frequently have to ask our contributors to resize their images (in order to keep the repository size down). Are you open to adding image resizing to image-actions or should we look for other solutions?

Edit: We never need images within our main content to be more than 1600px. There are a few exceptions we'd need to specify but I can share more details later.

crstauf commented 4 years ago

Related #20.

benschwarz commented 4 years ago

Hey @kaycebasques, actually — yes!

Since this was suggested back on #20, I've wondered how it could best work.

In my mind, it'd be great to be able to specify a directory, or path glob, along with resize settings. Some examples of that might be:

Something that gives me pause is being able to specify how cropping and other image resizing operations might be specified. However this gets implemented, my primary goal is to keep any required configuration super simple… but I feel we'll still be able to cover most common scenarios.

What do you think of all that?

tunetheweb commented 4 years ago

Think when you get into cropping you're asking for trouble.

One thing I'd like is just to ensure no one uploads a print quality 6000 x 3000 image when a 600 x 300 would do!

What about a max-width per folder?

E.g.

Or:

max-width_default: "600"
max-width_custom:
 1600:
  - "images/banners/"
max-width_exclusion:
  - "images/fullsize"
  - "images/**.XL.jpg"

Os something like that.

This would scale all images to 600px max width (with the appropriate height would be chosen to maintain aspect ratio) by default, however images/banners/banner1.jpg would instead be scaled to maximum of 1600px width, and images/fullsize/banner1.jpg would not be scaled at scaled at all and neither would images/folder/subfolder/photo.XL.jpg.

crstauf commented 4 years ago

An option to comment-only or keep the PR from merging if an image is found larger than max width would be nice.

Personally I'm hesitant to auto-resize images, but definitely see value in automating alerts and requests to contributors.

kaycebasques commented 4 years ago

Thanks for looking into this. Sorry for missing #20 (I recall searching for related issues… don't know how I missed that).

Here's our use case for web.dev:

@bazzadp's proposed config would probably work for us. Here's my first impression of an intuitive config:

max-width: 
  default: 1600
  input:
    - '/src/site/content/**'
  ignore:
    - '/src/site/content/**/hero.jpg' # or perhaps just 'hero.jpg'

I'm assuming it would automatically detect common image filename extensions.

tunetheweb commented 4 years ago

@kaycebasques alternatively if you also wanted to enforce the 3200px maximum width for hero images you could have this config like this under my proposal:

max-width: 
  default: 1600
  input:
    - '/src/site/content/**'
  custom:
    3200: 
      - '/src/site/content/**/hero.jpg' # or perhaps just 'hero.jpg'

That is provide a 3200 setting rather than ignoring it completely. Wouldn't enforce a 960px tall though and maybe overkill for your needs but throwing it out there.

tunetheweb commented 4 years ago

What would also be really cool (maybe as a stage two) would be to create alternative sizes/formats for scrset or picture elements:

alternatives:
  input:
    - **XL.jpg
  alt1:
    name: LG
    format: jpg
    width: 1600px
  alt2:
    name: MD
    format: jpg
    width: 800px
  alt3:
    name: SM
    format: jpg
    width: 400px
  alt4:
    name: LG
    format: png
    width: 1600px
  alt5:
    name: MD
    format: png
    width: 800px
  alt6:
    name: SM
    format: png
    width: 400px

So if you fed it a /src/site/content/article1/hero-XL.jpg it would automatically create the following images:

kaycebasques commented 4 years ago

@bazzadp that config for enforcing 3200px for the hero would work for us (probably)

I think I've represented our use case and requirements accurately but at this point I should CC @robdodson (our TL)

robdodson commented 4 years ago

I think as a start being able to request that all images that match a particular glob path can be proportionally resized would be good.

benschwarz commented 4 years ago

Thanks for sharing your config ideas @kaycebasques & @bazzadp. Unfortunately GitHub Actions doesn't support array objects so we'd need to come up with another way to specify configurations.

In general, I really like where this discussion is headed. Thanks for sharing your ideas 😎

What would also be really cool (maybe as a stage two) would be to create alternative sizes/formats for scrset or picture elements:

Yes! How great would that be!??

Maybe transcoding isn't something you'd want actively committed to a repo, but instead used in a more advanced pipeline that optimised images then packages/deploys in a following build step? 🤔 Either way. Sounds like a great addition.

petems commented 4 years ago

Hah, I was literally building something myself for this and realized that the awesome work in this action would be perfect for a few tweaks to reszing (Since sharp already has a super in-depth resizing feature: https://sharp.pixelplumbing.com/api-resize)

I was doing it in-place with mogrify: https://github.com/petems/img-resizer-inplace-limit

I was going to fork and hack it together myself, but if I can help in any way for this I'd be interested! 😄