Morphology Op

[Thomas E Deweese <th...@kodak.com>]

Hi all,

   I figured out the 'blockyness' 'darkness' issue.  The pixel is
Signed and the Alpha value is kept as the high byte (the lower bytes
are masked away) this means that when alpha goes above 127 (.5
opacity) it's interpreted as a negative number.  Which of course
messes up the min/max thing your trying to do.

   I now '>>>' 24 bits instead of masking it.  The image now looks
correct... most of the time.  I have run into another real Alpha
Pre-Mult problem.  I suspect it has been there for a while but has
gone unnoticed, when I draw the image the partially transparent parts
become 'dark'.  This is particularly evident for this image since the
background is 0.5 opacity.  It appears to only happen when I zoom
some, and only about 1/2 the time then.  I'm beggining to suspect the
trigger is somewhere in the canvas (the bug is most likely in the
JDK).

   I'm still working my way through this.  Right now I don't have a
good idea what exactly is going on though...

   If people want I can probably commit my changes in Morphology but I
would rather hold off until everything seems to be working again...

Re: Morphology Op

[Thomas E Deweese <th...@kodak.com>]

>>>>> "VH" == Vincent Hardy <vi...@eng.sun.com> writes:

VH> Thomas, Did you see my question about whether or not we should
VH> work in premultiplied for morphology? I'd like to know what you
VH> think.

    Given your case, a pixel with a bright red partially transparent
pixel and a fully opaque dark red pixel, and morphology's definition
of taking the maximum for each channel the result of a fully opaque
dark red pixel _is_ unexpected (I would expect a bright red fully
transparent pixel).

    I've gone through the math and it appears that the numbers at
least "make sense".  So you can't get Color Values that are out of
line with the associate "pre-multiplied" alpha channel (ie dividing
out alpha will never give you negative numbers (Duh!) or numbers
greater than 255).

    But it's important to note that the numbers don't 'work out' like
they do for convolution.  Where the portion of the 'bright red' that
is contributed is directly in-line with the amount of alpha the pixel
contributes.  Here the alpha used is potentially from a completely
different pixel than the premultiplied color, at which point you have
to ask premultiplied by what???

    If you get the current build I have a complete implementation of
'filter(BufferedImage, BufferedImage) in MorphologyOp that uses
unpremult alpha instead.  Compare the two see what you think looks
better/more correct (this is a bit hard since morphology already has a
tendency to do unexpected things).