Getting width and height of attachment

[pimpmaster]

I just realized that Paperclip doesn't provide image dimensions.

Is this an intentional omission? Are there plans to add this feature
in the future?

[edgarjs]

I was thinking the same... so I came up with a little initializer. Not
sure if there is an easier way to do this but it works in the
meantime:

module Paperclip
class Attachment
def width(style = default_style)
Paperclip::Geometry.from_file(to_file(style)).width
end

def height(style = default_style)
Paperclip::Geometry.from_file(to_file(style)).height
end
end
end

And now you can get the width and height for each of your styles:

@my_model.my_img.width # => returns the original width
@my_model.my_img.width(:thumb) # => returns the width for the :thumb
style

And of course you can also get the other Geometry instance methods
like 'square?', 'horizontal?' and so on.

I'm quite sure there must be an easier (and implemented) way to get
these...

Regards.

[pimpmaster]

Hey edgar, a belated THANK YOU for posting this code.

I am curious what the "official" way of doing this is, but your method
is working for now.

Cheers!

[Jonathan Yurek]

While this works, I should note that this code is very very
inefficient as it shells out to identify each time it's called.
Calling shell commands, especially repeatedly, isn't the most
efficient thing to be doing (which is why we try to keep it to 1 call
per style).

--
Jonathan Yurek, Founder and CTO
thoughtbot, inc.
organic brains. digital solutions.

617.482.1300 x114
http://www.thoughtbot.com/

[pimpmaster]

Is there any way I can setup Paperclip to write these attributes to
the database instead then?

Or perhaps there is a way to read the size hashes from the model??

[Lagarto Flojo]

I'm thinking you could add the "width" and "height" columns to your
model, then add to your model file a before_save like this:

before_save :save_dimensions

def save_dimensions
self.width = Paperclip::Geometry.from_file(to_file(style)).width
self.height =
Paperclip::Geometry.from_file(to_file(style)).height
end

[Felipe Elias]

You could use this as an initializer.

http://gist.github.com/10790

[Henrik N]

I just added image dimension support (with tests) and pushed to my
github: http://github.com/henrik/paperclip/tree/master

Note that I have three unrelated (but useful) commits between current
thoughtbot/master and my dimension commits.

Assuming a paperclip named "avatar", you get support for dimensions if
you have avatar_width and avatar_height columns in the model. The
original dimensions of the file are stored there on upload.

The attachment gets the methods "width", "height", "size" (e.g.
"50x50") and a couple of methods from Geometry like "square?".

"width", "height" and "size" take an optional style name (e.g.
"user.avatar.size(:medium)") and will give dimensions for that style.
I'm using some code from attachment_fu to calculate those dimensions
from the original dimensions without having to shell out. The results
are memoized, too.

[Henrik N]

I just used the dimension stuff in my app. Had only relied on the
tests previous to this.

Two issues I had:

1. Since I use SWFUpload (a Flash uploader), the MIME type was
application/octet-stream, and so Paperclip didn't think it was an
image, and so it didn't even try to get the dimensions. Fixed this by
using the mimetype_fu plugin (http://github.com/mattetti/mimetype-fu).

2. Even with the right mimetype, "identify" wasn't in the path. Worked
fine in console but not running in Passenger, so I had to set
the :image_magick_path explicitly.

I did both those things with this in an initializer (evil-twin plugin
works also): http://pastie.textmate.org/pastes/311261

[Thomas]

> > I just added image dimension support (with tests) and pushed to my
> > github:http://github.com/henrik/paperclip/tree/master
>

Hi Henrik,

I pulled your fork, and I was able to easily add automatic assignment
of width and height to images. Now I would like to do the same for flv
videos, but I have been running into problems:

1) Inside Geometry, why can't I write to the logger? How can I do
debugging in such case?
2) My Rails app handles multi-site setups, so when running flvtool2 at
the command line to retrieve the width and height of a video, I need
to also pass the value of request.domain from the controller to the
call to flvtool2 as each site has its own separate folder for videos,
how can I add such attribute to the uploaded_file object?

Best regards,

[Thomas]

> 1. Since I use SWFUpload (a Flash uploader), theMIMEtype was

> application/octet-stream, and so Paperclip didn't think it was an
> image, and so it didn't even try to get the dimensions. Fixed this by
> using the mimetype_fu plugin (http://github.com/mattetti/mimetype-fu).
>

And thanks for pointing out mimetype-fu, it works like a charm :D

[LesC]

Hi Henrik,

I've tried using your fork, but for some reason the files that are
written to the file system have got strange permissions set on them -
the folders are all readable by everyone, but the actual files are
readable only by my admin user.

Do you know what might cause this, and how to get round it?

Oh and does anyone know when the ability to save the width and height
details into the model will make it into the trunk of Paperclip? It's
a very useful addition!

Cheers

L

[Kennon Ballou]

Not to fight with Henrik, but I merged alot of his extension for
height/width saving and tried to match the style of the existing
paperclip master and left out a few of his other extensions that are
great but don't apply directly to height/width.

You can check out my fork here:
http://github.com/kennon/paperclip/tree/master

Sorry Henrik, just wanted to try to fit the existing coding style a bit
and clean up the code a bit as well :)

KB

[Henrik Nyh]

Kennon, no problem. My fork has been falling behind the paperclip
master for a while now, so I'm glad someone else has had time to keep
it current and improve it. Haven't looked at your fork yet. Does it
support getting width and height for other styles than original?

It'd be great if Thoughtbot could merge your stuff, or some other
width/height additions, so they don't fall behind again, and so
everyone can improve on the same codebase.

