Crossfades: What Is and Isn't Possible

Recently I tried to implement a crossfade between two translucent BufferedImages. This turned into a whole mess of code and theories; none of which really give me what I'm looking for. I'd like to thank Werner, Ken and Paul for their opinions on the subject.

The Simple Case

If both images are opaque, then this exercise is easy:

g.drawImage(img1, 0, 0, null);
g.setComposite(AlphaComposite.getInstance(AlphaComposite.SRC_OVER,t));
g.drawImage(img2, 0, 0, null);

This is probably how most slideshow transitions work. It's elegant and simple, but it fails for translucency:

Suppose img2 has large transparent areas where img1 is opaque: in this case we need to fade out img1, in addition to fading in img2:

g.setComposite(AlphaComposite.getInstance(AlphaComposite.SRC_OVER,1-t));
g.drawImage(img1, 0, 0, null);
g.setComposite(AlphaComposite.getInstance(AlphaComposite.SRC_OVER,t));
g.drawImage(img2, 0, 0, null);

This may not give the desired visual effect, though. In areas where both img1 and img2 are opaque, at t = .5 the destination will have an opacity of only 75%.

Background

Why 75%? The short answer is: AlphaComposites are not designed to crossfade. (In fact, they were originally designed for Star Trek special effects, but that's another story.) The javadocs explain the formula for SRC_OVER composites is:

Ar = As + Ad*(1-As)

So in our case:

As = t
Ad = 1-t
Ar = t + (1-t)*(1-t)
Ar = t^2-2t+t+1
Ar = t^2-t+1

This is a parabola where Ar is 1 at t = 0 and t = 1, but at its minimum Ar is only .75. If you study the equations and how the composites work: it appears impossible to use AlphaComposites to crossfade two images so these requirements are met:

1. The initial image is completely invisible at t = 1, and the final image is completely invisible at t = 0.


2. If two pixels at the same (x,y) location have an alpha of k, then at all times during the crossfade the destination pixel should have an alpha of k.

Alternatives

So what is possible, then? I put together a test program that compares different approaches to this problem:

Squared Composite: This builds on the simple implementation above, except img1 decreases more slowly and img2 increases faster. The result is that there is more overlap, so the two alpha values will be more opaque in the middle. The function now had a minimum of Ar = .93-ish.

g.setComposite(AlphaComposite.getInstance(AlphaComposite.SRC_OVER,1-t*t));
g.drawImage(img1, 0, 0, null);
g.setComposite(AlphaComposite.getInstance(AlphaComposite.SRC_OVER,1-(1-t)*(1-t)));
g.drawImage(img2, 0, 0, null);

.93 opacity isn't bad. However that assumes we're working with opaque pixels. If we work with pixels whose alpha values are .5, then we're layering two reasonably-opaque pixels on top of each other, and the resulting pixel is visibly more opaque than it should be (at As = Ad = .5, for example, they would combine to about Ar = .6.)

Complicated Composite: One approach to this problem is to play around with other composites, and see if a combination of other composites can relieve this problem. Here's one such combination:

g.setComposite(AlphaComposite.getInstance(AlphaComposite.SRC_OVER,1-t)); 
g.drawImage(img1, 0, 0, null); 
g.setComposite(AlphaComposite.getInstance(AlphaComposite.SRC_OVER,t)); 
g.drawImage(img2, 0, 0, null); 
float total = 1-t+t*t; 
g.setComposite(AlphaComposite.getInstance(AlphaComposite.SRC_IN,
  (float)(Math.pow(total,.2)))); 
g.drawImage(img1, 0, 0, null); 
g.drawImage(img2, 0, 0, null); 
g.setComposite(AlphaComposite.getInstance(AlphaComposite.SRC_OVER,1-t)); 
g.drawImage(img1, 0, 0, null); 
g.setComposite(AlphaComposite.getInstance(AlphaComposite.SRC_OVER,t)); 
g.drawImage(img2, 0, 0, null); 

This was found mainly through trial-and-error, but the basic concept is: at the end we apply the "simple composite" approach, but before that we prep the graphics destination with a ghosted copy of both images. This helps soften (or compensate for) the shortcomings of the simple approach.

As discussed below: this approach works with reasonable accuracy, but it's expensive to calculate.

Raster-Based Approach: Forget AlphaComposites. Go straight to the source. Directly grab each pixel component and say:

Cr = Cd*(1-t)+Cs*t

This has a 0% error rate: because it's exactly what we're looking for. But it's also by my tests the most expensive approach.

Results

To compare each of these approaches, I measured the time they take to complete, the memory allocation, and the accuracy. Now "accuracy" can be measured several ways: I chose to measure how much opacity changed for specific pixels that should have a constant opacity. (If you're facing this problem you may need to rewrite the tests with a different definition of accuracy/error.)

Here is a graph showing the error of each approach:

The last two raster-based approaches have zero error, so they don't make an impression on the chart. At its worst the complicated composite approach has an error of about .045. In my experience this is hardly noticeable, especially compared with the .13 error the simplest approach shows.

But the performance of the most accurate approaches make them less desirable:

Each figure here represents the time it takes to make 100 calls to each method, dealing with images that are 200x200 pixels in size.

And the memory performance also favors the simplest methods:

The difference in the two raster-based approaches is: one crossfades 1 row of pixels at a time, and other approach crossfades all pixels in the entire image in one pass. As you can see, dealing with all the pixels at once saves a little time, but is much worse for memory.

Also: a word about memory. Usually when we optimize "performance" we worry only about speed, but memory allocation can be equally important. If developers are sloppy with memory, it has a direct impact on performance:

• Excessive allocations (and not properly letting go of objects) can result in paging memory to run your application. This can range from a "bad" user experience to "catastrophic", depending on what your program does.


• Also sloppy memory allocation means the garbage collector has to run more frequently. On slower computers this can result in visible "burps" while the program is unusable. True: you can configure the garbage collection to run at certain intervals or when the heap reaches certain levels to minimize this problem: but dealing with memory allocation responsibly is still the best practice.

Conclusions

Ideally it'd be great to see a CrossfadeComposite class. This is effectively what the raster-based solution was, but my solution narrowly focused on specific types of images and ColorModels, and it would take some time/energy to extend it to a generic Composite class.

But even then: performance probably isn't going to be what we'd like. (A custom composite in Java won't perform on par with AlphaComposites anyway: AlphaComposites are probably optimized for the platform's graphics pipelines.)

The best thing to do in the mean time is to avoid translucent images! Opaque images are so much simpler. In cases where translucency is unavoidable though: this page outlines a few different options. You can pick which one is "less evil".