Package: firefox-esr
Version: 115.9.0esr-1~deb12u1
Severity: wishlist
In the upstream issue report on this, https://bugzilla.mozilla.org/show_bug.cgi?id=680385 https://bugzilla.mozilla.org/show_bug.cgi?id=680385, the last statement 38 contains “webp probably compresses just as well if not better”. This is extremely
wrong in my tests for a file of mine. As I don't have sufficient rights in bugzilla, I ask someone who has sufficient rights to comment there and, if possible, reopen the upstream issue report.
Here's my test. My original file, a nonpublic (sorry about that) portrait photograph, is of size 1483651 bytes. The goal was to compress it as much as possible with GIMP in 1 pass such that the face is still recognizable; we allow color artifacts and a
heavily rasterized image. Here are the test results (the first column is the size in bytes, the second column is the format and the settings used for saving):
35623 JPEG, 4:2:0 subsampling, integers
35619 JPEG, 4:2:0 subsampling, float-point numbers
35618 JPEG, 4:2:0 subsampling, fast integers
35254 JPEG, 4:2:0 subsampling, full aliasing, integers
35252 JPEG, 4:2:0 subsampling, full aliasing, float-point numbers
35248 JPEG, 4:2:0 subsampling, full aliasing, fast integers
25656 WEBP, Photo
25484 WEBP, Picture
25364 WEBP, Default
25342 WEBP, Drawing
20720 WEBP, Icon
20720 WEBP, Text
7892 JPEG, arithmetic encoding, 4:2:0 subsampling, full aliasing, integers
7891 JPEG, arithmetic encoding, 4:2:0 subsampling, full aliasing, floating-point numbers
7879 JPEG, arithmetic encoding, 4:2:0 subsampling, full aliasing, fast integers Of course, we used quality 0 in all places.
As we see, the smallest JPEG file created with the arithmetic encoding blows
- the smallest file created with a WEBP encoding by a factor of around 2.6 and - the smallest JPEG file created without the arithmetic encoding by a factor of around 4.5.
Also, both epiphany-browser and chromium do show this smallest file created with the arithmetic encoding (and the face on the compressed image is still recognizable).
In my view, both news together (astonishing file-size ratios and support in other browsers) is sufficient at least to reopen the issue report closed 4 years ago (regardless of how to resolve this and who would do this).

--==bound.0.bf820975201a2b5d8c92c9cc16d0796d.mail.rambler.ru=Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=utf-8

<div>Package: firefox-esr</div><div><br></div><div>Version: 115.9.0esr-1~deb12u1</div><div><br></div><div>Severity: wishlist</div><div><br data-mce-bogus="1"></div><div><br></div><div><br></div><div>In the upstream issue report on this, <a href="https://
bugzilla.mozilla.org/show_bug.cgi?id=680385" data-mce-href="https://bugzilla.mozilla.org/show_bug.cgi?id=680385">https://bugzilla.mozilla.org/show_bug.cgi?id=680385</a> , the last statement 38 contains “webp probably compresses just as well if not
better”. This is extremely wrong in my tests for a file of mine. As I don't have sufficient rights in bugzilla, I ask someone who has sufficient rights to comment there and, if possible, reopen the upstream issue report.</div><div><br></div><div>Here's
my test. My original file, a nonpublic (sorry about that) portrait photograph, is of size 1483651 bytes. The goal was to compress it as much as possible with GIMP in 1 pass such that the face is still recognizable; we allow color artifacts and a heavily
rasterized image. Here are the test results (the first column is the size in bytes, the second column is the format and the settings used for saving):</div><div><br></div><div><br></div><div>35623 JPEG, 4:2:0 subsampling, integers</div><div><br>35619
JPEG, 4:2:0 subsampling, float-point numbers</div><div><br>35618 JPEG, 4:2:0 subsampling, fast integers</div><div><br>35254 JPEG, 4:2:0 subsampling, full aliasing, integers</div><div><br>35252 JPEG, 4:2:0 subsampling, full aliasing, float-point numbers</

<div><br>35248 JPEG, 4:2:0 subsampling, full aliasing, fast integers</div><div><br>25656 WEBP, Photo</div><div><br>25484 WEBP, Picture</div><div><br>25364 WEBP, Default</div><div><br>25342 WEBP, Drawing</div><div><br>20720 WEBP, Icon</div><div><br>

20720 WEBP, Text</div><div><br>&nbsp;7892 JPEG, arithmetic encoding, 4:2:0 subsampling, full aliasing, integers</div><div><br>&nbsp;7891 JPEG, arithmetic encoding, 4:2:0 subsampling, full aliasing, floating-point numbers</div><div><br>&nbsp;7879 JPEG,
arithmetic encoding, 4:2:0 subsampling, full aliasing, fast integers</div><div><br></div><div><br></div><div><br></div><div>Of course, we used quality 0 in all places.</div><div><br></div><div>As we see, the smallest JPEG file created with the arithmetic
encoding blows</div><div><br></div><div><div>- the smallest file created with a WEBP encoding by a factor of around 2.6 and</div><div><br></div><div>- the smallest JPEG file created without the arithmetic encoding by a factor of around 4.5.</div><div><br>
</div><div>Also, both epiphany-browser and chromium do show this smallest file created with the arithmetic encoding (and the face on the compressed image is still recognizable).</div><div><br></div><div>In my view, both news together (astonishing file-
size ratios and support in other browsers) is sufficient at least to reopen the issue report closed 4 years ago (regardless of how to resolve this and who would do this).</div></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)