Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Call strip on thumbnails to reduce their size #2261

Merged
merged 3 commits into from
Jun 5, 2013

Conversation

gwagener
Copy link
Contributor

@gwagener gwagener commented May 8, 2013

This can cut the size of 300x200 thumbnails in half. I'm curious to get feedback on whether people think this is a good idea as thumbnail gets used by image_fu and people might use that with much larger geometries. I'm not sure if there would be cases where people would notice the lack of color profiles and whatever else strip cuts out.

end
thumbnail.strip
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In terms of factoring the code have you considered the following:

thumbnail = image
thumbnail = thumbnail.thumb(geometry) if geometry.present? && !geometry.is_a?(Symbol)
thumbnail.strip

I'm not advocating for it being better but it feels like it might be.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One thing I thought is make the the strip a configuration option passed to the thumbnail method.. and then image_fu can be configurable too. I'd consider changing the API to:

def thumbnail(options = {})
  options = {:geometry => options} if options.is_a?(String) # AND deprecation warning here.
  options = {:geometry => nil, :strip => true}.merge(options)

  # ...
end

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually tried that exact code but decided the middle line was too long. I'm not sure if I like that style in general or not, but in this case I'm happy with whichever people want.

Probably a better option would be to move some of it out into different methods and have the body of this one be something like

resize_image(parse_geometry(geometry)).strip

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That refers to the first comment only.

@parndt
Copy link
Member

parndt commented May 16, 2013

Are you still happy with this solution?

@gwagener
Copy link
Contributor Author

I think I managed to improve it quite a bit. Thanks for the feedback :)

def thumbnail(options = {})
if options.is_a?(String) || options.is_a?(Symbol)
Refinery.deprecate 'Refinery::Image#thumbnail(geometry)',
:replacement => 'Refinery::Image#url(:geometry => value)'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you add :when here and set it to 2.2? Thanks!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also shouldn't Refinery::Image#url be Refinery::Image#thumbnail instead?

@ugisozols
Copy link
Member

Looks good and with a changelog entry it would be even more awesome :)

@ugisozols ugisozols merged commit 9b16e49 into refinery:master Jun 5, 2013
@ugisozols
Copy link
Member

Merged. Thanks!

@0xl3x1
Copy link

0xl3x1 commented Nov 22, 2013

I'm not sure if there would be cases where people would notice the lack of color profiles and whatever else strip cuts out.

GRR >:|

@parndt
Copy link
Member

parndt commented Nov 22, 2013

I take it you don't like it. Want to make it configurable or something?

@0xl3x1
Copy link

0xl3x1 commented Nov 23, 2013

@parndt I spent a couple of hours debugging my way to this issue, trying to figure out why the fridging Exif data was being stripped from all the JPEGs being resized with Refinery::Image#thumbnail (I knew that the newer versions of ImageMagick don't strip Exif data by default).

Fortunately it's already configurable (see 16c013b), so adding strip: false to the Refinery::Image#thumbnail call fixed the issue.

@0xl3x1
Copy link

0xl3x1 commented Nov 23, 2013

@parndt I do wonder whether strip: true should be the default though. Clearly it has potential to cause unexpected behaviours.

@parndt
Copy link
Member

parndt commented Nov 24, 2013

Probably we shouldn't have unexpected behaviour by default. What do you think, @gwagener & @ugisozols ?

@gwagener
Copy link
Contributor Author

I think when you call ImageMagick thumbnail on the command line it strips the metadata, but in dragonfly it doesn't so these changes make Refinery behave like the command line. Someone will have to check that, but I think that's what I figured out when I was investigating why I didn't get the same results for thumbnails in Refinery as I did on the command line.

@gwagener
Copy link
Contributor Author

Looking at previous comments it's possible I was using an older version if ImageMagick when I did this stuff.

@0xl3x1
Copy link

0xl3x1 commented Nov 25, 2013

@gwagener The newer versions of ImageMagick don't strip metadata unless you specify -strip on the command line (see this comment on Stack Overflow, which seems to point to a bug in some older ImageMagick versions).

Dragonfly::ImageMagick::Processor#strip just adds -strip to the command line call (see here).

@ugisozols
Copy link
Member

The newer versions of ImageMagick don't strip metadata unless you specify -strip on the command line.

If that's the case then we need to set strip option to false by default to avoid unexpected behaviour.

@benjaminbrent keen to send a PR?

@0xl3x1
Copy link

0xl3x1 commented Nov 25, 2013

@benjaminbrent keen to send a PR?

@ugisozols I'll do that. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants