RMagick can not read remote image - imagemagick

My env is Linux centos, and use ruby 1.8.7, and the code is here below:
require 'rubygems'
require 'RMagick'
Magick::Image.read("http://image.domain.com/image.darenhui.com/images/random_bg/01.jpg")[0]
it throws error like below:
in `read': no decode delegate for this image format `//image.domain.com/images/random_bg/01.jpg' # error/constitute.c/ReadImage/532 (Magick::ImageMagickError),
but if i read from local like:
require 'rubygems'
require 'RMagick'
Magick::Image.read("/local/staticimages/random_bg/01.jpg")[0]
everything is ok.
I run identify -list format and see below:
JPEG* JPEG rw- Joint Photographic Experts Group JFIF format (62)
JPG* JPEG rw- Joint Photographic Experts Group JFIF format (62)
but when i test by identity for "http://image.domain.com/image.darenhui.com/images/random_bg/01.jpg" to fail, but success for "/local/staticimages/random_bg/01.jpg"
Can someone give me some clue? thank you in advance.

Magick::Image.read does not support URL links. But you can read the remote image using ruby open method:
require 'rubygems'
require 'RMagick'
require "open-uri"
image = Magick::ImageList.new
urlimage = open("http://www.jewelinfo4u.com/images/Gallery/ruby.jpg") # Image Remote URL
image.from_blob(urlimage.read)
# crop = image.crop(10,10,200,300) You can crop this image too
# crop.write('C:/nameofyourNewImage.jpg') If you want to save the image you can use this line in windows

Fast forward to May 2014, and I'm able to just...
require 'rubygems'
require 'RMagick'
include Magick
image = ImageList.new("http://www.jewelinfo4u.com/images/Gallery/ruby.jpg")
And it just works. Feels good.
(Tested on ImageMagick 6.8.8-9 Q16)
EDIT: Does not seem work on Heroku Cedar stack (ImageMagick 6.5.7-8 2012-08-17 Q16) though. :/

As far as I can see Magick::Image.read does NOT support URLs, only files/file handles - see http://www.imagemagick.org/RMagick/doc/image1.html#read where it says that it
Reads all the images from the specified file.
It is implemented by the C function ReadImage which does not support URLs - see the ImageMagick source at line 394 here.
IF you want to open an image from a URL you need to download the image somehow - to a file or a stream... then you can feed that file or stream to Magick...

You can read a file from a url with open-uri, then feed that into Rmagick's Image::from_blob.
Example:
require 'open-uri'
require 'rubygems'
require 'Rmagick'
image_url = 'http://example.com/image.jpg'
image = Magick::Image.from_blob(open(image_url).read).first
Note that you should additionally take care to handle exceptions arising from the open HTTP request. Ie, what happens if you get a 404, or a non-image response?

As of rmagick (4.1.2), Image.read does support URL links. In my case, I was reading an image, specifically a png file from AWS S3. This was via localhost. Updating to the latest version should fix this problem.

Related

Convert Dicom Image to JPG

