[ImageJ-devel] Bug in creation of CompositeXYProjectors in DefaultDatasetView

Lee Kamentsky leek at broadinstitute.org
Mon Jul 15 10:31:44 CDT 2013


Hi all,
I'm looking at the code for net.imglib2.display.CompositeXYProjector and as
I step through it, it's clear that the alpha calculation isn't being
handled correctly. Here's the code as it stands now, line 190 roughly:

for ( int i = 0; i < size; i++ )
{
sourceRandomAccess.setPosition( currentPositions[ i ], dimIndex );
currentConverters[ i ].convert( sourceRandomAccess.get(), bi );
// accumulate converted result
final int value = bi.get();
final int a = ARGBType.alpha( value );
final int r = ARGBType.red( value );
final int g = ARGBType.green( value );
final int b = ARGBType.blue( value );
aSum += a;
rSum += r;
gSum += g;
bSum += b;
}
if ( aSum > 255 )
aSum = 255;
if ( rSum > 255 )
rSum = 255;
if ( gSum > 255 )
gSum = 255;
if ( bSum > 255 )
bSum = 255;
targetCursor.get().set( ARGBType.rgba( rSum, gSum, bSum, aSum ) );

I have an ImgPlus backed by an RGB PlanarImg of UnsignedByteType and
ARGBType.alpha(value) is 255 for all of them, so aSum is 765. It would
appear that the correct solution would be to divide aSum by 3. In addition,
there's no scaling of the individual red, green and blue values by their
channel's alpha. If the input were two index-color images, each of which
had different alphas, the code should multiply the r, g and b values by the
alphas before summing and then divide by the total alpha in the end. The
alpha in this case *should* be the sum of alphas divided by the number of
channels.

However, I think the problem is deeper than that. For an RGB ImgPlus, there
are three LUTs and each of them has an alpha of 255, but that alpha only
applies to one of the colors in the LUT. When you're compositing images and
weighing them equally, if two are black and one is white, then the result
is 1/3 of the white intensity - if you translate that to red, green and
blue images, the resulting intensity will be 1/3 of that desired. This
might sound weird, but the only solution that works out mathematically is
for the defaultLUTs in the DefaultDatasetView to use color tables that
return values that are 3x those of ColorTables.RED, GREEN and BLUE.
Thinking about it, I'm afraid this *is* the correct model and each channel
really is 3x brighter than possible.

It took me quite a bit of back and forth to come up with the above... I
hope you all understand what I'm saying and understand the problem and
counter-intuitive solution and have the patience to follow it. Dscho, if
you made it this far - you're the mathematician, what's your take?

--Lee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20130715/dfc96817/attachment.html>


More information about the ImageJ-devel mailing list