# Attachment\_fu Not Resizing

**URL:** <https://www.ruby-forum.com/t/attachment-fu-not-resizing/90397>\
**Category:** Rails\
**Created:** [March 28, 2007, 12:45pm UTC](https://www.ruby-forum.com/t/attachment-fu-not-resizing/90397 "2007-03-28T12:45:50Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![starmaerker](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/e9bcb4/32.png) [@starmaerker](https://www.ruby-forum.com/u/starmaerker)\
**Post date:** [March 28, 2007, 12:45pm UTC](https://www.ruby-forum.com/t/attachment-fu-not-resizing/90397/1 "2007-03-28T12:45:50Z")

</div>

Hello,

Recently attachment\_fu stopped resizing images for me. I’m puzzled  
because before today it was resizing them and I don’t know what’s  
changed. Here’s my code:

class Product \< ActiveRecord::Base  
has\_attachment :content\_type =\> :image,  
:storage =\> :file\_system,  
:max\_size =\> 18.megabytes,  
:resize\_to =\> ‘300x’,  
:thumbnails =\> { :thumb =\> ‘61x110!’ }  
validates\_as\_attachment  
end

I expected a 420x595 image to be resized to 300xWhatever and a 61x110  
thumbnail to be created. The image and thumbnail product records  
were both created in the database but the images were left at the  
original size.

Strangely the width and height fields in the database are no longer  
being set. For new uploads they are null whereas previously they had  
been set to the measurements of the resized images.

I think I’ve traced the problem to this method (but I could equally  
well be barking up the wrong tree):

attachment\_fu/processors/rmagick\_processor.rb:

```
       module ClassMethods
       # Yields a block containing an RMagick Image for the given

```

binary data.  
def with\_image(file, &block)  
begin  
binary\_data = file.is\_a?(Magick::Image) ? file :  
Magick::Image.read(file).first unless !Object.const\_defined?(:Magick)  
puts “binary\_data.nil? : #{binary\_data.nil?}”  
puts “file.nil?: #{file.nil?}”  
puts “const\_defined? : #{Object.const\_defined?(:Magick)}”  
rescue  
# Log the failure to load the image. This should  
match ::Magick::ImageMagickError  
# but that would cause acts\_as\_attachment to require  
rmagick.  
logger.debug(“Exception working with image: #{$!}”)  
binary\_data = nil  
end  
block.call binary\_data if block && binary\_data  
ensure  
!binary\_data.nil?  
end  
end

The puts statements give this output:

binary\_data.nil? : true  
file.nil?: false  
const\_defined? : false

So it looks like the undefined constant prevents binary\_data from  
being assigned. But I don’t know what to do about this.

I’d appreciate any help.

Thanks and regards,  
Andy S.

---

<div class="post-metadata">

**Author:** ![starmaerker](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/e9bcb4/32.png) [@starmaerker](https://www.ruby-forum.com/u/starmaerker)\
**Post date:** [March 28, 2007, 1:04pm UTC](https://www.ruby-forum.com/t/attachment-fu-not-resizing/90397/2 "2007-03-28T13:04:54Z")

</div>

On Mar 28, 2007, at 12:43 PM, Andrew S. wrote:

> So it looks like the undefined constant prevents binary\_data from  
> being assigned. But I don’t know what to do about this.

Just in case it helps you moving on in the development while this is  
understood, I found by chance that minimagick (which is enough for  
me) works fine.

– fxn

---

<div class="post-metadata">

**Author:** ![starmaerker](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/e9bcb4/32.png) [@starmaerker](https://www.ruby-forum.com/u/starmaerker)\
**Post date:** [March 28, 2007, 1:21pm UTC](https://www.ruby-forum.com/t/attachment-fu-not-resizing/90397/3 "2007-03-28T13:21:58Z")

</div>

On 28 Mar 2007, at 11:54, Xavier N. wrote:

> Just in case it helps you moving on in the development while this is  
> understood, I found by chance that minimagick (which is enough for  
> me) works fine.

Thanks for the suggestion.

RMagick does still work for me when I call it from straight Ruby –  
which is what I am doing manually to resize images until my problem  
is fixed. This code looks like:

require ‘rubygems’  
require ‘RMagick’

…

img = Magick::Image.read(image\_file).first # image\_file defined  
above in snipped code  
img.change\_geometry(“300x”) do |cols, rows, img|  
img.resize(cols, rows)  
end

So I think my RMagick installation is still okay…

Thanks for taking the time to reply (and sorry about my double post  
with slightly different titles…user malfunction!).

Regards,  
Andy S.

---

<div class="post-metadata">

**Author:** ![starmaerker](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/e9bcb4/32.png) [@starmaerker](https://www.ruby-forum.com/u/starmaerker)\
**Post date:** [May 30, 2007, 9:03am UTC](https://www.ruby-forum.com/t/attachment-fu-not-resizing/90397/4 "2007-05-30T09:03:22Z")

</div>

Andrew are you devving on win xp? Incase others are finding this problem  
thought i would mention that Heggie (of heggie.biz) discovered a  
windows race condition bug with this plugin. He got some of it fixed  
before we reverted back to acts\_as\_attachment for [artabase.net](http://artabase.net)

The problem seems to be with the plugin looking in the file system for  
the file size, which isn’t available immediately due to win xp taking a  
few seconds to update it.

R.Cannon

Andrew S. wrote:

> Hello,
> 
> Recently attachment\_fu stopped resizing images for me. I’m puzzled  
> because before today it was resizing them and I don’t know what’s  
> changed. Here’s my code:
> 
> class Product \< ActiveRecord::Base  
> has\_attachment :content\_type =\> :image,  
> :storage =\> :file\_system,  
> :max\_size =\> 18.megabytes,  
> :resize\_to =\> ‘300x’,  
> :thumbnails =\> { :thumb =\> ‘61x110!’ }  
> validates\_as\_attachment  
> end
> 
> I expected a 420x595 image to be resized to 300xWhatever and a 61x110  
> thumbnail to be created. The image and thumbnail product records  
> were both created in the database but the images were left at the  
> original size.
> 
> Strangely the width and height fields in the database are no longer  
> being set. For new uploads they are null whereas previously they had  
> been set to the measurements of the resized images.  
> …