The options page documentation for -black-threshold says:
"Force to black all pixels at or below the threshold while leaving all pixels above the threshold unchanged."
And for -white-threshold says:
"Force to white all pixels at or above the threshold."
But the code says for -black-threshold:
if ((MagickRealType) q->red < threshold.red)
q->red=(Quantum) 0;
And for -white-threshold:
if (((channel & RedChannel) != 0) &&
((MagickRealType) q->red > threshold.red))
q->red=(Quantum) QuantumRange;
So the documentation says that the black-point and white-point are inclusive of what is changed to black or white, but the code says that it they are exclusive.
If the options page documentation is indeed wrong, let me know and I will go ahead and fix it.
bug in -black-threshold & -white-threshold vs documentation
- fmw42
- Posts: 25562
- Joined: 2007-07-02T17:14:51-07:00
- Authentication code: 1152
- Location: Sunnyvale, California, USA
bug in -black-threshold & -white-threshold vs documentation
Last edited by fmw42 on 2009-09-17T15:39:16-07:00, edited 2 times in total.
Re: bug in -black-threshold & -white-threshold vs documentation
The documentation is wrong. The black threshold for example, is documented in the code as
Notice it says below the threshold. Feel free to correct the HTML docs.BlackThresholdImage() is like ThresholdImage() but forces all pixels below
the threshold into black while leaving all pixels at or above the threshold
unchanged.
- fmw42
- Posts: 25562
- Joined: 2007-07-02T17:14:51-07:00
- Authentication code: 1152
- Location: Sunnyvale, California, USA
Re: bug in -black-threshold & -white-threshold vs documentation
No problem. I will then just correct the docs at http://www.imagemagick.org/script/comma ... ptions.php. On further thought, I think it best not to have a loss of backward compatibility. I can deal with the offset in my script easy enough.
Fred
Fred