Test post of the new-ish avif image format alongside a jpeg file created 
by gimp with a quality level of 90.0. The avif I created with ffmpeg 
using an input png file and default settings.

The Ubuntu 24.04 support is quite good for the avif format at this 
point, though, not quite universal (netpbm).

The png file came in at 314737 bytes.
The jpg file at 64355 bytes.
The avif file at 8410 bytes (It's expensive to encode).

One of the attractive bits is the avif format supports hdr and channel 
depths of 8, 10 and 12 bits. Plus transparency - where jpeg does not.

I'm thinking about adding support for the format (in addition to pfm 
(*)) to my yuqk playpen fork.

Bill P.

(*) - The real time ray-tracing (rtr) feature in yuqk has a crude image 
capture to the pfm format today - but POV-Ray (yuqk) cannot read it or 
otherwise save to the pfm image format.

Post a reply to this message

Attachments:
Download 'matrixhmm100.avif.dat' (9 KB) Download 'matrixhmm100.jpg' (63 KB)

Preview of image 'matrixhmm100.jpg'

On 27/01/2025 15:01, William F Pokorny wrote:
> Test post of the new-ish avif image format alongside a jpeg file created 
> by gimp with a quality level of 90.0. The avif I created with ffmpeg 
> using an input png file and default settings.
> 
> The Ubuntu 24.04 support is quite good for the avif format at this 
> point, though, not quite universal (netpbm).
> 
> The png file came in at 314737 bytes.
> The jpg file at 64355 bytes.
> The avif file at 8410 bytes (It's expensive to encode).
> 
> One of the attractive bits is the avif format supports hdr and channel 
> depths of 8, 10 and 12 bits. Plus transparency - where jpeg does not.
> 
> I'm thinking about adding support for the format (in addition to pfm 
> (*)) to my yuqk playpen fork.
> 
> Bill P.
> 
> (*) - The real time ray-tracing (rtr) feature in yuqk has a crude image 
> capture to the pfm format today - but POV-Ray (yuqk) cannot read it or 
> otherwise save to the pfm image format.




It's a very good idea. however, we need to look at the development 
effort required to use this new format for out and in images.
Unless you use ready-made libraries like ImageMagick, "libheif", 
"libavif", ...



In terms of comparability, the images in your messages are clearly 
visible, with some differences, but visible.



Good job.



-- 
kurtz le pirate
compagnie de la banquise

Post a reply to this message

On 1/28/25 11:24, kurtz le pirate wrote:
> It's a very good idea. however, we need to look at the development 
> effort required to use this new format for out and in images.
> Unless you use ready-made libraries like ImageMagick, "libheif", 
> "libavif", ...
> 
> In terms of comparability, the images in your messages are clearly 
> visible, with some differences, but visible.

Thanks for the feedback.

I'm able to view the avif image by clicking on the link in firefox. Both 
the jpg and avif files show up for me in thunderbird.

We'd certainly lean on libavif. Unsure about libheif. The trickier part 
would be support for the HDR transfer functions which would need to be 
pulled into POV-Ray for full support (display_gamma).

There are also wide color gamut capabilities - some of which I guess 
ripples back into avif SDR output formats too. Could get complicated as 
there isn't currently any existing code and keyword support for it.

It's true my todo list is very long, so we'll see. The ffmpeg program 
can do single image format conversions and it supports pfm already, so
an option would be to use it for a pre or post frame script calling 
ffmpeg to do the conversion from/to avif (unsure about ImageMajick's pfm 
support).

---
Aside. While looking at the avif format I stumbled across a USA 
government site which is keeping up a large collections of latest 
official file format documents. Looked useful. See:

https://www.loc.gov/preservation/digital/formats/fdd/browse_list.shtml

Bill P.

Post a reply to this message