Errors in high value pixels?

[b3and1p]

I am getting these errors a lot lately when pixels go over a value of 1 (or 255 I guess in non float)
http://placesnapdev02.s3.amazonaws.com/ ... b4_640.jpg

When I was getting this with extreme hald changes I would just do a +level 1% before modifying the color and that seemed to work. But that I have added some linear dodge and color burn overlays the +level trick doesnt seem to work. Is there a flag I have to turn on to fix this problem? Thanks guys!

[b3and1p]

http://placesnapdev02.s3.amazonaws.com/ ... 18c5_o.jpg

You can see it there in the middle of the picture. I think it comes from the linear dodge. Anyone know a secret for getting rid of these artifacts?

[anthony]

IT looks, just like you said. The values have bee clipped by the maximum limits of the digitial image.

Unfortunately once those values have been clipped information has been lost. It would be very difficult to get them back in a automated way.

If you have the original un-modified image we could look at the 'dodge' operation you used and see about preventing the clipping.

[b3and1p]

convert image1.png \(image2.png -resize 512x512\! \) -compose LinearDodge -composite result.png

is there any way to make the pixels clip to white? I don't mind clipping, I just don't understand why it doesn't clip to white or black like most image editing programs.

[anthony]

that is because linear Dodge like many composition methods are gray scale operators that work in individual channels.

One solution is to convert the image to CMYK, extract the black channel, negate, color dodge that, negate and combine the CMY channel images with the modified black channel, then convert back To RGB.

In theory that should work, but with out actual test images, I can't test it out.

For channel handling see...
see http://www.imagemagick.org/Usage/channels/

ASIDE: about color spaces. CMY colorspace (no black) is exactly the same as RGB colorsace but with all channels negated. The only difference between CMY and CMYK is that any amount common in ALL three channels is converted into a 'Black' Ink channel.

Alternative color spaces that may work better is HSB or HSL with the black channel equivalent being the B (Brightness) and L (Luminance) channels. Actually these may work better as it is more 'combined' than CMYK.

[b3and1p]

What about doing a plus instead of a linear dodge? I assume it would have the same problem? I can understand IM doing the calculations on a greyscale level, but I still can't understand why it isn't just clipping the channels at 255 instead of cycling (which it looks like it is doing). Are you saying that anytime a image has a channel modified past 255 this is what happens? That seems a little insane to me honestly.

[fmw42]

What version of IM are you using? Is it HDRI mode?

You could try adding -clamp to your command line, but it may already be too late after the composite step.

[anthony]

What about doing a plus instead of a linear dodge? I assume it would have the same problem? I can understand IM doing the calculations on a greyscale level, but I still can't understand why it isn't just clipping the channels at 255 instead of cycling (which it looks like it is doing). Are you saying that anytime a image has a channel modified past 255 this is what happens? That seems a little insane to me honestly.

It is clipping at 255 (for a Q8 version of IM)! The problem is it clips each channel individually, so you get clipping distortions.
Each channel is treated as a separate greyscale image, so when clipping sets in you get color distortions.

Use HSL, and just linear dodge the 'L' channel only.

Note that lighting effect 'linear dodge' and a mathematical 'plus' compositions are actually exactly the same function -- ADD with clipping! The only difference between them is how they handle the blending of image transparency. If both images are fully opaque, there is no difference!!!

See IM Examples, Linear Dodge
http://www.imagemagick.org/Usage/compose/#lineardodge

Multiply does not have clipping problems. Basically as the resulting channel values never go out of range. This is also why the lighting effects Overlay, Hard light, Soft light do not have clipping problems, as they are all based on multiply.

[b3and1p]

Ah ok thanks! yea I work in visual effects and we always work in float, so I never really have to deal with this. I will try HLS, I will also try something that is closer to a "screen" effect like soft light so that this doesn't become a issue. I got over this problem with -hald clut by doing +level 1%. I am not sure why that worked, but it did.

One problem.. How do I convert to HLS and do the compose only in L? Can i do it all in one line? Sorry to be such a bother guys!

[anthony]

I repeat the link given above
http://www.imagemagick.org/Usage/channels/

[GreenKoopa]

How do I convert to HLS and do the compose only in L? Can i do it all in one line?

You can change to HSB, HSL, Lab, etc. using -colorspace. To work with only L, use -channel.

[anthony]

WARNING: Channel does not work with LinearDodge or other Light Effect Compositions. However it does work with Mathematical compositions like Plus, so you can use Plus instead with -channel.

To apply it to the 'L' channel of a HSL image you need to extract a greyscale channel image, and apply it to that.

Code: Select all

convert image.png  -colorspace HSL -separate \
            \( +clone effect.png -compose LinearDodge -composite \
            \) +swap +delete \
           -combine -set colorspace HSL -colorspace RGB   result.png

First line converte to HSL colorspace and separates the images
seond grabs just the last 'L' greyscale image, and applies lineardodge
thrid line replaces the original 'L' image with new version
and last the 3 channel images are combined back together, the merged image declared to be HSL (otherwise IM thinks it is already RGB) and converted back to RGB colorspace

[b3and1p]

Hmm still not working. It has the same problem when I convert to HLS.
http://placesnapdev02.s3.amazonaws.com/ ... 1b_640.jpg
Here is the line:
$enc[] = "convert input.png -colorspace HSL -separate \( +clone \( ../../plus.jpg -resize $size\! \) -compose Plus -composite \) +swap +delete -combine -set colorspace HSL -colorspace RGB -quality 100 {out}";

[fmw42]

Lightness channel is rather odd. Prehaps try HSB in place of HSL. For an example of the oddness see http://www.imagemagick.org/Usage/color_ ... colorspace

also post a link to your input image so others can test.

what version of IM and platform are you using. If IM is old, perhaps it needs an upgrade.

[anthony]

Hmm still not working. It has the same problem when I convert to HLS.
http://placesnapdev02.s3.amazonaws.com/ ... 1b_640.jpg
Here is the line:
$enc[] = "convert input.png -colorspace HSL -separate \( +clone \( ../../plus.jpg -resize $size\! \) -compose Plus -composite \) +swap +delete -combine -set colorspace HSL -colorspace RGB -quality 100 {out}";

As the command is in double quotes, any backslashes are removed (escaped). You need to double the backslashes so the shell (which is what needs the backslash) will see them. Either that use use single quotes in the double quotes EG: '(' to protect the parenthesis from shell processing.

See IM Examples, PHP with IM CLI
http://www.imagemagick.org/Usage/api/#php