<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Custom Alpha Compositing</title>
	<atom:link href="http://blog.palantirtech.com/2007/03/27/custom-alpha-compositing/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.palantirtech.com/2007/03/27/custom-alpha-compositing/</link>
	<description>Just another WordPress weblog</description>
	<pubDate>Fri, 21 Nov 2008 13:16:10 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.1</generator>
		<item>
		<title>By: Carl</title>
		<link>http://blog.palantirtech.com/2007/03/27/custom-alpha-compositing/#comment-31</link>
		<dc:creator>Carl</dc:creator>
		<pubDate>Fri, 25 May 2007 22:58:03 +0000</pubDate>
		<guid isPermaLink="false">http://blog.palantirtech.com/2007/03/27/custom-alpha-compositing/#comment-31</guid>
		<description>It sounds like your output buffer/raster doesn't support transparency.  Though I'm unfamiliar with getNumBands() and it's horribly documented, it appears to be the number of channels supported.  You need Red, Green, Blue, and Alpha, but probably only have RGB.  You'll see above that SourceAlphaComposite references supporting BufferedImage.TYPE_4BYTE_ABGR BufferedImage.TYPE_INT_ARGB.  Both of these image types support alpha transparency, which not all images do.  Possibly you can change the instantiation of whatever you're painting to.  If you have no control over what you're painting to, perhaps you can paint your layers to a BufferedImage of identical size first, then paint the composited picture to the destination.

In other news, further research reveals that AlphaComposite.DstIn is a provided Composite implementation that does most of what we needed SourceAlphaComposite for.

-Carl</description>
		<content:encoded><![CDATA[<p>It sounds like your output buffer/raster doesn&#8217;t support transparency.  Though I&#8217;m unfamiliar with getNumBands() and it&#8217;s horribly documented, it appears to be the number of channels supported.  You need Red, Green, Blue, and Alpha, but probably only have RGB.  You&#8217;ll see above that SourceAlphaComposite references supporting BufferedImage.TYPE_4BYTE_ABGR BufferedImage.TYPE_INT_ARGB.  Both of these image types support alpha transparency, which not all images do.  Possibly you can change the instantiation of whatever you&#8217;re painting to.  If you have no control over what you&#8217;re painting to, perhaps you can paint your layers to a BufferedImage of identical size first, then paint the composited picture to the destination.</p>
<p>In other news, further research reveals that AlphaComposite.DstIn is a provided Composite implementation that does most of what we needed SourceAlphaComposite for.</p>
<p>-Carl</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dan</title>
		<link>http://blog.palantirtech.com/2007/03/27/custom-alpha-compositing/#comment-28</link>
		<dc:creator>Dan</dc:creator>
		<pubDate>Fri, 25 May 2007 22:04:07 +0000</pubDate>
		<guid isPermaLink="false">http://blog.palantirtech.com/2007/03/27/custom-alpha-compositing/#comment-28</guid>
		<description>Hello,
For some reason I can't modify the alpha on the destination writable raster.
When I call dstOut.getNumBands() I get 3 which I suspect is the source of the problem because when I call src.getNumBands() I get 4. The destination raster seems to be missing a band.

Any idea of how I can make sure the writable raster has 4 bands?

Thanks,
Dan.</description>
		<content:encoded><![CDATA[<p>Hello,<br />
For some reason I can&#8217;t modify the alpha on the destination writable raster.<br />
When I call dstOut.getNumBands() I get 3 which I suspect is the source of the problem because when I call src.getNumBands() I get 4. The destination raster seems to be missing a band.</p>
<p>Any idea of how I can make sure the writable raster has 4 bands?</p>
<p>Thanks,<br />
Dan.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
