"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.
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.
The lossless thingy is Brunsli. In the last meters of the standardization, Brunsli in JPEG XL was replaced with "Brunsli 2.0", the more natural formalism in JPEG XL format, allowing for a smaller spec and decoder as well as parallel decoding.
Guetzli is a slow high quality jpeg encoder. One can use jpegli for that need nowadays, 1000x faster...
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.
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.
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).
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.
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.
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.
Also good to know that Jpegli (a traditional jpeg codec within libjxl) allows for 16 bit input and output for '8-bit jpegs' and can deliver about ~12 bits of dynamics for the slowest gradients and ~10.5 bits for the usual photographs.
Jpegli improves existing jpeg images by about 8 % by doing decoding more precisely.
Jpegli allows for encoding jpeg images 30 % more efficiently by using JPEG XL adaptive quantization (by borrowing guetzli's variable dead zone trick), and the XYB colorspace from JPEG XL.
Together, you get about 35 % savings by using jpegli from the decoding + encoding improvements. Also, you get traditional JPEG that works with HDR.
Jpegli is predicted to be production ready in April or so, but can be benchmarked already.
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.
reply