Jonathan, could you give your opinion on that? Are you fine with
adding support for image width/height to Paperclip? Anything you'd
like fixed in Kennon's implementation before it can be merged?

[Kennon Ballou]

Yes, my fork supports widths/heights for styles.

The one thing that I just thought of, however, is if you overwrite the
:original style, querying width/height is going to return the actual
original height/width of the file and not the new :original style
height/width. I'll have to check to see if there is an easy way around
that (it probably just needs to rewrite height/width if there is an
:original style)

It also only calculates width/height if you have the corresponding
fields in the table - so for existing deploys it should just fail
gracefully.

(my fork also has tests, but please feel free to add more if you can
think of situations where my code might break, especially with existing
deploys)

KB

[LesC]

Kennon,

Thank you! Your fork did the trick, and has properly saved my bacon!!

Note for anyone else slightly dim like me, the width and height
columns need to be integers (duh!) otherwise it'll throw an error when
you try to get the styles width or height.

Cheers

L

On Jan 8, 3:02 pm, Kennon Ballou <ken...@angryturnip.com> wrote:
> Yes, my fork supports widths/heights for styles.
>
> The one thing that I just thought of, however, is if you overwrite the

> :original style, queryingwidth/heightis going to return the actual
> originalheight/widthof the file and not the new :original styleheight/width. I'll have to check to see if there is an easy way around
> that (it probably just needs to rewriteheight/widthif there is an
> :original style)
>
> It also only calculateswidth/heightif you have the corresponding

[Kennon Ballou]

You're welcome :) Now if we can only see about getting it merged into
master ... *wink*

KB

p.s. Which errors did you get with non-integer width/height fields? Some
sort of arithmatic error trying to compare with a string?

[pie...@tiiptop.com]

Thanks Kennon !
I can't wait to see your changes in the master.

Pierre

[Sebastian Deutsch]

Hi,

with the suggested snippet the identify command tages ages and when I
force a close on the dev server I get the following error message

Paperclip::NotIdentifiedByImageMagickError ( is not recognized by the
'identify' command.):
/vendor/plugins/paperclip/lib/paperclip/geometry.rb:24:in `from_file'
/app/models/image.rb:6:in `width'
/app/models/image.rb:58:in `all_scape_images_as_flash_object'
/app/controllers/images_controller.rb:17:in `index'

any ideas?

*.sebastian

pie...@tiiptop.com schrieb:

--
Sebastian Deutsch
---------------------------------------------------------------
www.9elements.com
Kortumstr. 19-21
44787 Bochum
Tel: 0234 - 689 41 88
Mobil.: 0177 - 331 21 98
Skype: sebastian.deutsch
Xing: https://www.xing.com/profile/Sebastian_Deutsch
--------------------------------------------------------------------------

[hors...@googlemail.com]

Hi,

I needed to get the image dimensions too. I don't know if it will be
of use to anyone else, but the approach I took was subclass the
Thumbnail processor and store the dimensions in the width and height
columns I added to the model to which I'm attaching files. Like this:

http://gist.github.com/66415

In a rails app you can save this as lib/paperclip/
thumbnail_with_dimensions.rb then update your model to use the
processor as follows

class MyModel < ActiveRecord::Base
has_attached_file :attachment, :processors =>
[:thumbnail_with_dimensions]
end

Cheers
Paul


On Jan 28, 3:52 am, Sebastian Deutsch <sebastian.deut...@gmail.com>
wrote:

[Olly Lylo]

This is a neat solution. I'd like to do a similar thing, but rather
than storing the dimensions of the original image, I'd like to store
the dimensions of the thumbnail:

has_attached_file :logo, :styles => { :screen =>
["300x75>", :png] },

Would you be able to explain how I might do that?




On Feb 18, 5:11 pm, "horsfa...@googlemail.com"

[pimpmaster]

Nice fork guys!!

Any chance this will makes its way into master??

+1 vote here

[Jonathan Yurek]

Here's the thing about storing style sizes...

I really want to do this, as it's a very requested feature. However, I
don't want to have image size calculations in Ruby. I feel it's simply
an area that's prone to error, and simply doesn't belong in the code,
considering the farming-out of all image-related activity. Paperclip
isn't an image processor, it just talks to one.

However, calling identify each time you call #dimensions is
inefficient, and I do already do square cropping calculations
(although this one's because IM didn't do this one until the advent of
the ^ geometry modifier), so there is a history of calculations in the
plugin.

I think I may run some tests to see if calling out to identify is
performant at all, because, in all honesty that's the route I'd rather
go (if feasible).

[Kennon Ballou]

That's an excellent point, but we're already storing the content type
(which technically could be determined by identify as well).

It is a good point that putting something like width/size directly into
the attachment code makes it more image specific, but it seems to be a
very common case and something that would make sense as optional.

| Kennon Ballou
| Angry Turnip, Inc.

[Jonathan Yurek]

Don't get me wrong. I'm opposed to neither extra optional columns nor
image-specific columns. I'm (mostly) against doing the calculations
for the geometries "by hand" in the plugin.

(also, we have the content_type because it's supplied by Rails and
part of the HTTP upload, and since not all uploads are images, we may
not be able to get it with a commandline tool)

[Steven Garcia]

Kennon's fork is awesome - I still think it deserves to be merged as
there is enough of a demand for basic functionality.

As long as you encourage folks to store the values in magical db
fields (attachment_width, attachment_height) then you completely avoid
the problems associated by calling shell concurrently.

Your call though