quikee

But this is quite a different format than JPEG or better said the subset of JPEG that we know today as JPEG format and the JPEG encoder/decoders support. The whole JPEG format did have support for a lossless mode for JPEG (different one than JPEG LS), arithmetic coding and 12-bit images too, but those features just didn't make it into the implementations of the format (arithmetic coding initially did, but was removed from popular implementations because of patents).

But supported by no browser today and software support in general is quite limited. If the PNG authors would just incorporate this possibility into PNG from start it would be interesting, but it's too late now.

"Collabora clearly has a conflict of interest, as their Collabora Office products both benefit from, and compete with LibreOffice proper."

But that was the point of TDF: being an umbrella for the community and the commercial partners. Commercial partner having its own interests is something that was expected and encouraged as long as the work would be done for the common good on the LibreOffice codebase. For the TDF itself there are COI policies in place as well from the very beginning.

"A non-profit dedicated to promoting open source software should do what is best for that project and its users regardless of if doing so steps on the toes of corporate sponsors."

That kind of thinking is what brought this result - especially when the corporate and the non-profit are supposed to be partners and work together for the common good. The result should be dialog to find a compromise that would work for both sides. So in this case forcefully reversing a previous decision and ignoring the de-atticisation rule (having active developers working on the code-base) was a needless aggressive move that just worsened the situation. And the reason for the move according to the TDF board was to "start the discussion".

Note that the proper procedure for de-atticisation of the LOOL codebase would be to confirm there is notable developer activity. Users wanting LOOL is NOT enough and the TDF board has clearly ignored one of its own rules.

"...being removed from the TDF board"

Not from the board, (implies board of directors), but from TDF membership (board of trustees). This essentially means you have no voting power and no benefits, but you're still free to still contribute by fixing bugs, adding new features, mentoring, code review,... ("community"). This are all the things that would benefit TDF by getting more money from donations (and then use that money for useful things that are mentioned in this TDF blog post).

Well, that's almost how it work but of course without the waiting bits. The change would be added to LOExt namespace and would be written to the document and read on load. Then the change is proposed for inclusion into the next ODF version. Once the ODF version is released, LO would add support for that as well and changed if needed. On next save the feature would use the ODF version instead of LOExt.

The process has its issues and could cause problems, but in practice I don't remember anyone reporting issues.

JXL has Guetzli lossless JPEG compressor integrated into the standard so it produces reversible and completely standard compliant JXL images that are 15-20% smaller size. Reversible in sense that you can still convert the image back the original JPEG, that is bit exact file as the input JPEG was (it takes care of all the metadata also - it has to).

Also if you decide to forgo the reversibility you can get a bit more out of it as JXL is actually a superset of JPEG, so it can read the JPEG stream and convert it to JXL without complete recompression - it will just use more efficient structure of JXL and much more efficient (ANS vs. Huffman) entropy encoding. The additional savings compared to the reversible mode aren't big however.

They ceased development on WebP2.. don't think they could've come up with anything better than AVIF or JXL already have anyway.

"Regarding your claim that Opus is better than HE-AAC, here's a "Quality vs Bitrate" chart from opus-codec.org, the home of Opus: https://opus-codec.org/static/comparison/quality.svg

Note that AAC (presumably they mean "Main Profile" rather than AAC-LC) has effectively the same efficiency as Opus. HE-AAC and HE-AACv2 have a higher efficiency than both Opus and AAC, and works great at lower bitrates in comparison to AAC."

This chart just roughly outlines (according to the feeling of Opus developers at that time) what to expect from Opus - a wide range of useful bitrates. It's not anything that was actually measured or something that can be used for drawing any conclusions from it. I mean - those nice curves and lack of any detail about the codecs used should give it away.

According to public (double blind) listening test that were performed by the Hydrogen audio group Opus does win over best HE-AAC codecs available at time when the test was performed - both at 64kbps and 96kbps bitrates [1] (Multiformat Tests).

[1] https://wiki.hydrogenaud.io/index.php?title=Hydrogenaudio_Li...

xHE-AAC from 2016 (also known as USAC) yes. The older HE-AAC from 2003 and HE-AACv2 are not. Codecs have similar names, but they are different and released at different times.

Well RED is mostly suing for their RAW video compression patents, which are just dumb an should never be allowed to be passed in the first place (and AFAIK Nikon is currently battling to invalidate that). But this is also their own problem - they haven't put almost no R&D into the software side of digital photography and videography like formats, processing. They have a nice camera which outputs 12-bit and higher images - they should be the first ones requesting and defining a new image format for consumption, which can handle that.

Camera manufacturers are old spineless companies. In all those years they have done nothing for digital image formats and it is the most important thing in a camera. They weren't even able to come up or attempt to make a standard RAW format. All that came from Adobe (DNG), which the camera manufacturers happily ignored for their own proprietary solution until this day.

and neither of your examples is experimental

Most RAW formats are based on TIFF... no standard TIFF decoder can decode a RAW format either.

DSLR market has pretty much stopped (rarely any new DSLR camera is released) as everyone shifted to mirrorless cameras. Camera manufacturers mostly added HEIF (Canon, Sony, Fuji) as the non-RAW image format, because they already have HEVC for video.

Camera with a lossy / lossless 12-bit, 14-bit JPEG XL would definitely be interesting for many photographers. Not everyone wants to be forced to do a complete post-processing with RAW. JPEG is to limited (8-bit only) and HEIF isn't much better, while not having much support (especially on the web) because of the patent situation.

In what way does Google control WebP? They have frozen the format and nothing will be added to it. WebP2 was abandoned. Google is also involved with JPEG XL - actually some developers that worked on WebP now work on JPEG XL.

If someone controls something it is the Chromium/AOM/AVIF/AV1 team that controls and decides what multimedia formats go inside Chrome/Chromium thus controlling what is used on the web and ignoring what the web community has to say about it.

No. VP8 and VP9 bitstreams are frozen and stayed frozen when they decided to freeze it (they made that sure with automatic tests in libvpx that calculated the bitstream checksum) otherwise old VP8/VP9 files would stop playing. The difference is only with the approach as with VP8 and VP9 the "reference" decoder is the specification, which is not what many people like for various reasons (for example there were some errors in the implementation, which needed to be implemented by everyone because of that).

The first link you posted about VP8 just writes that they'll create an experimental branch (back in 2010) where incompatible bitstream changes can go in. Guess what eventually happened with those changes? VP9

The second link is the link to the unfinished VP9 specification, however with VP9 they still had that "reference" decoder code is the specification approach. As VP9 started to gain traction, the demand for the specification became greater, so they post-hoc started writing one but as you can see, they never finished it. Still this doesn't mean the bitstream isn't frozen.

Apple probably held off adoption so that HEVC patent license situation improves a bit (at least most companies with patents join in some pool or start to offer licenses).

If AV1 would be released sooner it wouldn't be even as good as HEVC, which would be bad. VP9 is already that free-but-not-as-good-as-HEVC codec. Also they would need to release AV2 in 1 or 2 years (as the better-than-HEVC codec), which is just too soon after AV1 and would put a big question on why AV1 was released at all...