Posts:
3,905
Registered:
18-Oct-2002
|
|
|
|
jAlbum 39 beta for testing
Posted:
21 Dec 25, 02:29
|
|
|
Hi everyone,
jAlbum 39 is soon to be released. The big news with this version is read and write support for the superior AVIF image format. AVIF is supported by basically all browsers today and is seen as the successor to JPEG.
AVIF advantages over JPEG:
- Far better compression. Typically 1/3 or better vs JPEG
- Support for transparency
- Support for HDR
- Support for higher bit depth than 8 (finer color gradients)
- Animation support
- Support for lossless
- Open format. Not license infested
I could go on for ages on how good AVIF is, but refer to https://jakearchibald.com/2020/avif-has-landed/
... or how about these jAlbum galleries:
Yes, it's right. That AVIF example is only 16% the size of the JPEG gallery! You can figure out that this allows for more images on the same storage space and faster delivery
In jAlbum we're using top performing native code for both AVIF reading and writing
The beta has AVIF settings in two locations:
- Album Settings - Images - AVIF (quality and speed)
- Preferences - Advanced - AVIF (codec choices)
The beta ships with the following codecs:
Reading:
- "aom" (Fast reference implementation)
- "dav1d" (Super fast and memory slim)
Writing:
- "aom" (Fast reference implementation)
- "SVT_AV1" (Fast, heavily accelerated)
I'll leave it to you to experiment with various combinations of HEIC compression quality, speed and codec settings. Here are my finding so far:
- AVIF gives good results even at low quality settings (30% for instance)
- The "aom" reference implementation is not always slower than the heavily accelerated ones. There is in fact fast SIMD assembly instructions in the "aom" implementation as well
- Speed is as interesting to "play" with as quality. Lower speeds gives better results and smaller files
I'm super stoked about this release. What do you think?
Installers:
Windows: https://jalbum.net/download/jAlbum-install.exe
Mac (M-series): https://jalbum.net/download/jAlbum-M.dmg
Mac (Intel): https://jalbum.net/download/jAlbum.dmg
Linux (Intel): https://jalbum.net/download/jalbum_39.0-1_amd64.deb
Linux (arm): https://jalbum.net/download/jalbum_39.0-1_arm64.deb |
|
|
Posts:
3,905
Registered:
18-Oct-2002
|
|
|
|
Re: jAlbum 39 beta for testing
Posted:
21 Dec 25, 02:35
in response to: davidekholm
|
|
|
|
If we all agree on what codecs are superior, then we can leave out the others. I suggest that we use "dav1d" for reading and "SVT_AV1" for writing.
Also, I haven't yet implemented support for EXIF and xmp in AVIF, but as I'm actually interfacing directly with the native code libraries (using Java 23:s super fast FFM API) I can add support for EXIF and xmp soon.
As I said, browser support is almost complete, but should you worry about the <1% that can't handle AVIF (that means Internet Explorer), then just add AVIF as a Variant and use JPEG as the "typical" image. Then the browser falls back to JPEG in case it cannot handle AVIF.
|
|
|
Posts:
3,905
Registered:
18-Oct-2002
|
|
|
|
Re: jAlbum 39 beta for testing
Posted:
21 Dec 25, 02:46
in response to: davidekholm
|
|
|
|
Set jAlbum's logging level to "CONFIG" to see what codec was picked during album builds (printed to system console)
|
|
|
Posts:
8,179
Registered:
31-Jan-2006
|
|
|
|
Re: jAlbum 39 beta for testing
Posted:
21 Dec 25, 03:50
in response to: davidekholm
|
|
|
Kind of a non-starter. I can't load any skin other than the bundled ones. Exception in thread "Skin loading thread" java.lang.NoClassDefFoundError: Could not initialize class org.codehaus.groovy.runtime.InvokerHelper
at groovy.lang.GroovyObjectSupport.getDefaultMetaClass(GroovyObjectSupport.java:46)
at groovy.lang.GroovyObjectSupport.<init>(GroovyObjectSupport.java:32)
at groovy.lang.Binding.<init>(Binding.java:36)
at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl$2.<init>(GroovyScriptEngineImpl.java:236)
at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:236)
at org.codehaus.groovy.jsr223.GroovyCompiledScript.eval(GroovyCompiledScript.java:72)
at java.scripting/javax.script.CompiledScript.eval(Unknown Source)
at se.datadosen.jalbum.AlbumBean.processExpression(AlbumBean.java:3560)
at se.datadosen.jalbum.AlbumBean.processScript(AlbumBean.java:3482)
at se.datadosen.jalbum.JAlbumFrame.executeScript(JAlbumFrame.java:1360)
at se.datadosen.jalbum.JMainSettingsPanel$5$1.run(JMainSettingsPanel.java:369)
Caused by: java.lang.ExceptionInInitializerError: Exception java.lang.ExceptionInInitializerError [in thread "Skin loading thread"]
at org.codehaus.groovy.runtime.InvokerHelper.<clinit>(InvokerHelper.java:71)
... 11 more
ETA: But, as I suspected, I needed to do a complete housecleaning and reinstall to get anywhere. The presence of both C:\Program FIles\jAlbum and C:\Program Files\JAlbum AB\jAlbum was creating all sorts of havoc.
First quick tests look OK. Probably time to scrub WebP out of the app entirely. |
|
|
Posts:
8,179
Registered:
31-Jan-2006
|
|
|
|
Re: jAlbum 39 beta for testing
Posted:
21 Dec 25, 04:10
in response to: JeffTucker
|
|
|
|
Changing the AVIF image quality or speed is not triggering reprocessing of the slide images. Only a Force Remake does the trick.
The AVIF processing is quite a bit slower than JPG.
|
|
|
Posts:
8,179
Registered:
31-Jan-2006
|
|
|
|
Re: jAlbum 39 beta for testing
Posted:
21 Dec 25, 04:28
in response to: JeffTucker
|
|
|
|
Here's a nice, obscure one for you! When viewing an AVIF image from a server, or from the C:\ drive locally, it's served as type avif. But when viewed from the jAlbum preview server, 127.0.0.1:8080, it gets coughed up as type octet-stream.
For ordinary web pages, browsers will tolerate this. But if you've got a link that's trying to open the image in a new browser tab, it doesn't work from the built-in jAlbum web host. The browser doesn't know that it's supposed to open the image in a new tab, and offers to download it, instead. The browser knows that it can open an avif directly, but it's uncertain about an octet-stream.
ETA: intriguingly, Firefox gets it right, but the Chrome family of browsers do not.
|
|
|
Posts:
8,179
Registered:
31-Jan-2006
|
|
|
|
Re: jAlbum 39 beta for testing
Posted:
21 Dec 25, 04:50
in response to: JeffTucker
|
|
|
|
Just some quick testing, feeding it some of the images that used to trip up the WebP converter, I'm finding that I can dial the AVIF quality down to 40% or less, with no visible loss of clarity or smoothness (unlike the "blocky" clouds I always ran into with WebP images), and file sizes less than half the equivalent JPG's.
Interesting side note: with AVIF at 40%, you can choose HiDPI Images, but end up with file sizes about the same as the single-density JPG's.
(Devil's Advocate: All the more reason to get rid of variants. Just set the image bounds nice and big, and feed all visitors the same images.)
|
|
|
Posts:
8,179
Registered:
31-Jan-2006
|
|
|
|
Re: jAlbum 39 beta for testing
Posted:
21 Dec 25, 04:55
in response to: JeffTucker
|
|
|
|
"jAlbum 2026! Now with Polybendum!!"
(One million bonus points to anyone who recognizes the exceedingly obscure reference without Googling it.)
|
|
|
Posts:
44
Registered:
1-Sep-2009
|
|
|
|
Re: jAlbum 39 beta for testing
Posted:
21 Dec 25, 09:34
in response to: davidekholm
|
|
|
|
can I just ask an ignorant question..is this new format mainly if your start from raw and then normally go jpeg to publish?
what if you shoot jpeg..so your originals are jpeg..will there be any sense in letting JA convert format to the new AVIF?
|
|
|
Posts:
3,905
Registered:
18-Oct-2002
|
|
|
|
Re: jAlbum 39 beta for testing
Posted:
21 Dec 25, 10:58
in response to: JeffTucker
|
|
|
Changing the AVIF image quality or speed is not triggering reprocessing of the slide images. Only a Force Remake does the trick.
The AVIF processing is quite a bit slower than JPG.
Yes, I'm aware of that. Will fix that for the next beta. Just isn't implemented yet.
As for the speed, do set the speed setting higher. Try 10. Now it encodes super fast. Yes, it comes with a size and quality penalty, but fairly modest I'd say.
As for speed, make sure you also play with the various encoders (aom, SVT_AV1), in some speeds one outbeats the other. |
|
|
Posts:
3,905
Registered:
18-Oct-2002
|
|
|
|
Re: jAlbum 39 beta for testing
Posted:
21 Dec 25, 11:02
in response to: JeffTucker
|
|
|
Changing the AVIF image quality or speed is not triggering reprocessing of the slide images. Only a Force Remake does the trick.
The AVIF processing is quite a bit slower than JPG.
If you use the "aom" encoder with speed 1, you will get an awfully slow encoding. See it as a way to check for a theoretical maximum, not a practical setting for a large gallery.
Also, you will need a fairly modern computer for the codecs to make use of the faster assembly instructions. |
|
|
Posts:
3,905
Registered:
18-Oct-2002
|
|
|
|
Re: jAlbum 39 beta for testing
Posted:
21 Dec 25, 11:04
in response to: JeffTucker
|
|
|
(Devil's Advocate: All the more reason to get rid of variants. Just set the image bounds nice and big, and feed all visitors the same images.)
I just felt the addition of AVIF was an excellent case for using Variants, in case you're worried about that <1% that don't support it 
|
|
|
Posts:
3,905
Registered:
18-Oct-2002
|
|
|
|
Re: jAlbum 39 beta for testing
Posted:
21 Dec 25, 11:09
in response to: wolf-skate
|
|
|
can I just ask an ignorant question..is this new format mainly if your start from raw and then normally go jpeg to publish?
what if you shoot jpeg..so your originals are jpeg..will there be any sense in letting JA convert format to the new AVIF?
Sure it is, as long as the JPEGs are far larger dimension-wise (to avoid passing on JPEG artifacts), I'd recommend using AVIF any day. We need to address xmp embedding though, if that's important for you.
But, yes, I can see AVIF replacing RAW in many cases. It has the added bit depth that you usually only got with RAW. Note: our decoder isn't probably supporting high bit depth AVIFs right now, but I aim to at least make it understand and down-sample them to 8 bit.
As for high bit depth images: Java does handle such images. There's a special case of BufferedImage that can manage them, but I bet fairly few image filters will support such BufferedImages, and they are probably implemented in software only (slow) |
|
|
Posts:
3,905
Registered:
18-Oct-2002
|
|
|
|
Re: jAlbum 39 beta for testing
Posted:
21 Dec 25, 11:11
in response to: JeffTucker
|
|
|
Here's a nice, obscure one for you! When viewing an AVIF image from a server, or from the C:\ drive locally, it's served as type avif. But when viewed from the jAlbum preview server, 127.0.0.1:8080, it gets coughed up as type octet-stream.
For ordinary web pages, browsers will tolerate this. But if you've got a link that's trying to open the image in a new browser tab, it doesn't work from the built-in jAlbum web host. The browser doesn't know that it's supposed to open the image in a new tab, and offers to download it, instead. The browser knows that it can open an avif directly, but it's uncertain about an octet-stream.
ETA: intriguingly, Firefox gets it right, but the Chrome family of browsers do not.
Good one. We can probably add the right mime-type somewhere. |
|
|
Posts:
44
Registered:
1-Sep-2009
|
|
|
|
Re: jAlbum 39 beta for testing
Posted:
21 Dec 25, 12:27
in response to: davidekholm
|
|
|
Sure it is, as long as the JPEGs are far larger dimension-wise (to avoid passing on JPEG artifacts), I'd recommend using AVIF any day. We need to address xmp embedding though, if that's important for you.
xmp not important to me, but originals in jpg will also only have 8bit colour, right..so colour depth advantage does NOT? come into play when then converting into AVIF?
But, yes, I can see AVIF replacing RAW in many cases. It has the added bit depth that you usually only got with RAW. Note: our decoder isn't probably supporting high bit depth AVIFs right now, but I aim to at least make it understand and down-sample them to 8 bit.
do you think camera manufacturer will give options to shoot directly i AVIF? .. mine are to old for that I think (SOny RX100 and Fuji XT2)
also some talk about different jpeg progressions (jpeg XL?)
was skinning this comparison for formats
https://www.goodlookingdesign.co.uk/blog/webp-avif-png-or-jpg-what-image-file-should-you-use-for-websites-and-is-it-sustainable
and hard to tell differences (for my eyes), but that author is pt sticking to webP?..seems the primary 'down side' on AVIF is code/decode time..so should one consider using the variants option, say jpeg for fast browsing and the AVIF for detail?..if so can current albums be converted to include new variant w AVIF without having to remake and re-upload the existing jpeg images? |
|
|
|
Legend
|
|
Forum admins
|
|
Helpful Answer
|
|
Correct Answer
|
|
