On Fri, Aug 18, 2006 at 02:29:55AM -0700, Glenn Linderman wrote > Hi Walter, and all, > > I guess for my first (accidentally private) reply to Walter, Ah yes, "Chip Rosenthal Considered Harmful To Mailing Lists". Never before has one web page by one person screwed iup so many emails for so many people. I solve that problem with the following procmail recipie...
* ^X-BeenThere: [EMAIL PROTECTED] * !^Reply-To: [email protected] | formail -i "Reply-To: [email protected] (Image-Magick Users List)" > However, I don't understand the math behind this one, how did you come > up with that formula, and how do you know the resulting numbers stay in > range? > > I am also rather amazed at the significant effect the +1 has to the > overall result. It would seem that for pixel values ranging up to 65535, > multiplied by a positive number, that adding 1 wouldn't have a > significant impact. But I can see the difference if I omit it! [...deletia...] > >#!/bin/bash > >convert ${1} -fx u^${3} ${2} > > > > It's invoked like... > > > >pwrr input_image output_image 0.75 > > > >The 3rd parameter is a positive number (float) less than 1. The lower > >the 3rd parameter, the more brightening you get. > > > OK, this one also works better than it was: with the 6.0.8 version of > IM, it produced only a white or black image. Now it does do a reasonable > brightening job ... quite nice on my old slide, actually. > > I don't understand the math here, either. My first pixel has a red > component of 38550 (when converted to Q16), but when I do the u^.5 > operation, it becomes 50263. That is NOT the square root of 38550. What > exactly is -fx doing under the covers that I don't understand? The important thing to remember is that ImageMagick "normalizes" all pixel values, so that the range is always from 0.0 to 1.0 when doing internal manipulations. The result is "denormalized" appropriately when producing the final output. For Q16, 65535 maps to 1.0, i.e. it divides by 65535. For Q8, 255 maps to 1.0, i.e. it divides by 255. For the formula "ln(u*(${3}-1)+1)/ln(${3})", u is guaranteed to be in the range 0.0 through 1.0. As long as the 3rd parameter is > 1.0, the result is guaranteed to be in the range 0.0 through 1.0. In the following examples, there will be some roundoff error. The red pixel at 38550 is normalized to 38550/65535 = 0.582353. The square root of 0.582353 is 0.766965. When denormalizing, convert multiplies by the appropriate number, in this case 65535. And 0.766965 * 65535 = 50263.1. If you had specified "-depth 8" for your output (i.e. 8-bit channels), the result would've been multiplied by 255. The first red pixel would be 0.766965 * 255 = 195.576, which rounds off to 196. Normalizing allows Imagemagick to use the same routines to handle 8-bit channels, 16-bit channels, etc. It also eases converting images between gifferent formats. -- Walter Dnes <[EMAIL PROTECTED]> In linux /sbin/init is Job #1 My musings on technology and security at http://tech_sec.blog.ca _______________________________________________ Magick-users mailing list [email protected] http://studio.imagemagick.org/mailman/listinfo/magick-users
