OK, here's the rundown on the 10.3.1 results with the same images:
Transparent PNGs produce images with solid black backgrounds, rather than transparent (pretty much as expected). The transparent GIF produces an image with a solid white background. The regular GIF looks normal (conversion to a JPG doesn't really change it).
Tint filter: produces the same error with GIFs (won't process them at all), and the same color shift with PNGs. So, no change from 10.4b1.
Logo filter: OK with all images, including non-transparent GIF - better than 10.4b1.
Watermark filter: OK with all images, including non-transparent GIF - better than 10.4b1.
Blur filter: OK with all images, including non-transparent GIF - better than 10.4b1.
XBorderFilter: as expected, it treats the images as normal JPGs, with a drop-shadow around the edge. Since the image is not transparent, the drop-shadow works as designed.
So, jAlbum 10.4b1 has problems with non-transparent GIFs that 10.3.1 didn't have. I think my recommendation would be to confine the new image handling to PNGs, and let jAlbum convert GIFs to JPGs, the way it used to. That leaves transparent GIFs out in the cold, but it's my understanding that the GIF format is dying, anyway.
And neither approach is going to take care of animated GIFs - I guess that's always going to need a manual substitution in the finished album.
XBorderFilter can still do some things that there's no good way of doing in CSS3 yet. The semi-transparent inset borders come to mind. Multi-color frames in CSS require a bunch of pseudo-elements - I haven't played with them, but it looks really klunky. And doing brackets is pretty dicey.
Brackets shouldn't be any more difficult than any other frame.
I was hoping you'd chime in on this subject - you have more CSS experience than I do. In fact, it was one of your comments relating to CSS3 box-shadows that got me headed down the path I'm on for Matrix 7.
In this case, I was thinking about whether you could do brackets without using an external image or not. That's the virtue of XBorderFilter - you can just specify location and color, without having to cough up an image file to use for the borders.
But I'll bet there's some evil genius out there who's figured out a way to do it without an image file. It probably doesn't require more than half-a-dozen pseudo-elements and nested div's.
I have to admit I did use a PNG image for the brackets.
I haven't tried, but I was wondering whether you could finagle the "round corners" trick but probably not - I don't think you can have the corners without the sides being the same color
OOPS!! That one is no better than mine, it uses FOUR gifs and FOUR nested divs!!!!!!!!!
I don't mind wrestling with nested div's, but any solution that relies on image files is off the table, for me. Remember, I'm the guy with the "absolutely any colors" skins, in which maintaining several million color GIFs or PNGs is not exactly a workable solution.
It seems like EarlyOut was able to catch a whole set of bugs with translucent images, applying filters and jAlbum 10.4b1, furthermore you found bugs when applying some filters to GIF images too. I've therefore rewritten stuff again (the album engine and most filters, but left XBorderFilter untouched), so please try again.
Now I don't get color shifts on your sample GIF and it doesn't bail out on that GIF either. Furthermore transparency / translucency seems to be preserved correctly when applying filters. Finally, the changes made seem to make jAlbum process images faster too. Do you notice that too? (from 1 minute to 43 seconds with a sample album and "medium" scaling). Don't ask me why
Looking very, very good. I ran through all of the filters, and everything seems to be behaving itself - no error messages (I checked the console, too), and no unexpected color shifts. It also handles the transparent GIF correctly (the Paypal donate button I attached, above), without shifting its background to black.
(BTW, that bluegreen.gif file is a wonderful illusion. See the blue and green spiral bands? Guess what - they're both exactly the same color, #00ff96.)
This XMP Specification document suggests that embedding XMP metadata in PNG files is possible (see page 97).
However, how easy (or rather difficult) it would be to implement this within jAlbum using Java I have no idea!
It's not that easy I'm afraid. The library we're using (Apache Sanselan) states it supports embedding xmp into png files, but I cannot figure out how. The ordinary routine we use to update xmp blocks only supports JPEG files and the PNG writer of Apache Sanselan does not take an xmp block as parameter.