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.

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 just found

http://www.cssjuice.com/25-rounded-corners-techniques-with-css/
which links to
http://www.webcredible.co.uk/user-friendly-resources/css/css-round-corners-borders.shtml

which gives this recipe

The HTML to achieve this effect is:

<div class="bl"><div class="br"><div class="tl"><div class="tr">
Lorem ipsum dolor sit amet consectetur adipisicing elit
</div></div></div></div>

And the CSS that makes it all happen:

.bl {background: url(bl.gif) 0 100% no-repeat}
.br {background: url(br.gif) 100% 100% no-repeat}
.tl {background: url(tl.gif) 0 0 no-repeat}
.tr {background: url(tr.gif) 100% 0 no-repeat; padding:10px}

I haven't had time to test this, but thought you might like to beat me to it

Edited by: jimberry on 08-Jan-2012 01:54
OOPS!! That one is no better than mine, it uses FOUR gifs and FOUR nested divs!!!!!!!!!

Edited by: jimberry on 08-Jan-2012 02:11

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

Yes, it's a cool illusion indeed. Great that you couldn't break stuff this time
Too bad we haven't heard from the original poster though.

Edited by: davidekholm on 09-Jan-2012 18:08

Hi David,

it seems jAlbum can't write back the keywords to the png.

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!