Legacy ImageMagick Discussions Archive

contrast-stretch with no -channel selection should not change color balance, neither should linear-stretch. at least it does not in non_hdri to my knowledge. That is what I said, with a caveat... if channels are changes in sync the color won't change but, OTOH if you do that you'll burn much more p...

In that specific operation I'm trying to stretch contrast while not burning more than X% pixels and blacking out more than Y% pixels. My definition of "burn" and "black out" is, it seems, different from the current one used in ImageMagick: I would consider that if one channel bur...

The thing is, in the docs it says:

"All the channels are normalized in concert by the came amount so as to preserve color integrity, when the default +channel setting is in use."

I can't see where color integrity is being preserved here at 0.0001% levels or whatever is specified...

Linear stretches from full black and white, so that is why it does nothing for -linear-stretch 0. If your min and max graylevels are far from black and white, any small clip amount will jump all the way to those graylevels for linear-stretch and will go a little further for -contrast-stretch as it ...

When I read the current ImageMagick documentation what I see is that linear-stretch does the same as contrast-stretch, but instead of using the histogram as a lookup table it calculates the correct factors for use in "level" and then issues it internally. All 3 operators are now -channel/+...

Thanks guys, once again!

While it is true linear-stretch 0%x0% does not change the image there is an auto-level just before it, doing what linear-stretch 0%-0% should do in the first place (IMHO), so it's a wash: it does nothing but the work was already done anyway. In an image as small as this one burning 0.0001% is nothin...

[reviewed below] This is a strange behavior in linear stretch... convert input.exr -auto-level -linear-stretch 0%x0% -gamma 2 -channel Red -gamma 1 -channel Green -gamma 0.9 -channel Blue -gamma 1.02 +channel -depth 16 -sigmoidal-contrast 5x27.5% -set option:modulate:colorspace hsb -modulate 100,500...

I confirm the bug is solved. Apart from this small bugs I've found ImageMagick is doing an excellent work in HDRI post processing, mixing results from a bunch of tonemappings, etc... Together with pfstools makes one of the most powerful toolchains for HDRI processing. As always: thanks for this grea...

I'm not so sure if this is an actual bug, since one of the operations generates values out of range... nevertheless I'm reporting it for you to appreciate. convert input.exr -gamma 2.0 -linear-stretch 0.01%x0.01% -depth 8 -interlace line -quality 98 -sampling-factor 1x1 output.jpg If you either remo...

Ok, the bug in modulate seems solved, now I have another one... in another thread

Nice, now is there someway to make it run faster without -filter Point -resize 50% or similar extreme measures?

Found the answer myself: the image contains, in comments, the entire list of colors with the color count for each one! The correct way to sort this out in a single "convert" is something like this: convert input.jpg -write histogram:mpr:xpto +delete mpr:xpto -strip -evaluate Divide 2 -eval...

Hi! When I generate a histogram for an image with a command like: convert xpto.jpg histogram:output.png The output.png file tends to be huge, something like 300k or more... Now, if I do this: convert xpto.jpg histogram:- | convert - output.png The same exact histogram is generated (of course!) but n...

Hum... interesting it's only in HSL, because as I wrote previously the error occurred with all 3 colorspaces supported by modulate, unless I was doing something wrong :roll: I'll check it tomorrow, as soon as I get my hands on that new version ;) Thanks again for the fast answer! I'm using ImageMagi...