I'm trying to set the pixels of an image:
require 'RMagick'
width = 512
height = 256
image = Magick::Image.new width, height
width.times do |x|
height.times do |y|
pixel = Magick::Pixel.new rand(256), rand(256), rand(256)
image.pixel_color x, y, pixel
end
end
image.write ARGV.shift
But the resulting image is all black. Why?
And here's some code from my actual application:
pixel = Magick::Pixel.new(*rgb)
puts "The image pixel was: <#{ image.pixel_color(e, n) }>"
image.pixel_color(e, n, pixel)
puts "The pixel was <#{ pixel }>"
puts "The image pixel is now: <#{ image.pixel_color(e, n) }>"
And here's the result:
The image pixel was: <red=65535, green=65535, blue=65535, opacity=0>
The pixel was <red=175, green=206, blue=117, opacity=0>
The image pixel is now: <red=65535, green=65535, blue=65535, opacity=0>
Why on earth isn't it setting the pixel color on the image?
On 8/25/05, Joe Van Dyk <joevandyk@gmail.com> wrote:
I'm trying to set the pixels of an image:
require 'RMagick'
width = 512
height = 256image = Magick::Image.new width, height
width.times do |x|
height.times do |y|
pixel = Magick::Pixel.new rand(256), rand(256), rand(256)
image.pixel_color x, y, pixel
end
endimage.write ARGV.shift
But the resulting image is all black. Why?
Use Magick::MaxRGB+1 instead of 256. RGB Values range from 0...2**16.
And be shure to check out the View funktionality.
regards,
Brian
On 26/08/05, Joe Van Dyk <joevandyk@gmail.com> wrote:
I'm trying to set the pixels of an image:
require 'RMagick'
width = 512
height = 256image = Magick::Image.new width, height
width.times do |x|
height.times do |y|
pixel = Magick::Pixel.new rand(256), rand(256), rand(256)
image.pixel_color x, y, pixel
end
endimage.write ARGV.shift
But the resulting image is all black. Why?
--
http://ruby.brian-schroeder.de/
Stringed instrument chords: http://chordlist.brian-schroeder.de/
Hm. I'm reading in from a file that has a bunch of RGB values from 0
to 256. So how can I set the pixel color of each pixel with that
data?
On 8/26/05, Brian Schröder <ruby.brian@gmail.com> wrote:
On 26/08/05, Joe Van Dyk <joevandyk@gmail.com> wrote:
> I'm trying to set the pixels of an image:
>
> require 'RMagick'
>
> width = 512
> height = 256
>
> image = Magick::Image.new width, height
>
> width.times do |x|
> height.times do |y|
> pixel = Magick::Pixel.new rand(256), rand(256), rand(256)
> image.pixel_color x, y, pixel
> end
> end
>
> image.write ARGV.shift
>
> But the resulting image is all black. Why?
>
>Use Magick::MaxRGB+1 instead of 256. RGB Values range from 0...2**16.
And be shure to check out the View funktionality.regards,
Brian
The following behavior is confusing to me.
p rgb
pixel = Magick::Pixel.new(*rgb)
image.pixel_color(e, n, pixel)
p image.pixel_color(e, n)
p pixel
This returns the following output:
[2, 0, 0]
red=65535, green=65535, blue=65535, opacity=0
red=2, green=0, blue=0, opacity=0
I create a new pixel, I set the image pixel to be that color, but the
image pixel is still a different color.
On 8/26/05, Brian Schröder <ruby.brian@gmail.com> wrote:
On 26/08/05, Joe Van Dyk <joevandyk@gmail.com> wrote:
> I'm trying to set the pixels of an image:
>
> require 'RMagick'
>
> width = 512
> height = 256
>
> image = Magick::Image.new width, height
>
> width.times do |x|
> height.times do |y|
> pixel = Magick::Pixel.new rand(256), rand(256), rand(256)
> image.pixel_color x, y, pixel
> end
> end
>
> image.write ARGV.shift
>
> But the resulting image is all black. Why?
>
>Use Magick::MaxRGB+1 instead of 256. RGB Values range from 0...2**16.
And be shure to check out the View funktionality.
I'm starting to lose my mind now.
% ls
test.rb
% cat test.rb
require 'RMagick'
file = ARGV.shift
width = 512
height = 256
image = Magick::Image.new width, height
width.times do |x|
height.times do |y|
pixel = Magick::Pixel.new rand(6550), rand(65000), rand(64000)
image.pixel_color x, y, pixel
end
end
image.write file
% touch temp.jpg
% ls
temp.jpg test.rb
% rm temp.jpg
% ls
test.rb
% ruby test.rb temp.jpg
% ls
test.rb
% SCREW YOU
SCREW: Command not found.
Why isn't it writing the image any more? Argh. I swear stuff like
this was working before.
On 8/26/05, Joe Van Dyk <joevandyk@gmail.com> wrote:
On 8/26/05, Brian Schröder <ruby.brian@gmail.com> wrote:
> On 26/08/05, Joe Van Dyk <joevandyk@gmail.com> wrote:
> > I'm trying to set the pixels of an image:
> >
> > require 'RMagick'
> >
> > width = 512
> > height = 256
> >
> > image = Magick::Image.new width, height
> >
> > width.times do |x|
> > height.times do |y|
> > pixel = Magick::Pixel.new rand(256), rand(256), rand(256)
> > image.pixel_color x, y, pixel
> > end
> > end
> >
> > image.write ARGV.shift
> >
> > But the resulting image is all black. Why?
> >
> >
>
> Use Magick::MaxRGB+1 instead of 256. RGB Values range from 0...2**16.
> And be shure to check out the View funktionality.
>
> regards,
>
> BrianHm. I'm reading in from a file that has a bunch of RGB values from 0
to 256. So how can I set the pixel color of each pixel with that
data?
Aha! On an image with dimensions (say) 200x200, I was trying to set
image.pixel_color(0, 200, pixel). That's outside the image... I
really wanted to set image.pixel_color(0, 199, pixel).
On 8/26/05, Joe Van Dyk <joevandyk@gmail.com> wrote:
On 8/26/05, Brian Schröder <ruby.brian@gmail.com> wrote:
> On 26/08/05, Joe Van Dyk <joevandyk@gmail.com> wrote:
> > I'm trying to set the pixels of an image:
> >
> > require 'RMagick'
> >
> > width = 512
> > height = 256
> >
> > image = Magick::Image.new width, height
> >
> > width.times do |x|
> > height.times do |y|
> > pixel = Magick::Pixel.new rand(256), rand(256), rand(256)
> > image.pixel_color x, y, pixel
> > end
> > end
> >
> > image.write ARGV.shift
> >
> > But the resulting image is all black. Why?
> >
> >
>
> Use Magick::MaxRGB+1 instead of 256. RGB Values range from 0...2**16.
> And be shure to check out the View funktionality.The following behavior is confusing to me.
p rgb
pixel = Magick::Pixel.new(*rgb)
image.pixel_color(e, n, pixel)
p image.pixel_color(e, n)
p pixelThis returns the following output:
[2, 0, 0]
red=65535, green=65535, blue=65535, opacity=0
red=2, green=0, blue=0, opacity=0I create a new pixel, I set the image pixel to be that color, but the
image pixel is still a different color.
Hm, I'm starting to think there's something wrong with my magick
installation. 
On 8/26/05, Joe Van Dyk <joevandyk@gmail.com> wrote:
On 8/26/05, Joe Van Dyk <joevandyk@gmail.com> wrote:
> On 8/26/05, Brian Schröder <ruby.brian@gmail.com> wrote:
> > On 26/08/05, Joe Van Dyk <joevandyk@gmail.com> wrote:
> > > I'm trying to set the pixels of an image:
> > >
> > > require 'RMagick'
> > >
> > > width = 512
> > > height = 256
> > >
> > > image = Magick::Image.new width, height
> > >
> > > width.times do |x|
> > > height.times do |y|
> > > pixel = Magick::Pixel.new rand(256), rand(256), rand(256)
> > > image.pixel_color x, y, pixel
> > > end
> > > end
> > >
> > > image.write ARGV.shift
> > >
> > > But the resulting image is all black. Why?
> > >
> > >
> >
> > Use Magick::MaxRGB+1 instead of 256. RGB Values range from 0...2**16.
> > And be shure to check out the View funktionality.
> >
> > regards,
> >
> > Brian
>
> Hm. I'm reading in from a file that has a bunch of RGB values from 0
> to 256. So how can I set the pixel color of each pixel with that
> data?I'm starting to lose my mind now.
% ls
test.rb% cat test.rb
require 'RMagick'
file = ARGV.shift
width = 512
height = 256image = Magick::Image.new width, height
width.times do |x|
height.times do |y|
pixel = Magick::Pixel.new rand(6550), rand(65000), rand(64000)
image.pixel_color x, y, pixel
end
endimage.write file
% touch temp.jpg
% ls
temp.jpg test.rb% rm temp.jpg
% ls
test.rb% ruby test.rb temp.jpg
% ls
test.rb% SCREW YOU
SCREW: Command not found.Why isn't it writing the image any more? Argh. I swear stuff like
this was working before.
i've found that the only way to go with imagemagick is to compile from source.
the redhat fedora and enterprise rpms are totally hosed: for example loseless
jpeg2000 compression isn't - unless you build from source, which takes hours
due to all the bloody dependancies. in any case i thought i'd let you know
that in case your installation is a redhat package.
note: this info above is about 4 months old - it could be fixed...
-a
On Sat, 27 Aug 2005, Joe Van Dyk wrote:
Hm, I'm starting to think there's something wrong with my magick
installation.
email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
Your life dwells amoung the causes of death
Like a lamp standing in a strong breeze. --Nagarjuna
===============================================================================
Possible, or test.jpg isn't writable? Your test.rb generated a greenish-blue static image for me.
On 26 Aug 2005, at 12:41, Joe Van Dyk wrote:
On 8/26/05, Joe Van Dyk <joevandyk@gmail.com> wrote:
I'm starting to lose my mind now.
% ls
test.rb% cat test.rb
require 'RMagick'
file = ARGV.shift
width = 512
height = 256image = Magick::Image.new width, height
width.times do |x|
height.times do |y|
pixel = Magick::Pixel.new rand(6550), rand(65000), rand(64000)
image.pixel_color x, y, pixel
end
endimage.write file
% touch temp.jpg
% ls
temp.jpg test.rb% rm temp.jpg
% ls
test.rb% ruby test.rb temp.jpg
% ls
test.rb% SCREW YOU
SCREW: Command not found.Why isn't it writing the image any more? Argh. I swear stuff like
this was working before.Hm, I'm starting to think there's something wrong with my magick
installation.
--
Eric Hodel - drbrain@segment7.net - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04
Thanks... this is on a imagemagick installation compiled from scratch
last night though. 6.2.4. So I'm not sure what's going on.
If I have a bunch of RGB values from 0-256, do you know a way to
create an image for them? Apparently the MaxRGB on my installation is
around 65000 or so. The image is around 10kx10k pixels, so speed is
sorta important.
On 8/26/05, Ara.T.Howard <Ara.T.Howard@noaa.gov> wrote:
On Sat, 27 Aug 2005, Joe Van Dyk wrote:
> Hm, I'm starting to think there's something wrong with my magick
> installation.i've found that the only way to go with imagemagick is to compile from source.
the redhat fedora and enterprise rpms are totally hosed: for example loseless
jpeg2000 compression isn't - unless you build from source, which takes hours
due to all the bloody dependancies. in any case i thought i'd let you know
that in case your installation is a redhat package.note: this info above is about 4 months old - it could be fixed...
Maybe you should take a look at Magick::Image#constitute
http://www.simplesystems.org/RMagick/doc/image1.html#constitute
that should help you further.
regards,
Brian
On 26/08/05, Joe Van Dyk <joevandyk@gmail.com> wrote:
On 8/26/05, Ara.T.Howard <Ara.T.Howard@noaa.gov> wrote:
> On Sat, 27 Aug 2005, Joe Van Dyk wrote:
>
> > Hm, I'm starting to think there's something wrong with my magick
> > installation.
>
> i've found that the only way to go with imagemagick is to compile from source.
> the redhat fedora and enterprise rpms are totally hosed: for example loseless
> jpeg2000 compression isn't - unless you build from source, which takes hours
> due to all the bloody dependancies. in any case i thought i'd let you know
> that in case your installation is a redhat package.
>
> note: this info above is about 4 months old - it could be fixed...Thanks... this is on a imagemagick installation compiled from scratch
last night though. 6.2.4. So I'm not sure what's going on.If I have a bunch of RGB values from 0-256, do you know a way to
create an image for them? Apparently the MaxRGB on my installation is
around 65000 or so. The image is around 10kx10k pixels, so speed is
sorta important.
--
http://ruby.brian-schroeder.de/
Stringed instrument chords: http://chordlist.brian-schroeder.de/
Joe Van Dyk wrote:
Hm, I'm starting to think there's something wrong with my magick
installation.i've found that the only way to go with imagemagick is to compile from source.
the redhat fedora and enterprise rpms are totally hosed: for example loseless
jpeg2000 compression isn't - unless you build from source, which takes hours
due to all the bloody dependancies. in any case i thought i'd let you know
that in case your installation is a redhat package.note: this info above is about 4 months old - it could be fixed...
Thanks... this is on a imagemagick installation compiled from scratch
last night though. 6.2.4. So I'm not sure what's going on.If I have a bunch of RGB values from 0-256, do you know a way to
create an image for them? Apparently the MaxRGB on my installation is
around 65000 or so. The image is around 10kx10k pixels, so speed is
sorta important.
If speed is important then the best thing to do is to build a new ImageMagick using the --with-quantum-depth=8 option. Using 8-bit depth images considerably reduces IM's memory and CPU requirements and it makes the channel intensities range from 0-255 instead of 0-65535, more in line with your expectations. For 100-million-pixel images I think it would be worth the trouble.
However, if you don't want to re-install IM and you don't mind paying for a couple extra bit operations per channel, you can convert 8-bit channels to 16-bit channels like this:
red16 = (red8 << 8) | red8
Lastly, take a look at the #store_pixels method. This method lets you replace pixels in an image a section at a time, where a section can be a single row or column of pixels, or for that matter any rectangle. This might be a good compromise between pixel_color and constitute.
On 8/26/05, Ara.T.Howard <Ara.T.Howard@noaa.gov> wrote:
On Sat, 27 Aug 2005, Joe Van Dyk wrote:
Thanks. In my test, it's faster to create Magick::Pixel objects and
set each pixel in the array rather than building a large array
containing all the pixel data then doing Image.constitute.
On 8/26/05, Brian Schröder <ruby.brian@gmail.com> wrote:
On 26/08/05, Joe Van Dyk <joevandyk@gmail.com> wrote:
> On 8/26/05, Ara.T.Howard <Ara.T.Howard@noaa.gov> wrote:
> > On Sat, 27 Aug 2005, Joe Van Dyk wrote:
> >
> > > Hm, I'm starting to think there's something wrong with my magick
> > > installation.
> >
> > i've found that the only way to go with imagemagick is to compile from source.
> > the redhat fedora and enterprise rpms are totally hosed: for example loseless
> > jpeg2000 compression isn't - unless you build from source, which takes hours
> > due to all the bloody dependancies. in any case i thought i'd let you know
> > that in case your installation is a redhat package.
> >
> > note: this info above is about 4 months old - it could be fixed...
>
> Thanks... this is on a imagemagick installation compiled from scratch
> last night though. 6.2.4. So I'm not sure what's going on.
>
> If I have a bunch of RGB values from 0-256, do you know a way to
> create an image for them? Apparently the MaxRGB on my installation is
> around 65000 or so. The image is around 10kx10k pixels, so speed is
> sorta important.
>
>Maybe you should take a look at Magick::Image#constitute
http://www.simplesystems.org/RMagick/doc/image1.html#constitute
that should help you further.
regards,
I'll try the bitshifting approach, thanks.
Previously, I had builtup a lookup array that looked like (I think):
color_lookup_table = Array.new
256.times { |i| color_lookup_table << Magick::MaxRGB / i }
And then did a lookup on that table for each color. You think the
bitshifting approach will be faster than an array lookup?
On 8/28/05, Timothy Hunter <cyclists@nc.rr.com> wrote:
Joe Van Dyk wrote:
> On 8/26/05, Ara.T.Howard <Ara.T.Howard@noaa.gov> wrote:
>
>>On Sat, 27 Aug 2005, Joe Van Dyk wrote:
>>
>>
>>>Hm, I'm starting to think there's something wrong with my magick
>>>installation.
>>
>>i've found that the only way to go with imagemagick is to compile from source.
>>the redhat fedora and enterprise rpms are totally hosed: for example loseless
>>jpeg2000 compression isn't - unless you build from source, which takes hours
>>due to all the bloody dependancies. in any case i thought i'd let you know
>>that in case your installation is a redhat package.
>>
>>note: this info above is about 4 months old - it could be fixed...
>
>
> Thanks... this is on a imagemagick installation compiled from scratch
> last night though. 6.2.4. So I'm not sure what's going on.
>
> If I have a bunch of RGB values from 0-256, do you know a way to
> create an image for them? Apparently the MaxRGB on my installation is
> around 65000 or so. The image is around 10kx10k pixels, so speed is
> sorta important.
>
>If speed is important then the best thing to do is to build a new
ImageMagick using the --with-quantum-depth=8 option. Using 8-bit depth
images considerably reduces IM's memory and CPU requirements and it
makes the channel intensities range from 0-255 instead of 0-65535, more
in line with your expectations. For 100-million-pixel images I think it
would be worth the trouble.However, if you don't want to re-install IM and you don't mind paying
for a couple extra bit operations per channel, you can convert 8-bit
channels to 16-bit channels like this:red16 = (red8 << 8) | red8
Lastly, take a look at the #store_pixels method. This method lets you
replace pixels in an image a section at a time, where a section can be a
single row or column of pixels, or for that matter any rectangle. This
might be a good compromise between pixel_color and constitute.
Joe Van Dyk wrote:
Joe Van Dyk wrote:
Hm, I'm starting to think there's something wrong with my magick
installation.i've found that the only way to go with imagemagick is to compile from source.
the redhat fedora and enterprise rpms are totally hosed: for example loseless
jpeg2000 compression isn't - unless you build from source, which takes hours
due to all the bloody dependancies. in any case i thought i'd let you know
that in case your installation is a redhat package.note: this info above is about 4 months old - it could be fixed...
Thanks... this is on a imagemagick installation compiled from scratch
last night though. 6.2.4. So I'm not sure what's going on.If I have a bunch of RGB values from 0-256, do you know a way to
create an image for them? Apparently the MaxRGB on my installation is
around 65000 or so. The image is around 10kx10k pixels, so speed is
sorta important.If speed is important then the best thing to do is to build a new
ImageMagick using the --with-quantum-depth=8 option. Using 8-bit depth
images considerably reduces IM's memory and CPU requirements and it
makes the channel intensities range from 0-255 instead of 0-65535, more
in line with your expectations. For 100-million-pixel images I think it
would be worth the trouble.However, if you don't want to re-install IM and you don't mind paying
for a couple extra bit operations per channel, you can convert 8-bit
channels to 16-bit channels like this:red16 = (red8 << 8) | red8
Lastly, take a look at the #store_pixels method. This method lets you
replace pixels in an image a section at a time, where a section can be a
single row or column of pixels, or for that matter any rectangle. This
might be a good compromise between pixel_color and constitute.I'll try the bitshifting approach, thanks.
Previously, I had builtup a lookup array that looked like (I think):
color_lookup_table = Array.new
256.times { |i| color_lookup_table << Magick::MaxRGB / i }And then did a lookup on that table for each color. You think the
bitshifting approach will be faster than an array lookup?
I don't know. My gut feel is yes but if you're going to be working on 100,000,000 pixel images then it would be worth the trouble to actually compare the two approaches. A little bit of difference would mount up quickly 
Of course 100,000,000 pixel images are going to have resource constraints besides CPU. At 16-pixels per channel each pixel will require 8 bytes plus some per-image overhead, so each image will occupy a bit over 800MB of memory. Using quantum depth=8 cuts the memory requirement in half.
No matter which approach you take let me know how it goes so I'll be able to make recommendations to other RMagick users who are working with very large images. Thanks!
On 8/28/05, Timothy Hunter <cyclists@nc.rr.com> wrote:
On 8/26/05, Ara.T.Howard <Ara.T.Howard@noaa.gov> wrote:
On Sat, 27 Aug 2005, Joe Van Dyk wrote:
Yes, my Ruby program was taking up about 500 MB of memory (for a
8700x6000 pixel image). Memory's not a problem though, all of our
machines have more than 2 gigabytes.
I'll report back tomorrow after I try the bitshifting and 8-bit
imagemagick approach instead of the current array lookup.
Unit tests are really coming in handy on this type of application.
Especially the benchmark library. It's awesome to make a change and
then build up some sample data and do automated tests and benchmarking
on it.
On 8/28/05, Timothy Hunter <cyclists@nc.rr.com> wrote:
Joe Van Dyk wrote:
> On 8/28/05, Timothy Hunter <cyclists@nc.rr.com> wrote:
>
>>Joe Van Dyk wrote:
>>
>>>On 8/26/05, Ara.T.Howard <Ara.T.Howard@noaa.gov> wrote:
>>>
>>>
>>>>On Sat, 27 Aug 2005, Joe Van Dyk wrote:
>>>>
>>>>
>>>>
>>>>>Hm, I'm starting to think there's something wrong with my magick
>>>>>installation.
>>>>
>>>>i've found that the only way to go with imagemagick is to compile from source.
>>>>the redhat fedora and enterprise rpms are totally hosed: for example loseless
>>>>jpeg2000 compression isn't - unless you build from source, which takes hours
>>>>due to all the bloody dependancies. in any case i thought i'd let you know
>>>>that in case your installation is a redhat package.
>>>>
>>>>note: this info above is about 4 months old - it could be fixed...
>>>
>>>
>>>Thanks... this is on a imagemagick installation compiled from scratch
>>>last night though. 6.2.4. So I'm not sure what's going on.
>>>
>>>If I have a bunch of RGB values from 0-256, do you know a way to
>>>create an image for them? Apparently the MaxRGB on my installation is
>>>around 65000 or so. The image is around 10kx10k pixels, so speed is
>>>sorta important.
>>>
>>>
>>
>>If speed is important then the best thing to do is to build a new
>>ImageMagick using the --with-quantum-depth=8 option. Using 8-bit depth
>>images considerably reduces IM's memory and CPU requirements and it
>>makes the channel intensities range from 0-255 instead of 0-65535, more
>>in line with your expectations. For 100-million-pixel images I think it
>>would be worth the trouble.
>>
>>However, if you don't want to re-install IM and you don't mind paying
>>for a couple extra bit operations per channel, you can convert 8-bit
>>channels to 16-bit channels like this:
>>
>>red16 = (red8 << 8) | red8
>>
>>Lastly, take a look at the #store_pixels method. This method lets you
>>replace pixels in an image a section at a time, where a section can be a
>>single row or column of pixels, or for that matter any rectangle. This
>>might be a good compromise between pixel_color and constitute.
>
>
> I'll try the bitshifting approach, thanks.
>
> Previously, I had builtup a lookup array that looked like (I think):
> color_lookup_table = Array.new
> 256.times { |i| color_lookup_table << Magick::MaxRGB / i }
>
> And then did a lookup on that table for each color. You think the
> bitshifting approach will be faster than an array lookup?
>
>
I don't know. My gut feel is yes but if you're going to be working on
100,000,000 pixel images then it would be worth the trouble to actually
compare the two approaches. A little bit of difference would mount up
quicklyOf course 100,000,000 pixel images are going to have resource
constraints besides CPU. At 16-pixels per channel each pixel will
require 8 bytes plus some per-image overhead, so each image will occupy
a bit over 800MB of memory. Using quantum depth=8 cuts the memory
requirement in half.No matter which approach you take let me know how it goes so I'll be
able to make recommendations to other RMagick users who are working with
very large images. Thanks!
Joe Van Dyk wrote:
On 8/28/05, Timothy Hunter <cyclists@nc.rr.com> wrote:
No matter which approach you take let me know how it goes so I'll be
able to make recommendations to other RMagick users who are working with
very large images. Thanks!Yes, my Ruby program was taking up about 500 MB of memory (for a
8700x6000 pixel image). Memory's not a problem though, all of our
machines have more than 2 gigabytes.
Okay, first recommendation: have a honkin' great big machine
Thanks!
(in case people forgot, the color values in @tad_data are from 0-255,
so conversion is needed if ImageMagick is using 16 bit color pixels)
The inner code loop looked something like this:
(height - 1).downto(0) do |n|
# Code here that displayed percent-done status to user
width.times do |e|
# Lookup approach with 16 bit pixel ImageMagick
#rgb = @tad_data.read(8).unpack(TAD_FORMAT).collect! { |c|
lookup_table[c] }
# Bitshifting approach with 16 bit pixel ImageMagick
#rgb = @tad_data.read(8).unpack(TAD_FORMAT).collect! { |c| (c
<< 8) | c }
# 8 bit ImageMagick, no conversion necessary
rgb = @tad_data.read(8).unpack(TAD_FORMAT)
pixel = Magick::Pixel.new(*rgb)
@image.pixel_color(e, n, pixel)
end
end
Doing a 10000x10 pixel image (only 10 pixels high for unit testing
purposes), I could process:
13k pixels/second with the bitshifting approach (and 16 bit IM)
13k pixels/second with the array lookup approach (and 16 bit IM)
21k pixels/second with 256 bit IM.
I also found that building up an array of colors for one row and then
doing a @image.import_pixels had no speed improvements and the code
was uglier.
On 8/29/05, Timothy Hunter <cyclists@nc.rr.com> wrote:
Joe Van Dyk wrote:
> On 8/28/05, Timothy Hunter <cyclists@nc.rr.com> wrote:
>
>>No matter which approach you take let me know how it goes so I'll be
>>able to make recommendations to other RMagick users who are working with
>>very large images. Thanks!
>
>
> Yes, my Ruby program was taking up about 500 MB of memory (for a
> 8700x6000 pixel image). Memory's not a problem though, all of our
> machines have more than 2 gigabytes.
>Okay, first recommendation: have a honkin' great big machine
Hm... I don't think that those pixels/second numbers are correct. I
was doing the timings inside a Benchmark.measure { ... } block and
perhaps that makes things slower?
I was able to process a 8700x6000 pixel image when using 'time ./script.rb'
440.005u 9.917s 8:27.20 88.7% 0+0k 0+0io 52012pf+0w
So, around 7 minutes for 5 million pixels.. that's around 118000
pixels per second. Hm. Oh well, it's fast enough for me. This
operation isn't done all that often. Although, a while ago I did
something like this in C with the GD library, and it took around 10-20
seconds to process a similar sized image.
On 8/29/05, Joe Van Dyk <joevandyk@gmail.com> wrote:
On 8/29/05, Timothy Hunter <cyclists@nc.rr.com> wrote:
> Joe Van Dyk wrote:
> > On 8/28/05, Timothy Hunter <cyclists@nc.rr.com> wrote:
> >
> >>No matter which approach you take let me know how it goes so I'll be
> >>able to make recommendations to other RMagick users who are working with
> >>very large images. Thanks!
> >
> >
> > Yes, my Ruby program was taking up about 500 MB of memory (for a
> > 8700x6000 pixel image). Memory's not a problem though, all of our
> > machines have more than 2 gigabytes.
> >
>
> Okay, first recommendation: have a honkin' great big machine(in case people forgot, the color values in @tad_data are from 0-255,
so conversion is needed if ImageMagick is using 16 bit color pixels)The inner code loop looked something like this:
(height - 1).downto(0) do |n|
# Code here that displayed percent-done status to user
width.times do |e|
# Lookup approach with 16 bit pixel ImageMagick
#rgb = @tad_data.read(8).unpack(TAD_FORMAT).collect! { |c|
lookup_table[c] }# Bitshifting approach with 16 bit pixel ImageMagick
#rgb = @tad_data.read(8).unpack(TAD_FORMAT).collect! { |c| (c
<< 8) | c }# 8 bit ImageMagick, no conversion necessary
rgb = @tad_data.read(8).unpack(TAD_FORMAT)pixel = Magick::Pixel.new(*rgb)
@image.pixel_color(e, n, pixel)
end
endDoing a 10000x10 pixel image (only 10 pixels high for unit testing
purposes), I could process:13k pixels/second with the bitshifting approach (and 16 bit IM)
13k pixels/second with the array lookup approach (and 16 bit IM)
21k pixels/second with 256 bit IM.I also found that building up an array of colors for one row and then
doing a @image.import_pixels had no speed improvements and the code
was uglier.