Yes, if you do "all AVIF" for the output format, the downloads will be AVIF files. No problem pretty much anywhere in Windows or Mac. They show up in File Explorer/Finder and in whatever preview app you're using, and I've just confirmed that the Photos app on macOS and iOS are perfectly happy with the format.

I'd be less certain about Walmart printing. They should be able to handle it, but I'd like to try that out "live."

If you want to drag an AVIF into your favorite photo editor, things get murkier. I'm running an old-ish version of Adobe Photoshop Elements, and it won't open an AVIF. I believe that even in the current version, you need a plugin for it.

Paint.NET is perfectly happy with it, on the other hand. We'll all need to do some experimenting.


And completely addled.

I just tried letting jAlbum generate AVIF's, then using those images as input to a new project.

For openers, List metadata can't swallow them at all. The image editing tools run the gamut, from behaving normally to doing some very strange things. For example, open an AVIF for editing, then try rotating it.

At this stage, I think the advice to users is to continue to feed jAlbum the largest JPG's they've got, then let jAlbum scale them to AVIF's for the album. In short, write AVIF, but don't try to read AVIF.

(This experience also illustrates why a lot of image editing software can't take the format - it's very unlike JPG, and is more akin to a single frame from a video. A strange beast.)

AVIF's heritage from video encoders is noticed when using the SVT_AV1 encoder. It's actually primarily a video encoder that we use to take single picture snapshots. Other than that I don't think it's anything strange with the format itself. The standard reference "aom" encoder is made to encode still images from still images.

As for metadata and rotating images: I plan to add metadata support before releasing the beta. Keep your fingers crossed that it is a smooth ride. The good thing is that I'm now interfacing directly with the native code, so I don't need to rely on the "mercy" of some other small 3:rd party "java-glue" developer

As Jeff said, continue feeding jAlbum large JPEGs and let jAlbum do the final scaling and AVIF conversion. When image writers (cameras etc) support AVIF better, then that format would be my primary output format as it has deeper color depth and HDR support, and better compression, and... (paste list of AVIF advantages)

I'll see about that. The quality settings should go under a "Writing" section. They are not scaling specific

To the vast majority of jAlbum users, that's a distinction without a difference.

Will JPG originals be converted to AVIF if that's the output format choice and if only originals are included?

Probably not. Originals should be untouched.

Not a good thing.

On what OS and architecture are you getting that error? When you get that error again, open the system console and issue:

net.jalbum.avif.Avif.getInitError();

. That should provide more details.