Yes, there was a bug related to 2x versions. Note that the hero image will be pixelated when the source image is low-resolution. Use high-resolution originals and choose a landscape image as the hero image.

That's not what it's doing. If I use an image that's 4032x3024, image bounds of 1600x1200, page width of 920, and the hero not at full width, I get a folderimage.jpg that's 1800x345 and a folderimage@2x.jpg that's 1840x480. It's never shown at anything larger than its native size, and there's no pixelation.

If I drop the image bounds to 920x920, folderimage.jpg is 920x240 and folderimage@2x.jpg is 1840x480. Again, it's never shown larger than its native size.

And don't confuse folderimage.jpg and folderimg.jpg. The former is what's being shown in the title bar.

(Off-topic, but a page that's only 920px wide looks silly on a typical 1920x1080 monitor. Why use only half the monitor? And image bounds of 920x920? Go for 1920x1080. Why cheat the site visitor out of the best show possible?)

I copied the settings from your project, and fed it images that range from only a bit larger than 920px all the way up some 4000px images, and the hero images are all 920x240.

The only way I can get a hero image that's less than that is to use an original image that's less than 920. In that case, it is, indeed, browser-enlarged into fuzziness.

In short, I see the problem in the example link you provided, but I don't know how it's possible to get that result. Tiger isn't using the built-in core routines for generating theme images, so I can't even begin to debug this. But Laza needs to take a look.

One possible hint, however. All of your folders are, in fact, views, rather than just plain folders. In my own tests, that doesn't make any difference, but maybe there's something different going on here.

Unanswered according to Jeff

Thanks for your support.

I installed jAlbum 39.1 and Tiger 7.4.7 and generated the whole album new.

Folderthumb.jpg and shareimage.jpg have been generated new. Folderthumb.jpg has a higher resolution now.

Folderimage.jpg, folderimage@2x.jpg, folderimg.jpg and folderimg@2x.jpg have not been generated new. Thus the problem is still not solved yet.

In fact, the tiger update made the things for croped images worse. Now, also the croped slide images have a lower resolution.

Look at this:

(Link removed)

vs.

(Link removed)

This is very puzzling, indeed. I grabbed zif's project file (attached), fed it a collection of images (some very large, some of a more modest size, but none less than 920px wide), and made an album. Nothing unusual in there at all:

(demo album removed)

I even included his text and logotype filters (though I had to substitute the flag, since I didn't have the original he used), thinking that there might be a filtering problem at work.

Image sizes are all exactly what one would expect.

I noticed that, in the album zif has posted, some of the slide images are less than 920px wide, because of extreme cropping, but they're being shown at the full image bounds. The tipoff is that the text and logotype are being enlarged beyond their normal sizes. So I tried the same thing. In my Folder Two, I cropped the Rolls Royce. The original is only 1024px wide, so the crop makes it much smaller. But the core and the skin are still handling it properly:

(demo album removed)

Not sure what to do next. Nothing I've tried has produced the results we're seeing in zif's album.

Edited by: JeffTucker on 8 Feb 2026, 05:13

No, I haven't changed something regarding the slide image sizes.

Yes, the high resolutions theme image is enabled. For trial and error i also disable it and then rebulid the album. After that i enabled it again and rebuilt the album. Nothing helped.

I'm no longer sure if the problem is even caused by the tiger skin. In my file backups, I saw that I last generated all the slide images on July 3, 2025. Since then, I've added many new images, but I've only generated the album using "Make test". That's probably why I only noticed now, during my complete album generation, that the problem with the cropped images exists not only with the hero image but also with some of the slide images.

Based on Jeff's feedback, I also considered whether the problem might be related to a combination of certain filters (sometimes I use crop, sometimes straighten, and sometimes both together). However, this is not the case. Not all cropped images are scaled incorrectly. It's also not the case that I'm cropping the images so much that their resolution would be less than 920 pixels. It's also not the case that the images where the error occurs being in special file formats or specially edited. The original image files have existed unchanged for years, and they were scaled correctly and without problems by jalbum in July 2025 (and before).