[HN Gopher] JPEG XL
___________________________________________________________________
JPEG XL
Author : tosh
Score : 341 points
Date : 2021-06-21 08:29 UTC (14 hours ago)
(HTM) web link (jpegxl.info)
(TXT) w3m dump (jpegxl.info)
| JyrkiAlakuijala wrote:
| Check it out with your own eyes with the most recent comparison
| site for WebP, AVIF and JPEG XL:
|
| https://storage.googleapis.com/demos.webmproject.org/webp/cm...
|
| Most comparison links posted here are to older (almost a year
| old) versions that don't reflect the current state of encoding.
| Both JPEG XL and AVIF have improved tremendously.
| algorithm314 wrote:
| For some images like
| https://storage.googleapis.com/demos.webmproject.org/webp/cm...
| jpeg xl is really behind.
| 0-_-0 wrote:
| It seems to try really hard to preserve high frequencies,
| where WebP just gives up. Hopefully it's just a question of
| tuning the quantisation tables for low bitrate.
| JyrkiAlakuijala wrote:
| They originally chose to use x265 to calibrate the bitrates,
| possibly something went wrong there and the 'Tiny', 'Big',
| etc. are somewhat meaningless.
|
| At 'Large' and 'Big' settings of this image -- which are
| still in much less than 1 bpp bitrates, i.e., below internet
| image quality -- you can still observe significant
| differences in the clouds even if balloons are relatively
| well rendered.
| jonsneyers wrote:
| Nothing went wrong there, it's just what you get if you
| configure an encoder using just some quantization setting
| and not a visual target. The same will happen if you would
| encode images with libjpeg quality 50 (and then derive all
| other bitrates from there). In some cases the image will
| look OK-ish at that setting, in other cases it will be
| complete garbage.
|
| JPEG XL is the first codec to have a practical encoder that
| can be configured by saying "I want the worst visual
| difference to be X units of just-noticeable-difference".
| All other encoders are basically configured by saying "I
| want to use this scaling factor for the quantization
| tables, and let's hope that the result will look OK".
| astrange wrote:
| > All other encoders are basically configured by saying
| "I want to use this scaling factor for the quantization
| tables, and let's hope that the result will look OK".
|
| crf in x264/x265 is smarter than that, but it's still a
| closed-form solution. That's probably easier to work with
| than optimizing for constant SSIM or whatever, it always
| takes one pass and those objective metrics are not
| actually very good.
| ksec wrote:
| JPEG XL isn't yet optimised for extremely low bpp. I thought
| the label for tiny, large and medium etc are sort of
| misleading without looking at bpp number.
|
| It is a bit like looking at bitrate for Video quality without
| looking at video resolution.
| JyrkiAlakuijala wrote:
| The quality is normalized to x265 q24 setting. I believe
| this process/setting is either not working for images or
| something else went wrong there, because the observable
| quality as well as the bitrates vary from image to image.
|
| Bitrates vary from 0.26 bpp (Nestor/AVIF) to 4+ bpp
| (205/AVIF) at the finest setting. Nestor at lowest setting
| is just 0.05 bpp, somewhat unusual for an internet image. A
| full HD image at 0.05 bpp transfers over average mobile
| speed in 5 ms and is 12 kB in size. I rather wait for a
| full 100 ms and get a proper 1 bpp image.
| gardaani wrote:
| When is JPEG XL ready for use? Wikipedia [1] says that Part
| 4 will be released in 2022?
|
| [1] https://en.wikipedia.org/wiki/JPEG_XL#Standardization_s
| tatus
| jonsneyers wrote:
| Part 1 and 2 define the codestream and file format,
| respectively. They are both finalized at the technical
| level (the ISO process is still ongoing, but there is no
| more opportunity for technical changes, the JPEG
| committee has approved the final draft). So it is ready
| for use now: the bitstream has been frozen since January,
| free and open source reference software is available.
|
| Part 3 will describe conformance testing (how to verify
| that an alternative decoder implementation is in fact
| correct), and part 4 will just be just a snapshot of the
| reference software that gets archived by ISO, but for all
| practical purposes you should just get the most recent
| git version. Parts 3 and 4 are not at all needed to start
| using JPEG XL.
| jonsneyers wrote:
| The labels are indeed not very useful. It would have been
| better to use bitrates based on the jxl encoder, which has
| a perceptual-target based setting (--distance), as opposed
| to setting it based on absolute HEVC quantization settings
| (as was done here), which for some images causes 'Big' to
| be great and for others makes 'Big' still kind of low
| quality.
| twotwotwo wrote:
| Some notable features of JPEG XL that don't show up in side-by-
| sides:
|
| 1) Progressive decoding. Like the original .jpg, .jxl can give
| you a low-quality image when a fraction of the file is loaded,
| then a decent-quality image, then the final image. This can
| give JPEG XL the edge in perceived load speed even when the
| full .avif is smaller than the full .jxl. (Old demo from a JXL
| contributor at https://www.youtube.com/watch?v=UphN1_7nP8U )
|
| 2) Fast conversion: JPEG XL encoding/decoding is fast without
| dedicated hardware. Facebook found encode/decode speed and
| progressive decoding to be points in favor of JPEG XL for their
| use: https://bugzilla.mozilla.org/show_bug.cgi?id=1539075#c18
|
| 3) .jpg repacking: JPEG XL can pack a JPEG1 about 20% smaller
| without any additional loss; the original .jpg file can be
| recovered bit-for-bit.
|
| 4) Lossless mode. JXL's lossless mode is the successor to
| FLIF/FUIF, is really good, and also has progressive decoding.
| AVIF has a lossless mode too, but JPEG XL seems ahead here.
|
| (I know the parent comment is from a JXL contributor, I'm
| saying this for other folks.)
|
| I think those will give JPEG XL a niche on the Web. Meanwhile I
| suspect e.g. Android phone cameras will save .avif someday,
| like iPhones save .heic now. Phones want the encode hardware
| anyway for video, and you can crunch a zillion megapixels down
| to a smaller file with AVIF before attention-grabbing artifacts
| crop up--at low bitrates AVIF seems good at preserving sharp
| lines and mostly blurring low-contrast details (compare Tiny
| images).
|
| Finally, worth noting the codecs are different due to a bunch
| of rational choices by their devs. AVIF is the format for AV1
| video keyframes. Progressive decoding doesn't help there, and
| doesn't jibe well with spatial prediction, which helps AV1 and
| other video codecs preserve sharp lines. And video codecs need
| hardware support to thrive anyway, so optimizing for fast
| software encoding probably wasn't an early priority. Otherwise
| the new formats have a lot of overlap in fundamentals--variable
| size and shape DCTs, better entropy encoding, chroma-from-luma,
| anti-ringing postfilters, etc.
|
| Glad to see support for both getting more widespread.
| unlord wrote:
| Note that AVIF is not just AV1 video keyframes. The entire
| compliment of AV1 video coding tools (including inter
| prediction with motion vectors) are available. This includes
| spatial and temporal scaling.
|
| Note this means that animated images on the web (like GIF)
| are significantly smaller with AVIF than JPEG-XL which has no
| inter prediction.
| twotwotwo wrote:
| Good point. AV1 and AVIF could improve on how some sites
| (like Twitter) turn actual GIFs into video now.
|
| Also a plus for saving phone snaps, since the camera often
| saves a short video these days anyway.
| jonsneyers wrote:
| Yes, for animation a video codec like AV1 is much more
| suitable than a still image codec like JPEG XL.
|
| JPEG XL does have some weak forms of inter prediction
| though (but they were designed mostly for still image
| purposes). One of them is patches: you can take any
| rectangle from a previously 'saved' frame (there are four
| 'slots' for that) and blit it at some arbitrary position in
| the current frame, using some blend mode of choice (just
| replace, add, alpha blend over, multiply, alpha blend
| under, etc). This is obviously not as powerful as full
| motion vectors etc, but it does bring some possibilities
| for something like a simple moving sprite animation. This
| coding tool is currently only used in the encoder for still
| images, namely to extract repeating text-like elements in
| an image (individual letters, icons etc) and store them in
| a separate invisible frame, encoded with non-DCT methods
| (which are more effective for that kind of thing) and then
| patch-add them to the VarDCT image. The current jxl encoder
| is not even trying to be good at animation because this is
| not quite its purpose (it can do it, but 'reluctantly').
|
| Anyway, I think that animation is in any case best done
| with video codecs (this is what video codecs are made for),
| and I wish browsers would just start accepting in an <img>
| tag all the video codecs they accept in a <video> tag (just
| played looping, muted, autoplay), so we can for once and
| for all get rid of GIF.
| twotwotwo wrote:
| ++ to making it easier to use other codecs in place of
| .gif!
| lajamerr wrote:
| Why does JPEG XL affect the image quality even in lossless
| mode?
|
| I just compared the original tiger image to the lossless
| version for JPEG XL but there's some small changes that it
| makes.
| Aardwolf wrote:
| I think this is a quirk in the tool, even if you choose
| Original on both sides there is some difference that looks
| like a scaling that's off by a few pixels
| [deleted]
| hnbad wrote:
| The differences IMO are even more impressive at higher
| compression. WebP on "tiny" loses a lot of detail whereas JPEG
| XL retains most details while still losing overall image
| quality.
| Paul_S wrote:
| Is it just me or do all the comparisons linked from the page show
| that webp actually looks better?
|
| Still, the JPEG recompression feature might be what helps
| adoption.
| exclipy wrote:
| By golly, you're right.
|
| eg. https://eclipseo.github.io/image-comparison-web/#us-
| open&WEB... The player is missing the corner of her mouth in
| the JXL version.
|
| JXL Medium (32KB) is about the same quality as WebP Small
| (19KB)
| torgard wrote:
| I'd say JXL Medium is slightly better than WebP Small -
| compare e.g. the racket, face, and left hand.
|
| But it's also slightly worse than WepB Medium, e.g. with the
| corner of her mouth.
| LispWizard wrote:
| JXL's design operating point is "no visible compression
| artefacts".
|
| Most people do not want to have visible compression
| artefacts on the images they put on their web pages. JXL
| starts from this premise and tries to answer the question:
| "How small can we then make the image?"
|
| Care must be taken when trying to compare the performance
| of image codecs by increasing compression density until
| there are very visible compression artefacts and then
| evaluating whether A's or B's artefacts look worse: If both
| A's and B's artefacts are so bad that one would not want to
| put such an image on one's website, such an experiment
| gives no insight on what one would pick for images that one
| would actually put on one's website.
|
| Figuratively speaking, if I buy a shirt, my main criterion
| is that it looks good in good condition, and not that it
| still looks good if I put a coffee stain on it.
|
| So, before comparing codec quality at compression levels
| where artefacts show, always ask yourself: At that level of
| visual quality, would I actually want to put either of the
| two options on my website? Now, it is of course tempting to
| compare "away from the actual operating point", because it
| is just so much easier to do comparisons if there are very
| visible differences. Comparing near-identical images for
| quality is hard. Doing this over and over again in a human
| rater experiment is exhausting. But that's then answering
| the actual performance questions that need to be answered.
| torgard wrote:
| Great point!
| jonsneyers wrote:
| ^^^ This.
|
| Comparing artifacts at 0.2 bpp is tempting because the
| artifacts are big there. But it's like buying a car based
| on how it performs when you are using only the first
| gear.
| maeln wrote:
| Although the Moscow demo[0] look better (in my eyes) in jxl
| than wepb.
|
| Note also that JXL is still being worked on. We have no
| information also about which encoder was used (I am assuming
| the reference encoder, since it is the only one that I know
| off right now) and which version.
|
| Edit: the Citroen demo is also a clear win for JXL.
|
| [0] https://eclipseo.github.io/image-comparison-
| web/#moscow&WEBP...
| espadrine wrote:
| One case where JXL is very noticeably more accurate is
| here: https://storage.googleapis.com/demos.webmproject.org/
| webp/cm...
|
| The singer's left hand has wrinkles in the original image
| that disappear in WebP2.
|
| Overall, WebP2 and especially AVIF are really good at very
| low bitrates (<1 bit per pixel), but unlike video, images
| on the Web will always be shown at the smallest bitrate
| necessary to be indistinguishable from the original; there,
| JXL tends to show all the details at a lower bitrate.
| JyrkiAlakuijala wrote:
| You can get a more up-to-date comparison from the WebP team's
| comparison page:
| https://storage.googleapis.com/demos.webmproject.org/webp/cm...
|
| Internet uses jpeg qualities that average around 2-3 bpp today,
| and an improvement in compression density through a new format
| that compresses 50 % better would push it down to 1-1.5 bpp.
| The comparison tool displays the bitrates when you hover on the
| images.
| pavon wrote:
| Yeah, I agree that webp looks better for many of the images.
| For most of them it comes back to the subjective issue that
| webp (and VP9) choose to err on the side of blurring detail
| they can't encode, while jpeg XL (and x264, etc) try to keep
| all the detail they can at the expense of more artifacts. There
| are very vocal proponents of both approaches, and personally I
| think it varies by the image content.
|
| For all these examples, I was comparing at Small (as with Tiny
| they were both bad enough but in different ways that I often
| couldn't decide which was least bad). For the Abandoned Factory
| and Panthera Tigres, I think the extra detail of JXL looks
| better than the blurring of WEBP. On the otherhand, I think
| WEBP looks cleaner than JXL for Buenos Aires, Reykjavik, B-24
| Bombers without loosing significant detail. And Avenches is a
| mix as JXL looks much better than WEBP for the trees and tile
| roof, but has worse chroma artifacts near the edges of the hat
| and clothing.
|
| But that isn't the whole story, as for some of the images WEBP
| seems to both preserve more detail, and have fewer artifacts,
| such as Air Force Academy Chapel, Pont de Quebec, Steinway and
| White Dunes. What all these cases seem to have in common is a
| smooth gradient adjacent to sharp detail. WEBP seems to do a
| much better job of dealing with that boundary by blurring the
| smooth part, put preserving the sharp lines.
|
| And if you bump up to WEBP2, the number of cases where it both
| preserves more detail and has fewer artifacts than JXL
| increases significantly.
| astrange wrote:
| > Yeah, I agree that webp looks better for many of the
| images. For most of them it comes back to the subjective
| issue that webp (and VP9) choose to err on the side of
| blurring detail they can't encode, while jpeg XL (and x264,
| etc) try to keep all the detail they can at the expense of
| more artifacts. There are very vocal proponents of both
| approaches, and personally I think it varies by the image
| content.
|
| In VP9/WebP this wasn't a "choice" so much as they were
| optimizing for good looking marketing graphs instead of
| pictures. You get blurry images if you target a metric like
| PSNR instead of actually looking at your output. x264 does
| have a few different tunings, the film one will try to turn
| detail to noise and the animation one won't.
| dsego wrote:
| What is the Weissman score?
| yummybear wrote:
| This is going to sound childish, but PIK (Google Pik) is
| literally "dick" in my language. I can't help to chuckle at the
| notion of using PIK-images - literally dickpics.
| jonsneyers wrote:
| I'm a native Dutch (of the Belgian variety) speaker and my
| proposal was called FUIF (which means "party" in Dutch, but
| it's also a backronym for Free Universal Image Format).
|
| I am very happy the result of combining PIK and FUIF was not
| called PIKFUIF (or FUIFPIK). Some say JPEG XL is a bad name,
| but it could have been so much worse...
| dang wrote:
| Related ongoing thread, complete with newly-added title
| qualification:
|
| _JPEG XL would be Turing-complete without the 1024x1024 pixel
| limitation_ - https://news.ycombinator.com/item?id=27559748 -
| June 2021 (34 comments)
| childintime wrote:
| An important niche to consider might be face recognition. For
| example the "US Open" image on medium JXL is significantly
| distorted in the face. As the face area is critical to the
| overall image quality perception, that area would benefit from
| reduced compression.
|
| edit: This is also the case in other images with faces (and
| especially the eyes).
| tibbetts wrote:
| My biggest image format question, which I haven't seen a clear
| answer to, is as an iPhone camera user should I be keeping the
| JPEG or the HEIC as my archival format? I theorized the HEIC had
| more information, but I don't really know. Unfortunately keeping
| both is a usability nightmare in all the tools I've seen. Anyone
| have an informed opinion or good link?
| jonsneyers wrote:
| HEIC is in general better than JPEG (as a codec; not in terms
| of interoperability), but the way Apple does HEIC, I strongly
| suspect that JPEG is actually a better choice. Your files will
| of course be larger, but the HEIC will be a bit overcompressed
| compared to the JPEG: it will have some blurring/smearing
| artifacts that the JPEG will not have.
|
| The reason is that they do fast hardware HEIC encoding at
| relatively aggressive quality settings in order to get the file
| size savings they want to boast about. They claim the quality
| to be the same, but that's not actually true. It is a lower
| quality.
|
| One advantage of HEIC though is that it can also contain the
| depth map (in 'Portrait mode'), which I assume gets lost when
| you use JPEG. This is the information that gives a rough
| separation of foreground and background, so you can later do
| effects like applying bokeh to the background only.
| kalleboo wrote:
| The Apple portrait depth map is also stored in a JPEG. I
| believe they use MPO. The Google camera can do it too.
| Apparently it uses XMP metadata for this purpose.
| mceachen wrote:
| The depth map is actually stored as an image: PhotoStructure
| accidentally used them as preview images several versions
| back (when depth maps were fairly novel) and I had some
| interesting discussions with users complaining about "ghosts"
| in their library:
|
| https://forum.photostructure.com/t/i-see-ghosts/41
| zaarn wrote:
| If you want to preserve fidelity indefinitely, PNG or RAW might
| be a better bet. Lossless formats usually are better for
| archival, you can always get a lossy compression out of it
| later and don't have to worry about generational losses.
| pjc50 wrote:
| .. but this is an iPhone, so the options for "original" are
| HEIC, JPEG, and "proraw" https://support.apple.com/en-
| gb/HT211965
| zaarn wrote:
| I don't have an iPhone, hence a minor speculation on what
| it supports, if you forgive that.
|
| If you're looking into archival, you'll probably want the
| PRORAW then, sounds like that is the lossless format.
|
| Converting from JPEG/HEIV to lossless is a bit of a
| pointless thing to do, you already incur generational loss
| from that.
| lazide wrote:
| For archival, you need to worry about long term ability
| to read the format easily. JPEG wins that fight out of
| the three easily.
| zaarn wrote:
| RAW is a very old format that has been around for some
| time, Apple's ProRAW is backwards compatible and has some
| additional metadata attached (IIRC ProRaw attaches the
| image pipeline the iphone would have used, so that image
| software can recover this and produce the same image the
| iphone would have after the image pipeline). RAW is older
| (1988) than JPEG (1992), largely because RAW is largely
| based on TIFF (and any vendor specific variation is
| usually TIFF-like too) in it's mid-1980s state. The
| latest standard RAW standard (TIFF/EP) is from 2001.
|
| So in terms of long term ability to read... RAW wins,
| various versions aren't as old but JPEG got it's fair few
| of extensions too.
|
| For long term readability, I don't think JPEG would win
| on another standpoint; bitrot. It'll happen eventually,
| even if you use ZFS, you will eventually loose some bits.
| Maybe a sector of data. JPEG doesn't like loosing parts
| of the file.
|
| On the other hand, a TIFF file can be recovered from
| bitrot, if you don't mind loosing a part of the image.
| Because there is no compression, loosing a sector of data
| amounts to loosing the bits on that sector. The only
| sensitive part of the file would be the header, which
| isn't terribly complex and can be typed on notepad if
| needed be.
| thehappypm wrote:
| If you convert the full-resolution JPEG/HEIC to PNG you
| won't lose any information, right?
| jonsneyers wrote:
| Technically, you do lose _some_ information. PNG cannot
| represent DCT coefficients nor YCbCr data, and the
| conversion of those things to (8-bit) RGB is a (slightly)
| lossy operation.
| sp332 wrote:
| Sure, but what's the advantage to blowing up the file
| size to losslessly preserve all the lossy artifacts from
| JPEG or HEIC?
| MontagFTB wrote:
| ProRAW is lossless, if you're willing to pay the size price
| (~40MB/image.)
| mceachen wrote:
| Apple used to have a spectacular record with stable formats:
| see HFS+.
|
| Unfortunately, over the last several years, that's gone out the
| window.
|
| Mojave can't read some Big Sur volumes, even though both are
| using "Apple File System".
|
| HEIC image formats coming out of iPhones have changed /several/
| times in the past couple years: witness the scrambling by the
| libheif project as they find out they can't read images from
| the latest iDevice.
|
| Apple's in-device conversion to JPEG is lossy, but I don't
| expect you will notice. Most of the metadata it's retained (at
| least with the current iOS), and I couldn't see egregious
| artifacting.
|
| I'd personally keep the original and hope tooling keeps up with
| Apple shenanigans, but disk is cheap, and if you're worried at
| all, use `sips` (if you're on a Mac), the built-in
| "compatibility mode" conversion, or `heif-convert` to transcode
| to JPEG.
|
| (Source: building support for HEIC in PhotoStructure)
| jbverschoor wrote:
| The site doesn't state this, but https://jpeg.org/jpegxl/ says:
|
| JPEG XL further includes features such as:
|
| - animation
|
| - alpha channels
|
| - layers
|
| - thumbnails
|
| - lossless and progressive coding
|
| I wonder if progressive loading can halt loading (network I/O) at
| certain resolutions. This would remove the need of img-sets.
|
| Edit:
|
| Interesting talk at https://www.youtube.com/watch?v=t63DBrQCUWc
| and https://www.youtube.com/watch?v=RYJf7kelYQQ
|
| Esp. the "visual target" instead of "technical target" when
| deciding the encoding quality. Also, the lossless and reversible
| transcoding from JPEG, GIF and PNG.
| phkahler wrote:
| What about meta-data?
| jonsneyers wrote:
| The usual XMP and Exif metadata are supported in the file
| format, as well as JUMBF extensible metadata. It can
| optionally be Brotli-compressed too.
| ksec wrote:
| >I wonder if progressive loading can halt loading (network I/O)
| at certain resolutions. This would remove the need of img-sets.
|
| Yes, not resolution but predetermined quality levels.
| ZeroGravitas wrote:
| I believe it can also resume from where it left off, if you
| click a thumbnail to get a closer look.
| fho wrote:
| I guess you trade responsiveness for 'on-demand' data
| transfers. I would guess that the moment you click the
| button is too late to resume the loading.
|
| Otoh the low-res thumbnail might be just enough to show as
| a (big) placeholder to bridge the (short) loading time to
| bring the image to a resolution that the user won't notice
| a difference.
|
| (brain off ... can't write coherently ...)
| Retr0id wrote:
| I was playing with progressive PNGs, and with an
| "intelligent" web server, it's possible to halt image
| transmission (either temporarily or permanently) at a server-
| decided quality level.
|
| Here is a demo, which uses the different resolutions to
| create a pseudo-animation:
|
| https://www.da.vidbuchanan.co.uk/adamation/image.png
|
| It would be theoretically possible to write a server with a
| "give me the next quality level now" API endpoint, to enable
| the client to signal that it's ready for the next resolution.
|
| This is far too janky to be used in production, but at least
| its fun.
| rdsubhas wrote:
| Interesting, but doing it server side can screw up CDNs
| (which are quite important for images). It's better if the
| client takes care of that, so CDNs can cache the full
| image.
| ec109685 wrote:
| There has to be some incoming header / query param to
| indicate the resolution the browser is asking for in
| order know when to stop delivering bytes, so that can be
| used to vary the CDNs cache key.
| lcnmrn wrote:
| The only missing part is support in all browsers and operating
| systems.
| jerryX wrote:
| Already in Chrome, Firefox, Edge:
| https://www.ghacks.net/2021/05/11/find-out-if-your-browser-s...
| phartenfeller wrote:
| Yes but behind a Flag. With default settings, it hasn't
| landed in any browser yet: https://caniuse.com/jpegxl
|
| I hope that Safari does not take as long to implement it as
| with WEBP...
| ByTheBook wrote:
| I doubt it will be enabled by default until it reaches
| version 1.0, it is currently at 0.3 IIRC
| hulitu wrote:
| This is only 1 browser with 3 distributors.
| andrius4669 wrote:
| firefox is chrome distribution? that's new to me
| tgv wrote:
| Firefox is a very different browser. Edge shares its base
| with Chrome, and that's derived from WebKit.
| vanderZwan wrote:
| This may be my memory playing tricks on me (after all, time
| perception changes as you get older), but if I think back to
| the speed of adoption of just about any image format that came
| after JPEG and GIF, then JPEG XL seems to be moving really fast
| by comparison.
|
| EDIT: granted, computers being stuck on old versions of
| Internet Explorer back in the day and therefore holding back
| (for example) PNG adoption is a very different situation than
| that of the modern web, which makes it a bit of an unfair
| comparison.
| em-bee wrote:
| i don't think your memory is playing tricks. from all these
| new formats, only PNG has really caught on yet. i don't think
| jpegxl will be adopted any faster.
| tosh wrote:
| discussed at https://news.ycombinator.com/item?id=27559748
| [deleted]
| ChrisMarshallNY wrote:
| I really want this to work.
|
| As has been pointed out in the comments, it needs to be adopted
| beyond the browser. And _easily_.
|
| Anyone hear of FlashPix[0]?
|
| Anyone?
|
| Bueller?
|
| It was a staged-resolution format that was introduced by a
| consortium in the 1990s.
|
| The biggest problem (of many) was that, in order to read or write
| the format, you needed to use the Microsoft Structured Storage[1]
| library, which was a huge pig (at that time. I assume it's
| better, these days).
|
| The format was basically strangled in the crib. It was actually a
| fairly interesting idea, at the time, but files could be _huge_.
|
| [0] https://en.wikipedia.org/wiki/FlashPix
|
| [1] https://en.wikipedia.org/wiki/COM_Structured_Storage
| kalleboo wrote:
| > _The biggest problem (of many) was that, in order to read or
| write the format, you needed to use the Microsoft Structured
| Storage[1] library, which was a huge pig (at that time. I
| assume it 's better, these days)._
|
| HEIC and AVIF are based on the QuickTime file format, which
| doesn't seem very svelte either. I can't find any reference on
| the JPEG XL container format so it's probably it's own thing.
| ChrisMarshallNY wrote:
| Good chance it's TIFF, like JFIF.
| jonsneyers wrote:
| No thanks, the only TIFF you'll find in a JXL is the
| (optional) Exif metadata.
| jonsneyers wrote:
| HEIC and AVIF are both based on HEIF, which is based on
| ISOBMFF (just like for example MP4).
|
| The JPEG XL container (which is optional and only needed if
| you want to attach metadata to an image) is also based (more
| directly and with less header overhead) on ISOBMFF.
| astrange wrote:
| The ISO media file format is, like GP said, basically
| QuickTime.
|
| This can be a problem if you're the kind of completionist
| who needs to implement everything they see and make one C++
| class per QuickTime atom - a problem I saw with a lot of
| mp4 codebases.
|
| But there's no need to do this because almost all the
| things in the spec don't matter. Just don't read any of
| them and handle the rest procedurally and it'll be fine. It
| looks like JPEG XL also has too many features (like this
| animation and patching thing) so maybe just ignore that
| too.
| keanebean86 wrote:
| I was really excited about JPEG 2000 when I first heard about
| it in the mid 2000s. As is tradition it was pretty much killed
| by the possibility of patents that weren't part of the industry
| agreement.
| astrange wrote:
| JPEG2000 just wasn't a great format either. Wavelets don't
| compress well because they get blurry, which isn't pleasant
| to look at, and it's slow to decode, so sticking with JPEG
| was a good idea. Similar issues with WebP, it wasn't good
| enough to move to.
| Hypx_ wrote:
| That might've been true at the time. But what about today?
| Can't we use the higher settings for JPEG 2000? At least
| speed shouldn't be an issue now.
| ksec wrote:
| Comment from Facebook Infra [1],
|
| > _Erik Andre from the Images Infra team at Facebook here. I 'd
| like to share a bit of our view on JPEG XL in the context of new
| image formats (e.g AVIF, JPEG XL, WEBP2, ...) and how browser
| adoption will let us move forward with our plans to test and
| hopefully roll out JPEG XL._
|
| > _After spending the last 5 months investigating and evaluating
| JPEG XL from both a performance and quality point of view, it 's
| our opinion that JPEG XL has the most potential of the new
| generation of image formats that are trying to succeed JPEG._
|
| > _This opinion is based on the following findings:_
|
| > _JPEG XL encoding at speed /effort 6 is as fast as JPEG
| encoding (using MozJpeg with Trellis encoding enabled). This
| means that it's practical to encode JPEG XL images on the fly and
| serve to client. This can be compared with the encoding speed of
| AVIF which necessitates offline encoding which offers much less
| flexibility when it comes to delivering dynamically sized and
| compressed content. Depending on the settings used, JPEG XL can
| also be very fast to decode. Our mobile benchmarks show that we
| can reach parity with JPEG when using multiple threads to decode.
| This matches and in many cases surpasses the decoding performance
| of other new image formats. The JPEG XL image format supports
| progressive decoding, offering similar gains in perceived image
| load performance we are already benefitting from with JPEG. This
| is a feature lacking in the other new image formats which are all
| derived from Video codecs where such features makes little sense
| to support._
|
| > _Having browser support from all the major browsers is going to
| make our lives a lot easier in upcoming WWW experiments and
| ensure that we can deliver a consistent experience across
| platforms and browsers._
|
| Blink Tracking Bug [2] currently behind a flag ,Firefox on both
| [1] and [3], currently in about:preferences#experimental on
| Firefox Nightly. If I remember correctly it is supported on Edge
| behind a parameter as well. I thought it was all very quiet after
| the standard was published, turns out both Chrome and Firefox
| intent to support it.
|
| AFAIK, neither Webkit nor Safari has any plan or intention to
| support JPEGXL. I think ( someone correct me if I am wrong )
| Safari uses macOS image decoding library. So supporting JPEGXL
| may come from an OS update and not browser?
|
| Finally, an open standard, Royalty Free, open-source reference
| implementation, and it is nearly better than all other
| alternative. As an image format on the web it is quite possibly
| close to _perfect_ [4]. It is exciting and I hope JPEG XL will
| succeed.
|
| [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1539075
|
| [2]
| https://bugs.chromium.org/p/chromium/issues/detail?id=117805...
|
| [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1707590
|
| [4] I remember the conversion from a little more than 6 months
| ago current encoder is not optimised for image quality below bpp
| 1.0, those are going to be the focus once all the initial
| reference encoder and decoder standards and issues are done. So
| in case anyone wondering it doesn't look as good as other
| competitors ( but still a lot better than JPEG ), those
| improvements are coming later.
| jonsneyers wrote:
| That's correct, Safari does its image decoding via OS-level
| image decoding
| (https://developer.apple.com/documentation/coreimage).
|
| The only power Safari devs basically have is to decide which
| OS-supported formats to enable/allow and which ones to disable
| (e.g. JPEG 2000 is enabled but HEIC isn't).
|
| So getting JPEG XL supported in Safari will most likely first
| require it to be supported in MacOS and iOS. If you have an
| Apple device and would like it to get JPEG XL support, then
| feel free to open a Feedback Assistant ticket (there's an OS-
| level application to do that) to make a feature request. (I did
| that 5 weeks ago but haven't heard back yet)
| mayoff wrote:
| You probably meant the Image I/O framework, not the CoreImage
| framework.
|
| https://developer.apple.com/documentation/imageio/
| Eric_WVGG wrote:
| Huh. So that explains why WEBP worked in Safari 14 for Big
| Sur but not Catalina or Mojave.
| layoutIfNeeded wrote:
| Not gonna fly, unless it's supported by PDF.
| lucasmullens wrote:
| JPEG XL is available (in beta/with a flag) in Chrome, Edge, and
| Firefox. Seems likely once it's no longer in beta that some web
| developers will start conditionally using it depending on the
| user's browser.
|
| It doesn't need to be useful everywhere to be useful.
| ZeroGravitas wrote:
| A few cynical comments so far about this being one more standard
| to replace all the other standards a la the XKCD joke, but this
| is an effort that I have some faith in to actually deliver on
| that promise.
|
| Lots of technical, practical and and political reasons why this
| could quickly replace a whole bunch of legacy formats in various
| roles that have been hanging around for a while for one obscure
| reason or another.
|
| A faster, better-looking, and simpler web, yes please! Please
| support this so that it actually happens this time.
| est31 wrote:
| > this being one more standard to replace all the other
| standards a la the XKCD joke
|
| Even if JPEG XL does not replace all other image formats, note
| that as the computing industry is growing, so is the number of
| use cases for image formats. There is no law that there has to
| be one format to rule them all, how inconvenient that may be.
|
| E.g. some users might want to edit and encode extremely high
| resolution images on their embedded smartphones with weak
| processing power. They might not care if their images are 5%
| larger, they don't want their friends to wait for the encode to
| finish so that they can make another picture.
|
| Other users might only encode an image once and then distribute
| it to millions of users. 5% improvement in bandwidth cost might
| be quite significant here. On the other hand, they have lots of
| and computational resources to throw at making the optimal
| image.
|
| Can both use cases be served by the same format? Maybe. Maybe
| JPEG XL is that format. But these use cases came up as
| computers became embedded so you could carry them around, and
| as websites sprung up with billions of visitors. This is a
| development of the last 20 years.
|
| Often the response to such developments is an increase in
| complexity: more formats, more tools, etc.
| jandrese wrote:
| Oh nice, it seems they learned from the JPEG2000 fiasco and
| released this with an open source license.
|
| https://gitlab.com/wg1/jpeg-xl/-/blob/master/LICENSE
| dreamlayers wrote:
| Lossless JPEG transcoding making images 20% smaller is nice,
| though you can already losslessly shrink many JPEG files by up to
| 10% by using https://github.com/tjko/jpegoptim/ and making them
| interlaced.
| hoseja wrote:
| Somewhat unfortunate naming for a format that presumably tries to
| be as small as possible.
| lovasoa wrote:
| JPEG-XL can encode huge images, whereas JPEG is limited to a
| maximum width and height of 65535 pixels.
| hoseja wrote:
| Is support for 5 gigapixel images really such a killer
| feature to put it in the name?
| jonsneyers wrote:
| That's not where the name comes from :)
|
| https://en.wikipedia.org/wiki/JPEG_XL#Name
| hnbad wrote:
| I first thought the name must be a clever pun when I saw that
| the original JPEG was dated 1992. But sadly my brain was off by
| a decade, JPEG XL is in fact not JPEG 40.
|
| They could have gone with JPEG XXL or JPEG XXX but the former
| is a bit too fanciful and the latter might cause some adoption
| problems outside a certain niche industry.
| jonsneyers wrote:
| JPEG MMXXI ?
| IshKebab wrote:
| It's also very similar to JPEG-XR.
| jonsneyers wrote:
| And JPEG XT. And JPEG XS.
|
| I prefer calling it JXL (or jxl) which is visually
| sufficiently unique to avoid confusion.
| fleddr wrote:
| A game changer delivered by JPEG XL that is often overlooked:
|
| https://www.youtube.com/watch?v=lqi5U6dxeZU&t=223s
|
| To summarize, JPEG XL has the potential to use a single file to
| deliver many formats. This would deprecate the current practice
| of web developers storing many versions of the same image to
| optimize for different device types/sizes.
|
| The advantages are shockingly large:
|
| - It simply is much easier (time saved)
|
| - Huge storage/cost savings for media-heavy sites/apps
|
| - Significant world wide environmental benefit
|
| - Less need for huge platforms (Facebook, Twitter) to
| aggressively compress photos
|
| - No need to constantly add new sizes, future-proof
|
| A dream feature, if you ask me. Do note that this feature
| requires both browser and web server support, so don't hold your
| breath. But one can dream.
| lnyan wrote:
| Chrome status: In developer trial (Behind a flag)
|
| FireFox status: Only in Nightly and behind a flag
|
| https://caniuse.com/?search=jpeg-xl
| sp332 wrote:
| The Firefox flag is "image.jxl.enabled" and the Chrome flag is
| "enable-jxl", in case anyone else was searching for jpegxl or
| something instead.
| mmis1000 wrote:
| You don't really need to alter the flags directly if you are
| on Firefox nightly. Firefox nightly already has a dedicated
| page for recent experiments in setting page. JPEG XL is
| already on it for a few months.
| sp332 wrote:
| That's cool. I've been running Nightly for a while but I
| haven't been keeping up on new things in that tab.
| jug wrote:
| Aldo, note that while Edge has initial support as well, it's
| behind a command-like attribute rather than a flag. Not sure
| why they didn't just do it like Chromium but I have a suspicion
| they might want to remove it later and replace it with a JPEG
| XL image extension like they've done recently for AVIF etc. The
| reason is that this then benefits the entire system.
|
| But regardless. All main browsers but Safari will get it. The
| jury's still out on Safari/WebKit.
| nuclearsugar wrote:
| Very curious to see if this codec gets implemented into After
| Effects. I've been rendering out of Maya to a PNG sequence for
| many years since it's lossless and includes an alpha channel. But
| the decompression times leave me wishing for TIFF, TARGA, EXR, or
| such... But the cumulative file size difference is dramatic. And
| that matters when I'm rendering for example 10 tests, each with 2
| layers, and also each have 10,000 frames.
| KMnO4 wrote:
| Does After Effects support APNG? Most browsers do.
|
| https://en.wikipedia.org/wiki/APNG
| CyberDildonics wrote:
| This is not at all what it is for. Being an intermediary isn't
| even what png is for. Exr is made for it and can zip compress
| individual lines while having 16 or 32 bit floats per channel.
| jonsneyers wrote:
| JPEG XL can do lossless compression of 16-bit or 32-bit (or
| even 24-bit and other custom float types) float data, just
| like EXR. It can do pretty fast encode/decode (for mezzanine
| use cases) and also (if you have time for encoding) it can do
| the densest lossless compression.
| CyberDildonics wrote:
| The point here is that EXR has taken care of being an
| intermediate format for 20 years but this person is using
| pngs and is hoping jpegxl fills the same slot of a solved
| problem.
|
| > It can do pretty fast encode/decode (for mezzanine use
| cases)
|
| I'm not sure what this means, but zipping individual lines
| takes care of the interactivity problem of working with
| compressed intermediary frames.
| traspler wrote:
| One big problem I have with the image/video format zoo in the
| browsers is that it becomes an incredible complicated task to get
| the media out of the browser in a format all the other software
| can work with. It would be amazing if the browsers offered a
| built-in ,,Download & Convert" feature for images and videos.
|
| Pages automatically defaulting to webp so you try to send the
| link through a messenger and you might notice that it doesn't
| work for everyone, either iOS users can't see it or the messenger
| interprets it strangely. So you try to save the image and send
| that, same problem, you get the webp image...
| [deleted]
| Geee wrote:
| What would be even more amazing, is that browsers would
| compress / convert formats on upload. Especially video. It's
| stupid to upload gigabytes of raw video to a server which then
| compresses it to a few megabytes.
| dylan604 wrote:
| If you're willing for your video to suffer quality from bad
| compression settings because your browser is a "dumb" tool
| that just applies some preconfigured compression scheme, then
| great. Also, how many people are going to accept that instead
| of just uploading files and seeing immediate progress vs
| waiting for a browser to compress a file from some sub-$500
| laptop? What codec is it encoding to? H.265? good luck
| getting that to complete this week on that cheap laptop.
| Osiris wrote:
| Reminds me of the native plugin days where based on mine type,
| a plugin would handle the content.
|
| Could WASM in an extension be good enough for some use cases
| like this?
| dangerface wrote:
| Yea its awful the number of sites that use .jpg but its actualy
| a webp with the wrong extension, like thanks I hate it.
| slig wrote:
| Thanks Clouflare for that.
| vbezhenar wrote:
| It is a bad idea with lossy compression. Every convertation
| will make quality worse.
| nine_k wrote:
| Desktop Firefox already has it.
|
| Right click -- "Copy image" -- paste into any program that
| supports PNG.
|
| On Android though this is not the case.
| Pxtl wrote:
| Really? I'm getting "your browser does not support JPEG XL"
| in Firefox.
| nine_k wrote:
| I mean the way to export an arbitrary image in an open
| format, not JPEG XL support yet.
| philo23 wrote:
| I've noticed sometimes that when Cloudflare optimises images
| and serves up their own WebP versions of your existing images,
| if you go to save it you get the original jpg/png back.
|
| Presumably the HTTP request that gets sent when you save an
| image sends different Accept headers.
|
| Doesn't seem to work all the time, but presumably thats down to
| a combination of different Cloudflare settings, origin server
| configuration and what format the original image were in too.
| tyingq wrote:
| My guess is that the HTTP client request, when you do right
| click "Save Image As", is sent with Cache-Control:no-cache
| and Pragma:no-cache headers. Which bypasses Cloudflare.
| jonsneyers wrote:
| I think it just re-requests without the "Accept:
| image/webp" in the request header, so you get whatever the
| server would have sent to a browser that doesn't know about
| WebP.
| tyingq wrote:
| That seems like it would have to be an unusual hardcoded
| path in the browser's code. I can't figure out why it
| would do that.
| jandrese wrote:
| Too many complaints that they downloaded a picture from
| the web that their image viewer can't open maybe?
| CyberShadow wrote:
| > It would be amazing if the browsers offered a built-in
| ,,Download & Convert" feature for images and videos.
|
| In a way, they already do for images: right-click and "Copy".
| In some desktop environments, you can even paste that directly
| into a folder to save it as a file. Dolphin allows choosing
| which format (of those that the browser can convert to) to save
| it in.
| lostgame wrote:
| Google Image search even does this! Incredibly annoying - only
| to go to the source image itself and find it to be JPEG or PNG.
|
| Very confused as to why this is done - anyone?
| p410n3 wrote:
| I always hated when people sent me screenshots instead of just
| downloading the images, but for the reasons you mentioned I
| know often find myself screenshotting stuff....
|
| At least I cut the image so it's not obvious
| Daemon404 wrote:
| Chrome does seem to save the JPEG version on some WebP or AVIF
| URLs where there is also a JPEG version available too, although
| it seems to be 'clever' about it rather than explicitly
| offering the option, which can make saving the actual WebP or
| AVIF mildly annoying.
| krzyk wrote:
| Really? I find browsers as a software that recognizes fewest
| number of image formats.
|
| ImageMagick is just few keystroke away and you can convert to
| almost any format you like.
| h0nd wrote:
| At the same time content providers are trying to make it as
| difficult as possible to 'steal' their videos and images.
| phkahler wrote:
| >> At the same time content providers are trying to make it
| as difficult as possible to 'steal' their videos and images.
|
| Well, screenshot is a thing for images. Video is another
| story.
| BEEdwards wrote:
| OBS works great for screenshoting videos.
| dylan604 wrote:
| I like how you put steal in quotes to minimize the fact that
| is what you are doing. If you walk into an art gallery or
| musuem, you can't just take art of the wall and walk out with
| it. Just because the gallery is a website, people feel like
| they can just right-click and save as and walk out the door
| with it. Yet, people understand that highlighting text
| copy&pasting it into their own work is plagiarism. I honestly
| do not understand the disconnect. If the website felt like
| the imagery should be free for people to do what they want
| with, then they would provide a link to a higher quality
| image rather than a highly compressed one.
| desiderantes wrote:
| Wonky comparison, as plagiarism involves claiming
| authorship/evading citing, not literally copying text and
| keeping it somewhere else. I CAN go and copy text from any
| textbook into my notebook without consequences, why
| couldn't I download a copy of an image?
| dylan604 wrote:
| Did you ask for permission and were granted permission to
| take that image from the server for any other use than
| for viewing in a browser? What is the purpose of
| downloading the image? To share with friends? Why not
| send a link to the site? To use a desktop background? Did
| you pay to license for that use? To store on your phone
| for your own personal enjoyment? Again, why not reload
| the website?
| spider-mario wrote:
| Some countries, like France <https://www.legifrance.gouv.
| fr/codes/article_lc/LEGIARTI0000...> and Switzerland <htt
| ps://www.fedlex.admin.ch/eli/cc/1993/1798_1798_1798/en#ti
| ...>, cite several exceptions to copyright including
| private copying.
| NoSorryCannot wrote:
| As a lowly end user not intending to widely redistribute
| the content, I decline this absurd level of
| responsibility, and the doctrine of fair use would tend
| to agree.
|
| And as long as websites tend to modify, delete, move, or
| otherwise play games with urls and content, I will see
| value in saving a permanent copy. That I should be able
| to do that is frankly how the internet was intended to
| function; if that's not desirable for the content, then
| perhaps it should not be published on the internet at
| all.
| dylan604 wrote:
| >And as long as websites tend to modify, delete, move, or
| otherwise play games with urls and content <snip> then
| perhaps it should not be published on the internet at
| all.
|
| Except an artist can deliberately decide to only make an
| image publicly available for a limited time, and
| therefore taken the image down from the website. Just
| like art moves from museum to museum, an artist can allow
| an image to be used within a pre-defined window. Just
| because you have the technical know how to extract an
| image that is not readibly downloadable via the UI does
| not mean you should.
|
| Maybe one of the features of JXL would be a timebomb type
| of setting where after a certain date the data is no
| longer useable.
|
| I sympathize with both sides of this argument. I get that
| info wants to be free blah blah, but I also understand
| that artists are in a difficult situation with the
| internet. I mean, an artist's work posted on the internet
| is not the cure for cancer, or basic information on
| algebra where the info should be evergreen. The group
| think is more of "I want what I want" vs consideration
| for what the artist's intentions are. If you enjoy an
| image so much that you're willing to go to the effort to
| get the image, why not acquire the image throuh legit
| method?
| Dylan16807 wrote:
| If someone saves an image for private use, that doesn't
| interfere with limited public availability.
|
| > If you enjoy an image so much that you're willing to go
| to the effort to get the image, why not acquire the image
| throuh legit method?
|
| Do you make the same argument when people use a VHS? If
| you're willing to go through the effort to press the
| record button, you should go buy a copy for $20?
| dylan604 wrote:
| Depends on the purpose the use of the VHS. Copying
| something you brought home from Blockbuster would
| definitely qualify. Recording something off of TV to
| watch at a later more convenient time was just the
| precursor to DVR.
|
| The image file you downloaded from someone's website
| without their permission in miles better in quality than
| the stupid VHS. It's more like the DVD/Blu-ray you ripped
| from your buddy that actually paid for it. Just because
| you can doesn't mean you should
| Dylan16807 wrote:
| Saving an image _is_ very high quality. But so is DVR.
| Usually a DVR copy is perfect.
|
| DVR sounds like a very good analogy to me. The website is
| showing you something, and you make a personal capture
| that you can replay at any time. It was distributed to
| you specifically, and you're time-shifting it. You're not
| taking a personal copy held by one person and making it
| two personal copies held by two people, which is what
| happens when you rip someone else's DVD. And the same
| way, you shouldn't take that image you saved and start
| distributing it around.
| Majestic121 wrote:
| It's a bad metaphor, because if you take the image from the
| gallery, other people cannot enjoy it anymore, while with
| the right click/save you make a copy, so it's still there
| for everyone.
|
| A better analogy would be if you make a painting of a
| painting without paying the original artist, is it stealing
| ?
|
| It's not : it can be construed as counterfeiting though,
| and it might cause the artist to stop painting because he
| does not make enough money, but calling it stealing is
| simply wrong.
| dylan604 wrote:
| Okay, so you're one of those hung up on a definition.
| What do you call it when you use something without
| someone's explicit permission whether because you didn't
| ask for it first or knowingly using it after it has been
| posted on a website that you do not have permission to
| use it?
| adrianmonk wrote:
| Normally, discussions about semantics are indeed
| pointless. But this is a rare exception.
|
| The word "steal" is chosen _because_ it carries a strong
| negative connotation. It is an example of loaded language
| (https://en.wikipedia.org/wiki/Loaded_language).
|
| Regardless of whether it's ethical to copy whatever files
| in whatever situation being discussed, the term "steal"
| is intended to sidestep that question and make it _feel_
| unethical by drawing an equivalence between it and
| something most people agree is unethical.
|
| It's a slightly underhanded rhetorical technique, so it's
| reasonable to put the word "steal" in quotation marks to
| call attention to it.
| Majestic121 wrote:
| Depends on the context. If the person loses access to
| what I'm taking (typical in the physical world),
| stealing. If the person does not loses access (typical in
| the virtual world or with artificial scarcity items),
| counterfeiting.
| dylan604 wrote:
| And you're okay with being an counterfeiter?
| jonsneyers wrote:
| I agree with this, and I think for this reason it is best if a
| new codec gets wide adoption also outside browsers, instead of
| having the approach of a "web codec" where it suffices that
| servers and browsers know about it but the wider ecosystem
| doesn't support it.
|
| WebP in particular, as the name suggests, was conceived as an
| "image format for the web" and while I think it's good to have
| the web in mind when designing an image codec, I think it's a
| bad idea to limit the scope like that. Design decisions like
| limiting the maximum dimensions and bit depth at the codec
| level "because that's all the web needs" plus limited
| attention/focus to adoption outside browsers does lead to the
| phenomenon you describe where "it doesn't work for everyone",
| causing the small gain of improved compression to be dwarfed by
| the huge inconvenience of breaking workflows.
|
| Any new codec of course has this problem even if they do target
| wide adoption (like JPEG XL): adoption is never instantaneous.
| It is a fact that the release cycle of browsers is more
| suitable for innovation than that of most other software, so it
| does make sense to start there even when it will still cause
| things to break in software that doesn't support it yet.
|
| To mitigate that, I think it would help a lot of browsers would
| have a "Save As..." dialog box on images that gives users the
| choice to save the actual image in whatever format it is in, or
| to convert it to PNG or JPEG.
| im3w1l wrote:
| Another solution could be that "someone" creates a library
| supporting all these formats that everyone else can then use.
| If the supported formats are queried at run-time, this means
| that just updating the library will automagically add support
| into other programs.
| bmn__ wrote:
| I believe AmigaOS and BeOS had that, ROX Desktop too? We
| could replicate the same nowadays via GStreamer, but
| adoption is hampered by its plug-in system, meaning that
| most installations are incomplete.
| chungy wrote:
| You are basically describing libavformat and libavcodec
| (part of the ffmpeg project)
| onedognight wrote:
| This would significantly increases browser attack surface
| area. Coders are usually much more complicated than decoders.
| jonsneyers wrote:
| Browsers already have to include an encoder for JPEG and
| PNG. They need that anyway for things like toDataURL(), see
| https://developer.mozilla.org/en-
| US/docs/Web/API/HTMLCanvasE...
| astrange wrote:
| The input data to an encoder is very simple since it's just
| pixels. It's possible to find a crash but it would be
| surprising to find an exploitable one.
| nine_k wrote:
| The browser has to decompress the image into raw pixels to
| display it anyway.
|
| Dumping these raw pixels into a trivial intermediate
| format, like uncompressed PNG or BMP, should not increase
| the attack surface in any noticeable way.
| jacobolus wrote:
| > _It is a fact that the release cycle of browsers is more
| suitable for innovation than that of most other software,_
|
| Also there is a huge financial incentive for large web
| hosting companies (e.g. Google, Facebook) to adopt
| compression formats that save bandwidth, using automated
| tools to apply those wherever possible.
|
| People making e.g. image archives or building image capture
| hardware are going to be slower. They don't want to use new
| untested technologies that might not succeed, and they don't
| want to switch more frequently than necessary. When they do
| transition it will be by applying new technologies to new
| images but not immediately transforming older images to use
| the new technology.
| jonsneyers wrote:
| True -- which is one of the reasons why JPEG XL includes a
| risk-free JPEG recompression option: if needed, you can
| just undo it and get the bit-exact same JPEG files back.
|
| Applying lossy recompression on already-lossy-compressed
| images is something you should avoid at all cost, since it
| inevitably causes generation loss (and it is also likely to
| not be very effective, since you're basically spending a
| lot of bits in the new codec on replicating compression
| artifacts of the old codec).
| JyrkiAlakuijala wrote:
| Happy users, faster growing userbase, more e-store revenue,
| higher click-through rates, lower latency, better quality-
| of-experience, or more 7-day-returning users can be more
| important financial incentives than bandwidth. Humans are
| more than thousands of times more valuable than a computer.
|
| When image quality and observed latency are at a level
| where users don't care even subconsciously (say, images
| look like camera originals and load in 100 ms), then
| bandwidth cost optimization may become a good 2nd
| objective.
| dgb23 wrote:
| We automatically convert user generated images to WebP if
| feasible and then use the <picture> element to display
| alternatives (the original format as the fallback). I'm
| pretty sure that this might be a common pattern.
|
| Browsers could allow a selection of all sources provided by
| the picture element (this would also include differently
| scaled variants based on media queries) in a download dialog.
| Zardoz84 wrote:
| It's not a option doing that if you need to serve a TiB of
| images and you need, yet, to support IE 11.
|
| JPEG XL on fly conversion to JPEG, offers a nice solution
| for this use case.
| dgb23 wrote:
| We support IE11 with a polyfill.
|
| The images are converted and stored when they are
| uploaded or changed. I can see this being an issue with
| that kind of volume though. But it's a performance gain
| for the clients while content doesn't need to worry about
| it.
| txtsd wrote:
| I'm worried about whether it will get adoption outside of
| browsers.
| The_rationalist wrote:
| While the collaboration between Google and Cloudinary is very
| welcome and the JPEG standardisation will accelerate adoption, it
| would be nice to see a comparison of JPEG XL versus FLIF/FUIF, it
| doesn't seem to have improved over it and it is unclear if it
| retains all features such as progressive decoding of animated
| images Cf https://flif.info/animation.html
| yoran wrote:
| Not directly relevant to the discussion, but I'm glad to see some
| (ex?) KU Leuven people involved in this.
| kapsteur wrote:
| No matter the technical quality of a product such as jpeg XL, it
| is the adoption by browsers that will make it a concrete product
| ?
| dtech wrote:
| Both chrome and Firefox have it in their nightlies. Similarly
| to webp, as soon as they have it it will be usable with header
| sniffing quickly.
| sp332 wrote:
| Facebook likes it too. And honestly that's a pretty big egg if
| browsers are the chicken. What are you looking for to recognize
| a "concrete" product?
| bick_nyers wrote:
| Been evaluating lossless alternatives to .PNG, the nice thing
| about .webp is that it is multi-threadable (hard to come by as
| far as lossless compression algorithms go), can JPEG-XL
| (lossless) say the same?
| janwas wrote:
| Yes, JPEG XL lossy and lossless formats both enable parallel
| and region of interest decoding by splitting the image into
| "groups"/tiles.
|
| The parallel speedup for lossless mode depends on the speed
| setting.
| znpy wrote:
| I'm looking at an original vs jpeg-xl in lossless and it seems
| that jpeg-xl alters the colors (blue in particular) noticeably?
|
| https://eclipseo.github.io/image-comparison-web/#abandonned-...
|
| Not sure if this is a good or bad thing.
|
| EDIT: Looking at https://eclipseo.github.io/image-comparison-
| web/#japan-expo&... some details about the metallic structure in
| the background are noticeably worse (less defined) in the jpeg-xl
| version.
| jerryX wrote:
| In Chrome it looks identical.
| jonsneyers wrote:
| If Original vs Lossless does not look the same, it is because
| your browser does not do color management correctly. JPEG XL's
| lossless is mathematically lossless, so there cannot be any
| actual difference.
|
| What can happen though is that the "Original PNG" doesn't have
| an ICC profile and gets treated by your browser in a different
| way than the PNG produced by the jxl decoder. This is a problem
| of your browser though, not of JPEG XL, and likely the image
| you see for "lossless JPEG XL" is the correct one.
| 0-_-0 wrote:
| According to IrfanView, the Lossless JPEG XL one has 167959
| unique colors, while the original one has 233263.
|
| For me it looks different in Firefox, the same in Brave (the
| uncompressed one in Firefox is the odd one out)
| jonsneyers wrote:
| I'm curious how IrfanView is counting colors then.
| GrinningFool wrote:
| Both comparisons appear identical to me in Firefox.
| markdog12 wrote:
| Looks identical on Windows, Chrome Canary 93.0.4549.0
| baal80spam wrote:
| I wonder how relevant is this xkcd going to be here.
|
| https://xkcd.com/927/
| clouddrover wrote:
| It's true that JPEG will hang around purely because a lot of
| software and hardware supports it and they can't all be easily
| updated. But existing JPEG images can be losslessly (and
| reversibly) transcoded to JPEG XL and you still get reduced
| file sizes:
|
| https://cloudinary.com/blog/legacy_and_transition_creating_a...
|
| JPEG XL will be successful for this reason alone.
| blowski wrote:
| It's kind of relevant, but it's probably relevant to half the
| posts on HN. By this point, it's kind of a cliche to bring it
| up.
| andrius4669 wrote:
| lossless reversible jpeg recompression seems to be a nod to the
| fact that jpegs aren't going anywhere.
| romanovcode wrote:
| On the web you want to use WebP nowadays so I would not be so
| sure.
| p0nce wrote:
| WebP has a bit less features, for example it's only 4:2:0
| (which looks great).
| formerly_proven wrote:
| Well that kinda depends, 4:2:0 is good enough for video
| and photo uses, but falls over pretty hard when
| confronted with synthetic images (e.g. UIs).
| pabs3 wrote:
| JPEG XL is allegedly better than WebP, so once browsers get
| support, seems like it would be the future.
| acdha wrote:
| WebP is slower and frequently the size benefits are quite
| small, even non-existent, as you'd expect for an old codec.
| Anyone concerned about bandwidth or features is probably
| going to want to support newer formats like HEIC which
| offer better performance to offset the cost of managing
| multiple formats.
| lcnmrn wrote:
| JPEG XL has a non backwards compatible mode too for highest
| quality/compression and the bitstream can be improved with
| better encoders in the future.
| nabla9 wrote:
| Very nice practical feature: "Existing JPEG data can be
| represented as-is in JPEG XL: no lossy transcoding!" If you need
| ever to convert huge amount of archieved jpeg, you can config the
| conversion not to lose anything.
|
| https://docs.google.com/presentation/d/1LlmUR0Uoh4dgT3DjanLj...
| jmiserez wrote:
| I know it's not the same, but technically you could do that
| with every format: just ship a JPEG decoder and detect if the
| input is a JPEG. The other way round would be much cooler, i.e.
| if each JPEG XL file also was a valid JPEG.
| jokoon wrote:
| Curious to see how it compares to BGP:
|
| https://bellard.org/bpg/
|
| Comparison:
|
| http://xooyoozoo.github.io/yolo-octo-bugfixes/
|
| But again, the main bottleneck with image compression is embedded
| software, like smartphone, cameras, etc. There is a compromise
| and cost/benefit between file size, transistor requirement, CPU
| cycles, power required, etc.
|
| For example, I would be interested to see the size of binary code
| required to compress JPG, JPG XL, BGP, WEBP, etc.
| est31 wrote:
| Quality wise, BPG is essentially the same thing as HEIF because
| both base on HEVC. There are comparisons with HEIF in the
| slides linked on the JPEG XL homepage:
| https://docs.google.com/presentation/d/1LlmUR0Uoh4dgT3DjanLj...
| formerly_proven wrote:
| n.b. HEVC is not royalty-free, while JPEG XL is.
| sp332 wrote:
| Thanks for mentioning this, I was curious and I thought it
| would be getting more discussion here.
| londons_explore wrote:
| Oh look, another barely used image format alongside WebP,
| Animated PNG, AVIF, JPEG2000, and a bunch of others so obscure I
| forgot them.
|
| It seems image formats have ossified. Nobody cares if the images
| are 50% smaller because storage and network are cheap enough not
| to deal with the hassle of using a non-standard image format.
| mschuster91 wrote:
| I would not call JPEG2000 being "barely used" - it is the
| standard format for all digital cinema movie packages.
| ianlevesque wrote:
| What is a digital cinema movie package?
| detaro wrote:
| The data format used to send movies to cinemas.
| layoutIfNeeded wrote:
| https://en.m.wikipedia.org/wiki/Digital_Cinema_Package
| speedgoose wrote:
| Cinemas don't use consumer grave video compression like
| h265, instead each frame is a jpeg 2000 image. It's heavy.
| KaiserPro wrote:
| To simplify its a tar with jpeg2000s as an image stream,
| plus audio and some metadata.
|
| Its then (usually, but it is optional) encrypted to make
| sure that its hard to copy. The keys are sent directly to
| each projector to allow time limited, and or other limited
| use.
|
| The reason why its used is because it optimized for
| quality, rather than size. It also allows custom colour
| spaces and other tweaks to maintain/enforce colour
| correctness/image quality.
| snovv_crash wrote:
| Its also heavily used in the medical imaging field for
| radiographs etc
| detaro wrote:
| also for aerial photography images.
| jonsneyers wrote:
| If nobody would care, then how do you explain all the effort
| that went into MozJPEG, WebP, BPG, FLIF, HEIC, AVIF and JPEG
| XL?
|
| Do you really think people are working on improved image
| compression just for fun, and not because "somebody actually
| cares"?
|
| Also, it is not just about compression, it is also about
| functionality. HDR displays are a thing, images with alpha
| transparency are also a thing. There just is no way to properly
| do HDR and alpha without "dealing with the hassle of using a
| non-standard image format", unless you think 16-bit PNGs are a
| good idea for the web.
| londons_explore wrote:
| Neat... But the only image on this page (the logo) is still a
| gif, an image format from 33 years ago, without any updates
| for 32 years.
| jonsneyers wrote:
| Sure, if you don't need images, then that's fine and you
| obviously don't need a new codec. There is a significant
| chunk of the web though that does make significant use of
| images.
| tusharpandey13 wrote:
| So just halt innovation because a fraction of the internet's
| users have fast connection speeds?
| hulitu wrote:
| > So just halt innovation because a fraction of the
| internet's users have fast connection speeds?
|
| Inovation ? Will it make life easier for people ? No. You
| still need to update. Will the page load faster ? No page
| still has 30 Mb at 50 kbps. Lossless ? Same as PNG. Lossy -
| same as JPG. So what is the inovation ? That with 20 threads
| on an Epyc is very fast ? How about my 1ghz phone with 4
| cores ?
| lucasmullens wrote:
| Lots of users in the world are still on 2G/3G and would
| greatly benefit from a faster image format.
|
| > Lossless ? Same as PNG. Lossy - same as JPG.
|
| This is incorrect, JPEG XL is smaller.
|
| Also why do you put spaces before your question marks? It
| makes your post look rushed.
| ncann wrote:
| I wonder how good the lossy quality and size is compared to JPEG
| Mini.
___________________________________________________________________
(page generated 2021-06-21 23:01 UTC)