Original Whatever

As part of my task of blurring thumbnail images, I wrote some code to use ConvolveOp. ConvolveOp is basically a filter that generates a new value for each pixel of an image by mixing the value of that pixel with the values of the pixels around it. The mixing depends on a "kernel," which is a matrix of weights. The ConvolveOp filter positions the center of the kernel over each pixel of the source image, mixes the values of that pixel and its neighboring pixels together, depending on their weights in the matrix, and then assigns the result to the pixel in the destination image. The size of the kernel determines the number of neighboring pixels that are used in the convolve operation. If the kernel is 5x5 pixels, for example, then the convolve operation will include the original pixel and those up to two pixels distant. It seems simple, but ConvolveOp is actually the main (and sometimes only) building block in many image-processing operations. Basic blurring and sharpenin

While the first of the Java 2D classes that I used in my thumbnail-generation code was AffineTransformOp, in order to actually see the results, I needed to save the image. Fortunately, Java includes a library called ImageIO that can save images in various formats. The code to write out a JPEG is pretty straightforward, though if you want to set a specific quality, you can't use the one-line version. But when I opened the resulting file in Preview (I use a Mac), it was completely black! I've had experiences with weird JPEG variants before, and I figured that maybe Preview was lame and that a better program would be able to display the image. So I opened it in Photoshop. This time, I was able to see the image, but all the colors were wrong. According to Photoshop, it was a CMYK image. But the original image was RGB. How could Java 2D be loading an RGB image, scaling it, then producing a CMYK JPEG? And anyway, the file obviously wasn't really a CMYK image: the color

Some time ago, I blogged about using UUIDs as primary keys . To quickly recap, because programs can generate UUIDs directly, without having to consult an external ID-generation service such as a database, using UUIDs as primary keys enables developers to avoid having to deal with the differences between persistent and transient instances of the same class and allows them to develop classes that are completely independent of the database. And because UUIDs are globally unique, they facilitate the creation of system that can operate in a disconnected fashion and then sync up later. After working with a system that uses UUIDs for primary keys, I come around to the idea that database-generated keys aren't so bad after all. But, I think that the key (pardon the pun) is to keep them in the database. To that end, I have been creating Java classes that have UUIDs and use them to implement equals and hashCode, but that simultaneously have an integer ID field that is assigned from the da