• vzq@lemmy.blahaj.zone
    link
    fedilink
    arrow-up
    50
    arrow-down
    1
    ·
    14 days ago

    This decision has probably saved us from a decade long trickle of very embarrassing security vulnerabilities.

    And has also gifted us a decade of less, but also more interesting, security vulnerabilities.

  • lnxtx@feddit.nl
    link
    fedilink
    English
    arrow-up
    15
    arrow-down
    2
    ·
    14 days ago

    Good algorithm, bad name. JPEG Extra Large.
    O.g. JPEG has bad reputation, because of visual artifacts.

  • pivot_root@lemmy.world
    link
    fedilink
    arrow-up
    10
    ·
    14 days ago

    Interestingly, the reference implementation libjxl appears to be a Google project. They’re all over the patents file and CLA.

    If Mozilla isn’t merely being hopeful about having the same team create a Rust implementation, that might actually mean there’s internal interest within Google. Assuming they pull it off, the bullshit reason for refusing to add JPEG XL to Chromium might finally stop being a blocker.

  • 1984@lemmy.today
    link
    fedilink
    arrow-up
    11
    arrow-down
    2
    ·
    14 days ago

    It’s sad to see how Mozilla needs Google even for this.

    I hate that Google seems to have a finger in absolutely everything. Why? Because their end goal is a web where you need to identity yourself to them.

    • dan@upvote.au
      link
      fedilink
      arrow-up
      15
      ·
      edit-2
      14 days ago

      It’s likely that Google offered, and Mozilla doesn’t have a reason to say no. Google Research do this for a bunch of open source projects.

      Chrome needs a JPEG-XL decoder too, so I’d guess they’re going to share the code across both Chrome and Firefox.