I am trying to convert a dicom file to JPG which I would then use to show as thumbnail for the dicom file. I am using the code below to convert the dicom file but When I execute it I get the following error
'write': no encode delegate for this image format `' # error/constitute.c/WriteImage/1272 (Magick::ImageMagickError)
I am using ruby version 2.7.0 and I have installed ImageMagick 7.1.0-4 and the supportive gems. How to solve this error?
require 'dicom'
require 'rmagick'
include DICOM
dcm = DObject.read("sample.dcm")
image = dcm.image(:frame => 5)
image.normalize.write("test.jpeg");
I had to reinstall ImageMagick-7.1.0-26 along with libgdcm-tools on my system and the above mentioned code worked fine. So Imagemagick needs these additional libraries (libjpeg62-dev, libtiff-dev, libpng-dev, libpng12-0 and libgdcm-tools) to work with these image types. I don't know if this is correct or not but that the problem I was facing has been resolved by following this approach. Here are some of the links which helped me in solving this
Install ImageMagick with JPG TIFF and PNG Delegates
How to configure and build with libgcdm for lossless jpeg conversion
and dicom support

Rails: Received string from web service should be converted to a pdf image to be displayed

When using a web service I receive a string that looks like this:
JVBERi0xLjIgDQoxIDAgb2JqDQo8PA0KL1R5cGUgL0NhdGFsb2cNCi9QYWdlcyAzIDAgUg0KL1BhZ2VNb2RlIC9Vc2VOb25lDQovUGFnZUxheW91dCAvU2luZ2xlUGFnZQ0KPj4NCmVuZG9iag0KMiAwIG9iag0KPDwNCi9Qcm9kdWNlciAoUGRmQ3JlYXRvciB2ZXJzaW9uIDEuMCkNCi9BdXRob3IgKCkNCi9DcmVhdGlvbkRhdGUgKEQ6MjAxNzA4MjUxMTM0MDApDQovQ3JlYXRvciAoKQ0KL0tleXdvcmRzICgpDQovU3ViamVjdCAoKQ0KL1RpdGxlICgpDQovTW9kRGF0ZSAoRDoyMDE3MDgyNTExMzQwMCkNCj4+DQplbmRvYmoNCjMgMCBvYmoNCjw8DQovVHlwZSAvUGFnZXMNCi9LaWRzIFs0IDAgUiBdDQovQ291bnQgMQ0KPj4NCmVuZG9iag0KNCAwIG9iag0KPDwNCi9UeXBlIC9QYWdlDQovUGFyZW50IDMgMCBSDQovTWVkaWFCb3ggWzAgMCA0MjUgMjkyIF0NCi9SZXNvdXJjZXMgPDwNCi9Gb250IDw8DQovRjAgNiAwIFINCi9GMSA4IDAgUg0KPj4NCi9YT2JqZWN0IDw8DQovMCA3IDAgUg0KPj4NCi9Qcm9jU2V0IFsvUERGIC9UZXh0IC9JbWFnZUMgXQ0KPj4NCi9Db250ZW50cyA1IDAgUg0KPj4NCmVuZG9iag0KNSAwIG9iag0KPDwNCi9MZW5ndGggNDE4DQovRmlsdGVyIFsvRmxhdGVEZWNvZGUgXQ0KPj4NCnN0cmVhbQ0KeF6lVMtu2zAQvPMr9tjmwHCXD1G9uXkiCBI3VtND0YNj0akL20ppGQX69V1Slp2iRWI4ECCMRHJmd2ek43MFpSwsVFORMKqEFKQrPoqPlUCpFD89u3dvtHe820g+uhDvEE6a+bx5D9UPcVbtCBAl8Y7rl5k8kKYN0+D+omf5+k1BLbQpgbyFhTBoMpp3yDlGeTWjrui7C4HwS6z264EPUtErn8fxcrJtoRMnVQBRmcV5L6Mkzp2jZ5RWO7QVV3uLI4tjP78jPTo9uz+xxnhntTNH/Qx+CnJWKpObs066EpyXSgNZaQ1MFuJYwWkjPmX7/F/ula8MPg+RJGUHB9PfYVmH+OEfD1+jyTNi/zqe4e2ournuSf6TqX0ikSoz5SYRw2bV7hi32dyXRxcbntEsztarOoYwBUMwOCisqTJyG0ZCTV8quGyaaV038ekgRuJvjtC/vdlMpPrahqENEeoAd+sZo4NLw5KDlp29nddh+bCOjyGu2jget4C62BmNgJyAZz8P1Ongi59+Khk9Ss4tC2hb6NEVfG5jmHxve+Y/1ub6WwplbmRzdHJlYW0NCmVuZG9iag0KNiAwIG9iag0KPDwNCi9UeXBlIC9Gb250DQovU3VidHlwZSAvVHlwZTENCi9GaXJzdENoYXIgMzINCi9MYXN0Q2hhciAyNTUNCi9CYXNlRm9udCAvSGVsdmV0aWNhDQovRW5jb2RpbmcgPDwNCi9UeXBlIC9FbmNvZGluZw0KL0RpZmZlcmVuY2VzIFszMiAvc3BhY2UgMTk2IC9BZGllcmVzaXMgMjE0IC9PZGllcmVzaXMgMjIwIC9VZGllcmVzaXMgMjI4IC9hZGllcmVzaXMgMjQ2IC9vZGllcmVzaXMgMjUyIC91ZGllcmVzaXMgMjIzIC9nZXJtYW5kYmxzIDE5MiAvQWdyYXZlIDE5NCAvQWNpcmN1bWZsZXggMTk4IC9BRSAxOTkgL0NjZWRpbGxhIDIwMCAvRWdyYXZlIDIwMSAvRWFjdXRlIDIwMiAvRWNpcmN1bWZsZXggMjAzIC9FZGllcmVzaXMgMjA2IC9JY2lyY3VtZmxleCAyMDcgL0lkaWVyZXNpcyAyMTIgL09jaXJjdW1mbGV4IDE0MCAvT0UgMjE3IC9VZ3JhdmUgMjE5IC9VY2lyY3VtZmxleCAxNTkgL1lkaWVyZXNpcyAyMjQgL2FncmF2ZSAyMjYgL2FjaXJjdW1mbGV4IDIzMCAvYWUgMjMxIC9jY2VkaWxsYSAyMzIgL2VncmF2ZSAyMzMgL2VhY3V0ZSAyMzQgL2VjaXJjdW1mbGV4IDIzNSAvZWRpZXJlc2lzIDIzOCAvaWNpcmN1bWZsZXggMjM5IC9pZGllcmVzaXMgMjQ0IC9vY2lyY3VtZmxleCAxNTYgL29lIDI0OSAvdWdyYXZlIDI1MSAvdWNpcmN1bWZsZXggMjU1IC95ZGllcmVzaXMgMTk3IC9BcmluZyAyMTYgL09zbGFzaCAxOTMgL0FhY3V0ZSAyMDUgL0lhY3V0ZSAyMTggL1VhY3V0ZSAyMjEgL1lhY3V0ZSAyMjkgL2FyaW5nIDI0OCAvb3NsYXNoIDIyNSAvYWFjdXRlIDIzNyAvaWFjdXRlIDI1MCAvdWFjdXRlIDI1MyAveWFjdXRlIDIxMCAvT2dyYXZlIDI0MiAvb2dyYXZlIDIwNCAvSWdyYXZlIDIzNiAvaWdyYXZlIDE5NSAvQXRpbGRlIDIxMyAvT3RpbGRlIDIyNyAvYXRpbGRlIDI0NSAvb3RpbGRlIDIyMiAvVGhvcm4gMjU0IC90aG9ybiAyMDkgL050aWxkZSAyNDEgL250aWxkZSAxMzggL1NjYXJvbiAxNTQgL3NjYXJvbiAyNDMgL29hY3V0ZSAyMTEgL09hY3V0ZSBdDQo+Pg0KL1dpZHRocyBbMjc4IDI3OCAzNTUgNTU2IDU1NiA4ODkgNjY3IDE5MSAzMzMgMzMzIDM4OSA1ODQgMjc4IDMzMyAyNzggMjc4IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiAyNzggMjc4IDU4NCA1ODQgNTg0IDU1NiAxMDE1IDY2NyA2NjcgNzIyIDcyMiA2NjcgNjExIDc3OCA3MjIgMjc4IDUwMCA2NjcgNTU2IDgzMyA3MjIgNzc4IDY2NyA3NzggNzIyIDY2NyA2MTEgNzIyIDY2NyA5NDQgNjY3IDY2NyA2MTEgMjc4IDI3OCAyNzggNDY5IDU1NiAzMzMgNTU2IDU1NiA1MDAgNTU2IDU1NiAyNzggNTU2IDU1NiAyMjIgMjIyIDUwMCAyMjIgODMzIDU1NiA1NTYgNTU2IDU1NiAzMzMgNTAwIDI3OCA1NTYgNTAwIDcyMiA1MDAgNTAwIDUwMCAzMzQgMjYwIDMzNCA1ODQgMCA1NTYgMCAyMjIgNTU2IDMzMyAxMDAwIDU1NiA1NTYgMzMzIDEwMDAgNjY3IDMzMyAxMDAwIDAgNjExIDAgMCAyMjIgMjIyIDMzMyAzMzMgMzUwIDU1NiAxMDAwIDMzMyAxMDAwIDUwMCAzMzMgOTQ0IDAgNTAwIDY2NyAwIDY2NyA1NTYgNTU2IDU1NiA1NTYgNjY3IDU1NiAzMzMgNzM3IDM3MCA1NTYgNjExIDAgNzM3IDYxMSA0MDAgNTU2IDMzMyAyMjIgMzMzIDU1NiA1MDAgMzMzIDMzMyAyNzggMzY1IDU1NiA1MDAgODM0IDgzNCA1MDAgNjY3IDY2NyA2NjcgNjY3IDY2NyA2NjcgMTAwMCA3MjIgNjY3IDY2NyA2NjcgNjY3IDI3OCAyNzggMzMzIDMzMyA3MjIgNzIyIDc3OCA3NzggNzc4IDc3OCA3NzggNTg0IDc3OCA3MjIgNzIyIDcyMiA3MjIgNjY3IDY2NyA2MTEgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgODg5IDUwMCA1NTYgNTU2IDU1NiA1NTYgMjc4IDI3OCAzMzMgMzMzIDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1ODQgNjExIDU1NiA1NTYgNTU2IDU1NiA1MDAgNTU2IDUwMCBdDQovTmFtZSAvRjANCj4+DQplbmRvYmoNCjcgMCBvYmoNCjw8DQovTGVuZ3RoIDE2Mg0KL0ZpbHRlciBbL0ZsYXRlRGVjb2RlIF0NCi9UeXBlIC9YT2JqZWN0DQovU3VidHlwZSAvSW1hZ2UNCi9Db2xvclNwYWNlIFsvSW5kZXhlZCAvRGV2aWNlUkdCIDIyMyA8MDAwMDAwIDAwMDAzMyAwMDAwNjYgMDAwMDk5IDAwMDBjYyAwMDAwZmYgMDAzMzAwIDAwMzMzMyAwMDMzNjYgMDAzMzk5IDAwMzNjYyAwMDMzZmYgMDA2NjAwIDAwNjYzMyAwMDY2NjYgMDA2Njk5IDAwNjZjYyAwMDY2ZmYgMDA5OTAwIDAwOTkzMyAwMDk5NjYgMDA5OTk5IDAwOTljYyAwMDk5ZmYgMDBjYzAwIDAwY2MzMyAwMGNjNjYgMDBjYzk5IDAwY2NjYyAwMGNjZmYgMDBmZjAwIDAwZmYzMyAwMGZmNjYgMDBmZjk5IDAwZmZjYyAwMGZmZmYgMzMwMDAwIDMzMDAzMyAzMzAwNjYgMzMwMDk5IDMzMDBjYyAzMzAwZmYgMzMzMzAwIDMzMzMzMyAzMzMzNjYgMzMzMzk5IDMzMzNjYyAzMzMzZmYgMzM2NjAwIDMzNjYzMyAzMzY2NjYgMzM2Njk5IDMzNjZjYyAzMzY2ZmYgMzM5OTAwIDMzOTkzMyAzMzk5NjYgMzM5OTk5IDMzOTljYyAzMzk5ZmYgMzNjYzAwIDMzY2MzMyAzM2NjNjYgMzNjYzk5IDMzY2NjYyAzM2NjZmYgMzNmZjAwIDMzZmYzMyAzM2ZmNjYgMzNmZjk5IDMzZmZjYyAzM2ZmZmYgNjYwMDAwIDY2MDAzMyA2NjAwNjYgNjYwMDk5IDY2MDBjYyA2NjAwZmYgNjYzMzAwIDY2MzMzMyA2NjMzNjYgNjYzMzk5IDY2MzNjYyA2NjMzZmYgNjY2NjAwIDY2NjYzMyA2NjY2NjYgNjY2Njk5IDY2NjZjYyA2NjY2ZmYgNjY5OTAwIDY2OTkzMyA2Njk5NjYgNjY5OTk5IDY2OTljYyA2Njk5ZmYgNjZjYzAwIDY2Y2MzMyA2NmNjNjYgNjZjYzk5IDY2Y2NjYyA2NmNjZmYgNjZmZjAwIDY2ZmYzMyA2NmZmNjYgNjZmZjk5IDY2ZmZjYyA2NmZmZmYgOTkwMDAwIDk5MDAzMyA5OTAwNjYgOTkwMDk5IDk5MDBjYyA5OTAwZmYgOTkzMzAwIDk5MzMzMyA5OTMzNjYgOTkzMzk5IDk5MzNjYyA5OTMzZmYgOTk2NjAwIDk5NjYzMyA5OTY2NjYgOTk2Njk5IDk5NjZjYyA5OTY2ZmYgOTk5OTAwIDk5OTkzMyA5OTk5NjYgOTk5OTk5IDk5OTljYyA5OTk5ZmYgOTljYzAwIDk5Y2MzMyA5OWNjNjYgOTljYzk5IDk5Y2NjYyA5OWNjZmYgOTlmZjAwIDk5ZmYzMyA5OWZmNjYgOTlmZjk5IDk5ZmZjYyA5OWZmZmYgY2MwMDAwIGNjMDAzMyBjYzAwNjYgY2MwMDk5IGNjMDBjYyBjYzAwZmYgY2MzMzAwIGNjMzMzMyBjYzMzNjYgY2MzMzk5IGNjMzNjYyBjYzMzZmYgY2M2NjAwIGNjNjYzMyBjYzY2NjYgY2M2Njk5IGNjNjZjYyBjYzY2ZmYgY2M5OTAwIGNjOTkzMyBjYzk5NjYgY2M5OTk5IGNjOTljYyBjYzk5ZmYgY2NjYzAwIGNjY2MzMyBjY2NjNjYgY2NjYzk5IGNjY2NjYyBjY2NjZmYgY2NmZjAwIGNjZmYzMyBjY2ZmNjYgY2NmZjk5IGNjZmZjYyBjY2ZmZmYgZmYwMDAwIGZmMDAzMyBmZjAwNjYgZmYwMDk5IGZmMDBjYyBmZjAwZmYgZmYzMzAwIGZmMzMzMyBmZjMzNjYgZmYzMzk5IGZmMzNjYyBmZjMzZmYgZmY2NjAwIGZmNjYzMyBmZjY2NjYgZmY2Njk5IGZmNjZjYyBmZjY2ZmYgZmY5OTAwIGZmOTkzMyBmZjk5NjYgZmY5OTk5IGZmOTljYyBmZjk5ZmYgZmZjYzAwIGZmY2MzMyBmZmNjNjYgZmZjYzk5IGZmY2NjYyBmZmNjZmYgZmZmZjAwIGZmZmYzMyBmZmZmNjYgZmZmZjk5IGZmZmZjYyBmZmZmZmYgYzBjMGMwIDgwODA4MCA4MDAwMDAgMDA4MDAwIDAwMDA4MCA4MDgwMDAgODAwMDgwIDAwODA4MCA+IF0NCi9XaWR0aCAyMjA5DQovSGVpZ2h0IDENCi9CaXRzUGVyQ29tcG9uZW50IDgNCi9OYW1lIC8wDQo+Pg0Kc3RyZWFtDQp4XsWVUQ7AIAxCvf8Fvc7+tImEPuKy+bXUKZTSOtaaaontHSpf+6zfpveNdWEDV0mLVM6QZUBRHVIlnGsqGFBSXgqpI5b5n4RlRlLfi6rmGlAGmv5ZTto8k/aqJyjg0lDJDPuK2hh1cesMVdWYwduF1qOBJcznIB3QrOh3GvgnwjHAvpIQXz4L22qtK9l0D//iqGqAxO81lbYxO/XVA7D3SAYKZW5kc3RyZWFtDQplbmRvYmoNCjggMCBvYmoNCjw8DQovVHlwZSAvRm9udA0KL1N1YnR5cGUgL1R5cGUxDQovRmlyc3RDaGFyIDMyDQovTGFzdENoYXIgMjU1DQovQmFzZUZvbnQgL0hlbHZldGljYS1Cb2xkDQovRW5jb2RpbmcgPDwNCi9UeXBlIC9FbmNvZGluZw0KL0RpZmZlcmVuY2VzIFszMiAvc3BhY2UgMTk2IC9BZGllcmVzaXMgMjE0IC9PZGllcmVzaXMgMjIwIC9VZGllcmVzaXMgMjI4IC9hZGllcmVzaXMgMjQ2IC9vZGllcmVzaXMgMjUyIC91ZGllcmVzaXMgMjIzIC9nZXJtYW5kYmxzIDE5MiAvQWdyYXZlIDE5NCAvQWNpcmN1bWZsZXggMTk4IC9BRSAxOTkgL0NjZWRpbGxhIDIwMCAvRWdyYXZlIDIwMSAvRWFjdXRlIDIwMiAvRWNpcmN1bWZsZXggMjAzIC9FZGllcmVzaXMgMjA2IC9JY2lyY3VtZmxleCAyMDcgL0lkaWVyZXNpcyAyMTIgL09jaXJjdW1mbGV4IDE0MCAvT0UgMjE3IC9VZ3JhdmUgMjE5IC9VY2lyY3VtZmxleCAxNTkgL1lkaWVyZXNpcyAyMjQgL2FncmF2ZSAyMjYgL2FjaXJjdW1mbGV4IDIzMCAvYWUgMjMxIC9jY2VkaWxsYSAyMzIgL2VncmF2ZSAyMzMgL2VhY3V0ZSAyMzQgL2VjaXJjdW1mbGV4IDIzNSAvZWRpZXJlc2lzIDIzOCAvaWNpcmN1bWZsZXggMjM5IC9pZGllcmVzaXMgMjQ0IC9vY2lyY3VtZmxleCAxNTYgL29lIDI0OSAvdWdyYXZlIDI1MSAvdWNpcmN1bWZsZXggMjU1IC95ZGllcmVzaXMgMTk3IC9BcmluZyAyMTYgL09zbGFzaCAxOTMgL0FhY3V0ZSAyMDUgL0lhY3V0ZSAyMTggL1VhY3V0ZSAyMjEgL1lhY3V0ZSAyMjkgL2FyaW5nIDI0OCAvb3NsYXNoIDIyNSAvYWFjdXRlIDIzNyAvaWFjdXRlIDI1MCAvdWFjdXRlIDI1MyAveWFjdXRlIDIxMCAvT2dyYXZlIDI0MiAvb2dyYXZlIDIwNCAvSWdyYXZlIDIzNiAvaWdyYXZlIDE5NSAvQXRpbGRlIDIxMyAvT3RpbGRlIDIyNyAvYXRpbGRlIDI0NSAvb3RpbGRlIDIyMiAvVGhvcm4gMjU0IC90aG9ybiAyMDkgL050aWxkZSAyNDEgL250aWxkZSAxMzggL1NjYXJvbiAxNTQgL3NjYXJvbiAyNDMgL29hY3V0ZSAyMTEgL09hY3V0ZSBdDQo+Pg0KL1dpZHRocyBbMjc4IDMzMyA0NzQgNTU2IDU1NiA4ODkgNzIyIDIzOCAzMzMgMzMzIDM4OSA1ODQgMjc4IDMzMyAyNzggMjc4IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiAzMzMgMzMzIDU4NCA1ODQgNTg0IDYxMSA5NzUgNzIyIDcyMiA3MjIgNzIyIDY2NyA2MTEgNzc4IDcyMiAyNzggNTU2IDcyMiA2MTEgODMzIDcyMiA3NzggNjY3IDc3OCA3MjIgNjY3IDYxMSA3MjIgNjY3IDk0NCA2NjcgNjY3IDYxMSAzMzMgMjc4IDMzMyA1ODQgNTU2IDMzMyA1NTYgNjExIDU1NiA2MTEgNTU2IDMzMyA2MTEgNjExIDI3OCAyNzggNTU2IDI3OCA4ODkgNjExIDYxMSA2MTEgNjExIDM4OSA1NTYgMzMzIDYxMSA1NTYgNzc4IDU1NiA1NTYgNTAwIDM4OSAyODAgMzg5IDU4NCAwIDU1NiAwIDI3OCA1NTYgNTAwIDEwMDAgNTU2IDU1NiAzMzMgMTAwMCA2NjcgMzMzIDEwMDAgMCA2MTEgMCAwIDI3OCAyNzggNTAwIDUwMCAzNTAgNTU2IDEwMDAgMzMzIDEwMDAgNTU2IDMzMyA5NDQgMCA1MDAgNjY3IDAgNzIyIDU1NiA2MTEgNTU2IDU1NiA2NjcgNTU2IDMzMyA3MzcgMzcwIDU1NiA2MTEgMCA3MzcgNjExIDQwMCA1NTYgMzMzIDI3OCAzMzMgNjExIDU1NiAyNzggMzMzIDMzMyAzNjUgNTU2IDUwMCA4MzQgODM0IDUwMCA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiAxMDAwIDcyMiA2NjcgNjY3IDY2NyA2NjcgMjc4IDI3OCAyNzggMjc4IDcyMiA3MjIgNzc4IDc3OCA3NzggNzc4IDc3OCA1ODQgNzc4IDcyMiA3MjIgNzIyIDcyMiA2NjcgNjY3IDYxMSA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA4ODkgNTU2IDU1NiA1NTYgNTU2IDU1NiAyNzggMjc4IDI3OCAyNzggNjExIDYxMSA2MTEgNjExIDYxMSA2MTEgNjExIDU4NCA2MTEgNjExIDYxMSA2MTEgNjExIDU1NiA2MTEgNTU2IF0NCi9OYW1lIC9GMQ0KPj4NCmVuZG9iag0KeHJlZg0KMCA5DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMTEgMDAwMDAgbg0KMDAwMDAwMDExMSAwMDAwMCBuDQowMDAwMDAwMjk4IDAwMDAwIG4NCjAwMDAwMDAzNjMgMDAwMDAgbg0KMDAwMDAwMDU3MyAwMDAwMCBuDQowMDAwMDAxMDc0IDAwMDAwIG4NCjAwMDAwMDMwMDcgMDAwMDAgbg0KMDAwMDAwNDk1MSAwMDAwMCBuDQp0cmFpbGVyDQo8PA0KL1NpemUgOQ0KL1Jvb3QgMSAwIFINCi9JbmZvIDIgMCBSDQo+Pg0Kc3RhcnR4cmVmDQo2ODg4DQolJUVPRg0K
Sorry for that.
Anyway, this should be a pdf because that was one of the request parameters. (I could also have chosen for .gif, or .jpg in different qualities.)
I tried reading the content, like this:
#label_binary = #response_label[:generate_label_response][:response_shipments][:response_shipment][:labels][:label][:content]
binary_data = Base64.decode64(#label_binary)
#label = File.open('file_name.pdf', 'wb') {|f| f.write(Base64.decode64(binary_data))}
But what this prints then as #label is just a number (three of four digits). Same when I use urlsafe_decode64.
Not very helpful.
Preferred end-result would be a pdf image file that I can immediately display (in this case a barcode on top of an invoice for sending a package).
Could I for this purpose save the file temporarily? Meaning: every time I need to display I rebuild this image. I think that would be best.
EDIT
I am making the call now directly to a 600dpi .jpg image and then:
base_64_binary_data = #response_label[:generate_label_response][:response_shipments][:response_shipment][:labels][:label][:content]
#jpg_file = File.open('label.jpg', 'wb') do |file|
content = Base64.decode64 base_64_binary_data
file << content
end
This file shows up at my_apps_name/label.jpg.
In my filesystem I can see the picture crystal clear.
In my view I then put:
<%= image_tag #jpg_file.path %>
When I inspect my html in the browser I see:
<img src="/images/label.jpg" alt="Label">
I suppose this is easily fixed, suggestions are still welcome of course, but...
..more importantly: What if this call is made several times at once. Will rails manage? Should I maybe save these images (to my S3) or build some kind of chronejob to manage it?
(I am not sure of the added value of mini_magic anymore, since I can see the .jpg being already there.)
Then on a complete side note, maybe better left for a separate question: what if the API on the other side fails?
Step one
decode http response
require "base64"
BASE_64_BINARY_DATA = "PASTE YOUR BIG STRING HERE"
pdf_file = File.open('your_pdf.pdf', 'wb') do |file|
content = Base64.decode64 BASE_64_BINARY_DATA
file << content
end
Step two
convert pdf file to an image
add to gemfile 'gem 'mini_magick' and use 'bundle install' command
put somewhere in your code
require 'mini_magick'
pdf = MiniMagick::Image.new(pdf_file.path)
pdf.pages.first.write("preview.png")
image saved as preview.png
To display pdf image put in the view
<%= image_tag ("path_to_image/preview.jpg")%>

Where do the temp files go when using MiniMagick in a Ruby on Rails app?

I'm using MiniMagick to perform some image resizing on images uploaded through a multi-part form. I need to generate a few different types of images from the originally uploaded file. Here's the code that's performing the image processing:
// Generates a thumbnail image
mm = MiniMagick::Image.open(Rails.root.join('public', 'uploads', new_url))
mm.resize(thumbnail_dimensions.join("x"))
mm.write(Rails.root.join('public', 'uploads', "t_"+new_url))
// Generates cropped version
mm_copy = MiniMagick::Image.open(Rails.root.join('public', 'uploads', new_url))
mm_copy.crop('200x200')
mm_copy.write(Rails.root.join('public', 'uploads', "c_"+new_url))
new_url is the path to the image in the public folder. The thumbnail routine works perfectly. When the app goes to start processing the cropped version, that is where things start breaking and I can't for the life of me figure it out. I receive the following error when from this code:
No such file or directory - /tmp/mini_magick20110627-10055-2dimyl-0.jpg
I read some stuff about possible race conditions with the garbage collector in Rails but I wasn't able to resolve the issue. I tried this from the console as well and can create MiniMagick instances but receive the No such file error there as well. At this point, I have no idea where to go so I'm hoping someone here has some helpful suggestions. Thanks for your help!
Details:
OS: Ubuntu (Lucid Lynx)
Rails Version: 3.0.7
Ruby Version: 1.8.7
MiniMagick Version: 3.3
Did you installed ImageMagick?
If not,
try sudo apt-get install ImageMagick,
and then restart your webrick server
it's probably the race condition which is mentioned here:
https://ar-code.lighthouseapp.com/projects/35/tickets/6-race-condition-with-temp_file
here's one fix:
http://rubyforge.org/tracker/index.php?func=detail&aid=9417&group_id=1358&atid=5365
alternatively, and probably easier, you could try this:
// Generates a thumbnail image
mm = MiniMagick::Image.open(Rails.root.join('public', 'uploads', new_url))
mm_copy = mm.clone # clone the opened Image, instead of re-opening it
mm.resize(thumbnail_dimensions.join("x"))
mm.write(Rails.root.join('public', 'uploads', "t_"+new_url))
// Generates cropped version
mm_copy.crop('200x200')
mm_copy.write(Rails.root.join('public', 'uploads', "c_"+new_url))

ruby reading files from S3 with open-URI

I'm having some problems reading a file from S3. I want to be able to load the ID3 tags remotely, but using open-URI doesn't work, it gives me the following error:
ruby-1.8.7-p302 > c=TagLib2::File.new(open(URI.parse("http://recordtemple.com.s3.amazonaws.com/music/745/original/The%20Stranger.mp3?1292096514")))
TypeError: can't convert Tempfile into String
from (irb):8:in `initialize'
from (irb):8:in `new'
from (irb):8
However, if i download the same file and put it on my desktop (ie no need for open-URI), it works just fine.
c=TagLib2::File.new("/Users/momofwombie/Desktop/blah.mp3")
is there something else I should be doing to read a remote file?
UPDATE: I just found this link, which may explain a little bit, but surely there must be some way to do this...
Read header data from files on remote server
Might want to check out AWS::S3, a Ruby Library for Amazon's Simple Storage Service
Do an AWS::S3:S3Object.find for the file and then an use about to retrieve the metadata
This solution assumes you have the AWS credentials and permission to access the S3 bucket that contains the files in question.
TagLib2::File.new doesn't take a file handle, which is what you are passing to it when you use open without a read.
Add on read and you'll get the contents of the URL, but TagLib2::File doesn't know what to do with that either, so you are forced to read the contents of the URL, and save it.
I also noticed you are unnecessarily complicating your use of OpenURI. You don't have to parse the URL using URI before passing it to open. Just pass the URL string.
require 'open-uri'
fname = File.basename($0) << '.' << $$.to_s
File.open(fname, 'wb') do |fo|
fo.print open("http://recordtemple.com.s3.amazonaws.com/music/745/original/The%20Stranger.mp3?1292096514").read
end
c = TagLib2::File.new(fname)
# do more processing...
File.delete(fname)
I don't have TagLib2 installed but I ran the rest of the code and the mp3 file downloaded to my disk and is playable. The File.delete would clean up afterwards, which should put you in the state you want to be in.
This solution isn't going to work much longer. Paperclip > 3.0.0 has removed to_file. I'm using S3 & Heroku. What I ended up doing was copying the file to a temporary location and parsing it from there. Here is my code:
dest = Tempfile.new(upload.spreadsheet_file_name)
dest.binmode
upload.spreadsheet.copy_to_local_file(:default_style, dest.path)
file_loc = dest.path
...
CSV.foreach(file_loc, :headers => true, :skip_blanks => true) do |row|}
This seems to work instead of open-URI:
Mp3Info.open(mp3.to_file.path) do |mp3info|
puts mp3info.tag.artist
end
Paperclip has a to_file method that downloads the file from S3.

Ruby file_get_contents equivalent

I need to use this in my rails program so I can get the image contents and then base64 it. I know how to base64 it but I just don't know how I would get the image. Anyone know how?
Edited to retrieve from external URL:
PHP:
$image = file_get_contents("http://www.example.com/file.png");
Ruby:
require 'net/http'
image = Net::HTTP.get_response(URI.parse("http://www.example.com/file.png")).body
For http/https/ftp you can use OpenURI module:
require "open-uri"
image = open("http://www.example.com/file.png").read

Resources