cfreksen

That means that SSIMULACRA2 does not capture quality perfectly.

Note that in that figure the formats are compared at the same SSIMULACRA2 score, not at the same file size. In the "very low quality" category, JPEG uses ~0.4 bpp (bits per pixel), while JPEG-XL and AVIF use ~0.13 bpp and ~0.1 bpp, respectively, so JPEG is roughly given 4 times as much space to work with. In the "med-low quality" category, JPEG-XL and AVIF use around 0.4 bpp, so perhaps you should compare the "very low quality" JPEG with "med-low quality" JPEG-XL and AVIF.

After reading your comment, I assumed you had missed the bpp difference. Please excuse me if I assumed incorrectly.

Sorry for being off topic, but what is going on with the timestamps of this paper?

The latest version (version 2) has 2018-05-28 as the date above the abstract, but it was added to arxiv on 2014-12-15. Version 1 has the date 2022-05-18, but was added to arxiv on 2010-10-29. I briefly skimmed the .tex source file, but I couldn't find any explanation of the date in there. Did someone mess with the clock on the build server?

I would say that the instance (or second long interval) in time that we name 2016-12-31T23:59:60Z is 1483228836 seconds after 1970-01-01T00:00:00Z, and that 2017-01-01T00:00:00Z is 1483228837 seconds after 1970-01-01T00:00:00Z [0].

The key here is that I use "seconds" to mean a fixed duration of time, like how long it takes light to travel 299792458 meters in a vacuum[1], and this version of seconds is independent of Earth orbiting the Sun, or the Earth spinning or anything like that[2]. If I understand you correctly, you use "seconds" more akin to how I use "days in a year": Most years have 365 days, but when certain dates starts to drift too far from some astronomical phenomenon we like to be aligned with (e.g. that the Northern Hemisphere has Summer Solstice around the 21st of June) we insert an extra day in some years (about every 4th year).

I haven't read RFC 9562 in detail, but if you use my version of "seconds" then "seconds since the Epoch" is a meaningful and monotonically increasing sequence. I suspect that some of the other commentors in this thread use this version of "seconds" and that some of the confusion/disagreement stems from this difference in definition.

The paragraph in Section 6.1 titled "Altering, Fuzzing, or Smearing" also seems relevant:

    > Implementations MAY alter the actual timestamp. Some examples include ..., 2) handle leap seconds ...
    > This specification makes no requirement or guarantee about how close the clock value needs to be to the actual time.

[0] Please forgive any off-by-one errors I might have made.

[1] I know that the SI definition between meters and seconds is the other way around, but I think my point is clearer this way.

[2] I ignore relativity as I don't think it is relevant here.