From: Timothy Hunter Date: 2005-08-29T06:11:22+09:00 Subject: Re: rmagick question Joe Van Dyk wrote: > On 8/26/05, Ara.T.Howard 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.