[HN Gopher] Dithered images and websites (2020)
___________________________________________________________________
Dithered images and websites (2020)
Author : symisc_devel
Score : 68 points
Date : 2021-09-29 16:29 UTC (6 hours ago)
(HTM) web link (endtimes.dev)
(TXT) w3m dump (endtimes.dev)
| defanor wrote:
| Apparently the author's point is that image compression is
| useful, but dithering and then using lossless compression instead
| of using lossy ones sounds like rather poorly reinventing lossy
| compressions.
| munificent wrote:
| The reason so many blogs have "stock images of people in suits
| doing business" is because when the article is submitted to a
| social media app, the app scrapes the blog looking for an image
| to use as a thumbnail for the link. Pages with no image, get a
| default thumbnail and users don't click it. The _entire reason_
| so many pages on the web have some generic image from unsplash is
| because of these thumbnails.
|
| This means that the main meaningful way users will see the image
| is resized as a thumbnail, so before you start dithering, you
| should really test to see how the resized dithered image looks.
| Odds are good it will not look good.
| jameshart wrote:
| I think there's an interesting idea in here - not necessarily
| that 'everyone should use dithering', but more that _if_ you are
| using an image and _if_ that image is being used in a way that
| would not be harmed by stylizing the image in some way, that
| _one_ of the things you can consider when thinking about how to
| stylize it might be the compressibility of the stylized image.
|
| If you are coming up with a look for a site, dithering all the
| hero images, or running them through a cell-animation filter, or
| mosaicing them, or halftoning them, all are stylistic choices
| that might help your design stand out, _and_ help reduce file
| size.
|
| But... no, you probably shouldn't just diffusion dither
| everything down to black and white.
| w0mbat wrote:
| This makes no sense. For photographs, a decent quality JPEG is
| smaller and better looking than a dithered PNG or GIF.
| Gormisdomai wrote:
| If we grant that the right kind of blog could make the aesthetics
| of this work I still think users with cheaper internet might like
| to be able to click to load the original full-res versions of the
| images.
| robbrown451 wrote:
| The example images look awful. If the site really has images of
| "people in suits doing business," why would you want them to be
| so ugly? I'm not a fan of such images, but if you are going to
| have them, they should at least look pleasant. These look awful.
| zokier wrote:
| Just threw together quick comparison between AVIF and the
| dithered image: https://ibb.co/hKnwF1Z (scaled up 4x)
|
| I think we can pretty conclusively say that dithered PNG does not
| make sense from bandwidth point of view.
| armada651 wrote:
| As others have pointed out lossy compression will give a way
| better result. I feel like the author simply misses the aesthetic
| of the 90s internet and is trying to find any reason for it to
| make a return.
| [deleted]
| literallyaduck wrote:
| Maybe put dithering images outside the paywall and full pictures
| within and in your ad block placeholder a message that says pro
| users get the real images.
| mark-r wrote:
| So paying users get a slower site? That seems counter-
| productive.
| literallyaduck wrote:
| You sell it as quality. Think of ordering the quick paperback
| printing with black and white photos vs getting the full
| quality hardbound with a glossy photo folio in the middle.
| Premiumification vs free to read. It is also egalitarian as
| users aren't paywalled, get access to the content and only
| pay if they want to use the extra bandwidth.
| jjcm wrote:
| This is terrible advice. Dithering should not be used for
| compression. Real world example:
|
| Here's his dog picture encoded to webp using default settings
| (11KB): https://image.non.io/dog.webp
|
| This is smaller than all but his two color and his four color
| examples, at a tremendously higher fidelity. Just for comparison:
|
| webp vs original @ 11KB: 2.1% difference from source image.
|
| gameboy vs original @ 8KB: 18.2% difference from source image.
|
| 4 color vs original @ 9KB: 15.2% difference from source image.
|
| Even if you compress the webp down to 8KB, you only encounter a
| 3.3% difference from the original.
|
| TL;DR - use modern image formats. Don't use dithering for
| compression.
| mikl wrote:
| This reads more as an argument against dithering. Sure, it saves
| bandwidth, but all the images in the post look awful. If I saw
| pictures like these on a professional website, I'd assume the
| people behind it were incompetent.
|
| If you really want to save bandwidth, you'd be better off looking
| at better formats like AVIF, and WebP.
|
| Those will shave off a lot of extra bits, especially AVIF,
| although that is not universally supported yet.
|
| Combine that with making a the images a little smaller would save
| you a lot of bandwidth, without making your pictures look like
| they are 20 years old.
| theandrewbailey wrote:
| > If you really want to save bandwidth, you'd be better off
| looking at better formats like HEIF and WebP.
|
| Use AVIF instead. An image in AVIF is half the size of an
| equivalent JPEG. Chrome already has it, and full Firefox
| support is imminent.
| mikl wrote:
| Good point, I'll add that to my list.
| duffyjp wrote:
| Whenever I look into the modern formats excited to save 50%
| on bandwidth, I realize I'd have to spend 50% more on storage
| since I still need my fallback to JPEG. WebP is probably the
| best supported but isn't available on slightly older Macs or
| iOS devices. There are tons of iOS 12 iPads and pre-Big Sur
| macs in service.
| MrYellowP wrote:
| I like the idea a lot, but the execution on his website is
| horrendous.
|
| This GDC presentation, featuring Mark Ferrari, shows how it's
| done: https://www.youtube.com/watch?v=ri4_3P2Oh14
| discreditable wrote:
| With ImageMagick, you can use -colors to reduce the number of
| colors in the image. You don't even have to go down to 256
| colors. This will usually make photos larger in size, but
| drawings/graphics can be smaller.
| tyingq wrote:
| Not as drastic as the dithering in the linked post, but if you
| work with png files, pngquant is worth a look. It's lossy, but
| the image quality is still quite good.
|
| https://pngquant.org/
|
| Also, better to compile from source. There are os packages, but
| they tend to be older versions of pngquant that have various
| issues.
| edflsafoiewq wrote:
| The images in the article are not optimized, so the comparisons
| are not meaningful.
|
| For example, my-dog-dithered.png which uses only black and white
| is stored as 4x8 bpp instead of 1bpp. Running it through optipng
| halves the size.
| mark-r wrote:
| That seems odd to me. Isn't PNG compression based on a LZW-type
| algorithm, making the bit count of the inputs irrelevant as
| long as you're only using two distinct values?
| skyde wrote:
| the example in the page is kind of stupid. he could have kept
| using Jpeg but with increased compression ratio to achieve same
| file size and the visual quality would still be better than
| dithered PNG.
| bigattichouse wrote:
| If you take the "4x4 ordered dithering" image, and copy it, use a
| "mean curvature blur" filter (I used gimp - similarly for
| gaussian with low enough width) and overlay it on the dither at
| 50% opacity, the image actually looks pretty good. This could
| probably be done in CSS/JS on a client machine. a 14k image comes
| across passably, even on my desktop.
| tblt wrote:
| > The internet is responsible for 3.7% of global carbon emissions
|
| Given all the trade, commerce, learning, community, education,
| entertainment, and countless other benefits and multipliers the
| internet brings, I can't help but feel it's a fantastic return on
| its energy investment.
| Brajeshwar wrote:
| Isn't this the technique used in Black-n-White Newspapers. I used
| to help compose Newspaper layouts in the early 90s, and dithering
| of images were done for similar reasoning -- printing flat colors
| are bad, so dither them.
| jameshart wrote:
| There's a difference between dithering and halftoning, although
| with some techniques the results can end up similar.
| mark-r wrote:
| In particular the ordered dither can look very similar to
| halftoning, because it results in varying size dots.
| the_gipsy wrote:
| They look like shit
| vernie wrote:
| Hey maybe you want to jump on the brutalist web design
| bandwagon and have your shit look like a zine.
| jebronie wrote:
| satire?
| Sohcahtoa82 wrote:
| "The average web page has nearly 1MB of images."
|
| And probably 3 MB of JavaScript...
| petermcneeley wrote:
| Dithered images cause significant problems with many lower end
| LCD displays. When I scroll any image on my laptop or my phone
| they change brightness while in motion.
| kangalioo wrote:
| Seems more like an article on dithering generally rather than how
| to optimize your website
|
| If you just want small images, a lossily compressed image will
| probably look better than a lossless dithered image
| mnw21cam wrote:
| Agreed. The dog picture actually looks acceptable in jpeg
| format at 19kB (original 123kB).
| ThePadawan wrote:
| Does it? I tried this in GIMP and I get pretty bad block
| artifacts, discoloration, and blurriness at compression
| factor 25 (which ends up at ~25kB).
|
| I would say at that point it's arguable _which_ artifacts are
| preferable (compression or dithering), not compression being
| a clear winner.
| mnw21cam wrote:
| Tell GIMP not to include the EXIF and XMP data (which
| doesn't get any smaller when you decrease the quality).
| Then tell it to use 4:2:0 chroma subsampling, and set the
| quality to 24 or so.
| Veen wrote:
| It just looks a bit blocky/fuzzy when I try this. It
| doesn't look great, but it retains much more detail than
| the dithered version. It looks a bit better at the same
| size as a HEIC image.
| tyingq wrote:
| Here's one done with jpegoptim -m 40, which gets it down to
| 28k:
|
| Original 123k picture on top, 28k picture on bottom:
|
| https://imgur.com/a/hZy46K3
| ThePadawan wrote:
| Yes, this looks pretty much like my version.
|
| Maybe I'm just nit-picky, but I do quite clearly see
| greenish squares, especially on the forehead and nose
| area.
|
| Probably not enough to catch my eye, but strong enough
| that looking at the picture for 5 seconds I would say
| "boy this was compressed way too much".
| noja wrote:
| No.
| icyfox wrote:
| Images serve to make a website beautiful. Dithered images are not
| - in my mind - beautiful. There are other ways to optimize a
| website speed and bandwidth. Let's serve devices the image
| resolution that they can handle and not an XL image just because
| we can. Let's minimize JS cruft, minimize excessive renders.
| Sacrificing image quality would be near the bottom of my list.
| mrweasel wrote:
| Website exist to convey information, image are used to help
| convey information which is not easily explained otherwise.
| Using images to make pages beautiful is, to me, part of the
| problem with modern websites.
|
| I happen to like the dithered look, but arguably it might not
| be the best way to save on bandwidth.
| theandrewbailey wrote:
| Anybody who used a cheap PC in the 90s knows how horrible
| everything looked. It was a low-res dithered hell. I don't
| understand why anyone thought that gradients on a 256 color
| screen ever looked good, and wonder why we didn't have the
| modern, flat, solid color designs that are fashionable today
| back then.
| mywittyname wrote:
| >and wonder why we didn't have the modern, flat, solid color
| designs that are fashionable today back then.
|
| A lot of UI design on computers of the era was flat colors,
| maybe with a mild gradient. Go look up screenshots from
| Windows 3.1. Everything is flat grey or white. Windows 9x
| wasn't really much better, except it had that ugly solid teal
| background.
|
| Also, dithering on a CRT produced a very different effect
| from dithering on a high-res LCD.
| shakna wrote:
| > wonder why we didn't have the modern, flat, solid color
| designs that are fashionable today back then.
|
| I really, really, dislike the modern flat colour designs of
| today. They make it much harder for me to separate out what I
| care about, like context and information, because my eyesight
| isn't perfect.
|
| Gradients made it so much easier for me to see the difference
| between a tab and the bar it's sitting in. A little strip of
| colour or some shadowing, to denote the active tab just
| disappears for me.
| bitwize wrote:
| I'd rather have flat colors for background elements and
| bevels for "active" UI elements like buttons and
| checkboxes. NEXTSTEP-derived UIs (like Windows 9x) were
| razor sharp and easy to read... and it's funny how
| futuristic cyberpunk UIs, like the non-VR interfaces
| featured in _Johnny Mnemonic_ , were envisaged as being
| more of the same -- maybe a drop shadow or marble texture
| on the beveled button -- instead of the indistinct flat-
| shaded hellscape of today.
| rob74 wrote:
| IIRC the color gradients only started to appear once PCs
| which could display "True-Color" (or at least "High-Color")
| modes were widespread enough. The original Windows 95
| definitely didn't use them yet.
|
| And the "modern flat solid color designs" still use stuff
| like subtle shadows and transparencies that would have been
| either impossible or wouldn't have looked nice in the
| nineties...
| ohazi wrote:
| Dithering was never a compression technique, it's a filtering
| technique for reducing banding on devices/displays/images that
| have a small color palette.
|
| In fact, even in the 80's, dithered images were often _larger_
| than their un-dithered counterpart, sometimes by a lot. But it
| was worth the trade-off when the alternative was an image with so
| much banding that it could be confused for a European flag.
|
| Unless you're trying to display your image on a retro console (or
| have aesthetic reasons for wanting to achieve that effect), you
| should not use dithering. Essentially all modern devices have a
| sufficiently enormous color palette, and modern compression
| algorithms use other techniques to achieve their efficiency.
|
| In fact, modern compression will do a much better job giving you
| a smaller file size if you _don 't_ use dithering.
|
| Edit:
|
| Don't get me wrong, dithering is a _super_ interesting topic, and
| designing a good dither can be surprisingly hard, it 's just not
| going to help you if your goal is to shrink the images on your
| website the way the article claims.
|
| If you haven't seen the trailer for "Return of the Obra Dinn" you
| owe it to yourself to take a look:
|
| https://youtu.be/ILolesm8kFY
|
| Super cool aesthetic, and writing that shader must have been all
| sorts of difficult/fun. But you don't do this sort of thing for
| compression efficiency.
| kixiQu wrote:
| Really? IME images compressed real hard with modern techniques
| look pretty terrible. Dithering is _much_ less efficient if you
| 're looking for low loss, but if you're trying to get something
| quite lossy, it looks better to my eyes.
| zokier wrote:
| Do you think dithering beats AVIF in this comparison?
| https://ibb.co/hKnwF1Z
| pornel wrote:
| The problem is that in terms of file sizes, a "quite lossy"
| dithered PNG file is still likely to be larger than a "low
| loss" AVIF.
|
| AVIF can look fine in full color at 0.5 bits per pixel.
| That's equipment of a black and white dithered bitmap with
| 2:1 compression ratio.
|
| Low-color dithering can be a nice artistic filter, but it's
| not useful in image compression in general.
| ohazi wrote:
| The loop filters in modern image/video compression systems
| don't know anything about dithering. If you want a pixel
| perfect dither like what you remember from the 80s, you're
| going to need _way_ more bits to encode the image, because
| you need to encode those pixels as expensive residuals that
| can 't be ignored, rather than obvious (to the decompresser)
| pixels that can be inferred from the decompressed pixels in
| neighboring regions.
| lpghatguy wrote:
| This was something I helped with recently, as a great case
| study. We launched a new website for our game studio recently
| and went all-out on supporting modern compressed images: AVIF
| and WebP with PNG fallback.
|
| The header image for this page was a doozy:
| https://uplift.games/about/
|
| Originally, the image came from art with the glow around the
| planet being dithered. The resulting PNG was over 2 MB,
| resisted crushing, and didn't downscale well. Trying to use
| AVIF and WebP with aggressive compression made the image look
| awful.
|
| We asked if they could remove the dithering and suddenly we
| got super great compression with some tweaking: 50 kB as
| AVIF, 68 kB as WebP, 797 kB as PNG (oof!)
|
| This is a large banner image. Smaller images can get _much_
| smaller with AVIF and WebP with no sacrifice of quality. It
| takes some tweaking and the tools were pretty bad in my
| experience. We wrote a couple utilities to do this and
| fiddled with knobs for awhile and it turned out great.
|
| EDIT: Looking at this page again closely, I can see
| interesting artifacts because of AVIF. Look at the robo-dog's
| left ear! You could probably use slightly higher settings
| than we did.
| jhncls wrote:
| Sometimes it is helpful to first reduce the number of
| colors (preferably to 256 if that doesn't cause too much
| banding, depending on the number of color shades used).
| Then png usually compresses a lot better. Png compresses
| badly when the image contains too many different colors.
| achairapart wrote:
| > Png compresses badly when the image contains too many
| different colors.
|
| Old trick to squeeze a few kb out of a png: Use Posterize
| filter from Photoshop, with very light settings.
| Basically it will just flatten the number of colors.
| theandrewbailey wrote:
| > Look at the robo-dog's left ear!
|
| Not sure how you created those AVIFs. The reference AVIF
| encoder[0] wants to use 4:4:4 chroma, but it looks like
| that hero image is 4:2:0. There is a small size hit for
| 4:4:4, but edges around saturated colors is much better.
|
| [0] https://github.com/AOMediaCodec/libavif
| vikingerik wrote:
| > In fact, modern compression will do a much better job giving
| you a smaller file size if you don't use dithering.
|
| Not necessarily. The idea of dithering is to use a
| representation with a smaller color space, meaning fewer bits
| per pixel, possibly palettized.
|
| The idea is to control where the lossiness "damage" happens.
| You deliberately discard information in the area of color
| depth, rather than whatever the modern compression might choose
| to discard. It's possible you could get results that to an
| observer appear subjectively better per file size.
|
| Imagine a photo of masonry brickwork. What's important is the
| edges between the brick and mortar, while you don't really care
| about the grain within a brick. General-purpose image
| compression tends to smear sharp edges like that. It's possible
| you could do subjectively better by reducing the color depth,
| to intentionally discard more of the data that you don't need
| with dithering to keep a little of it, while keeping more of
| the information you do want in the sharp edges.
|
| I'm not claiming any of this would pan out for real-world use,
| but there are certainly hypothetically feasible cases for
| dithering.
| pornel wrote:
| Your example is about saliency and perception. Modeling these
| to guide lossy compression is an important feature of high-
| end encoders, but that is largely independent of compression
| techniques used.
|
| It's possible to do optimal-ish highly compressible dither
| (it's been done for LZW), but the results are still pretty
| disappointing compared to even old JPEG.
| ohazi wrote:
| In practice, video inspired image compression techniques
| (i.e. HEVC Main Still Picture) will do a significantly better
| job on that masonry brickwork image.
|
| The algorithm is already looking for patches of image that
| have moved by possibly hundreds of pixels (to sub pixel
| accuracy) both within a single frame, and across multiple
| frames.
|
| Basically, it'll find a patch of image that, when shifted
| horizontally and vertically by a certain amount, looks pretty
| close to the patch of image that it's trying to encode. The
| compressor will then say "just copy that region that you
| decompressed half a frame ago to here first, and now the
| residual values I give you are differences between the first
| patch and the second."
|
| Even if the brick / mortar phase is slightly off (e.g. from
| perspective or lens effects), this will give you about an
| order of magnitude more compression efficiency (and
| perceptual quality) than anything that tries to use color
| depth to preserve edges.
| LeifCarrotson wrote:
| Specifically, modern formats use gradients where possible. If
| something transitions smoothly from one color to another, they
| can represent that as what it is - to oversimplify, one pixel
| is the first color, a different pixel some distance away is the
| second color, and the decompression will generate the
| intermediate colors for all the pixels between those two. By
| manually dithering, it has to encode each pixel individually,
| because the transitions are gone.
| CodeIsTheEnd wrote:
| Directly related to dithering and compression, Return of the
| Obra Dinn is, to an certain extent, an "unstreamable game".
|
| When this streamer on Twitch tried to play it [1], the quality
| of his composited webcam would immediately drop as the
| compression algorithm focused on rendering the high-frequency
| dithering sections of the screen. As soon as he would aim the
| camera away from the fancy rendering (to the sky for instance,
| or the menu), the video quality would immediately improve.
| Really a fascinating clip.
|
| [1]: https://imgur.com/S191sI0
|
| Here's a thread of someone complaining about it on Reddit:
|
| https://www.reddit.com/r/Twitch/comments/ls06j5/the_unstream...
| bspammer wrote:
| The devlog [1] for that game is incredibly interesting, would
| strongly recommend to anyone interested in game development.
| If I recall correctly this compression problem almost made
| him reconsider the whole game - how can your indie game get
| any momentum if it's unwatchable on youtube/twitch? Luckily
| for us he persisted. Obra Dinn is one of the most interesting
| games I've ever played.
|
| [1] https://forums.tigsource.com/index.php?action=profile;u=3
| 073...
| DantesKite wrote:
| That's pretty amazing analysis.
| ohazi wrote:
| I hadn't thought of that, but this is hilarious, and
| illustrates my point perfectly.
|
| If your compression algorithm isn't aware of the exact dither
| you're using, the decompressor can't reproduce the dither on
| the other end using only rules and image data. The compressor
| needs to encode every single dither pixel as an expensive
| "Hey decompressor, you're never going to be able to guess
| this pixel value, so here's the whole thing" residual value.
|
| This is also why old image compression algorithms that were
| aware of _simple_ dithers (i.e. a handful of fixed grid
| patterns) could produce small-ish images that looked slightly
| better than un-dithered, but still kind of bad. But then as
| soon as you customized the dither to use a more random
| looking pixel arrangement that looked significantly better,
| the filesize would explode -- because the compressor was
| blissfully unaware of the more complicated dither and had no
| choice but to encode all of the seemingly random pixels
| directly.
| crtasm wrote:
| Do you know if they tried the other rendering modes
| (shaders?) included in the game? From memory there were at
| least five and some of them looked more suitable for
| livestreaming.
| tgsovlerkhgsel wrote:
| The best counterexample for the claim that dithering is a good
| idea is the post itself. It shows a high quality (albeit
| downscaled) picture of the dog that is only twice as big as the
| horrible-looking dithered versions. And at 30 KB vs. 14 KB,
| _HTTP header sizes_ already start to make the marginal savings
| questionable.
|
| https://imgur.com/a/eBxFlL5 has 4 images next to each other -
| the original scaled down image, the 14 KB dithered image, a 14
| KB JPEG, and a 8 KB webp (both the JPEG and WEBP were at the
| full 500x500 resolution, downscaled afterwards, since in my
| experience that often yields better results).
| dirtyid wrote:
| >Climate Change. Big images waste electricity and emit carbon.
| The internet is responsible for 3.7% of global carbon emissions4.
| A number that keeps growing as we send more and more data.
|
| This is a fun stat, I wonder how much physical infrastructure is
| actually behind serving all the images vs videos / adtech.
| system2 wrote:
| "The average web page has nearly 1MB of images."
|
| LOL What. Make it 10mb.
| cube00 wrote:
| :s/images/javascript
| eigengrau5150 wrote:
| And you could replace them all with dithered WEBP images of
| William Howard Taft. Nothing of value would be lost, content-
| wise.
|
| https://en.wikipedia.org/wiki/William_Howard_Taft#/media/Fil...
| neivin wrote:
| LOL no.
|
| This is literally moving backwards.
| WithinReason wrote:
| Dithering for compression is a bad idea, dithered images are much
| harder to compress than undithered ones.
| Panino wrote:
| I like dithered images and appreciate the author's post.
|
| If you don't, but you want your webpages to load fast, look into
| WebP and AVIF images. Load them opportunistically using the html5
| PICTURE tag - no JS required and no worry about old browsers not
| supporting new formats. Even plain lossless encoding of legacy
| formats goes a long way. Test your own site for ideas:
|
| https://webspeedtest.cloudinary.com
| pablodavila wrote:
| In case anyone is curious about dithering in the context of
| audio, here[0] is an excellent video on that.
|
| [0] https://www.youtube.com/watch?v=2iDrbgfPjPY
| kixiQu wrote:
| I'm a big fan of this piece! For those looking to play around
| further, there's
|
| https://ditherit.com/
|
| and on the command line, good ol' imagemagick comes through with
| something like
|
| convert picture_with_cool_colors_you_like.png -colors 10 -unique-
| colors sourcecolormap.png
|
| convert source.jpg -resize 500x500\> -ordered-dither o4x4 -remap
| sourcecolormap.png output.png
|
| mutatis mutandis. :)
| mark-r wrote:
| False dichotomy. Dithering is hardly the only or even best way to
| reduce image sizes. Just opening his 200x200 original in my
| favorite editor and resaving as JPEG with my usual parameter
| choices reduced it from 30K to 11K with no noticeable reduction
| in quality. I could have tuned the parameters for even more
| savings.
|
| Dithering isn't usually worth the reduction in quality. And
| ironically it can make things worse if you're not careful -
| dithering the image and saving it as JPEG actually INCREASED the
| size to 39K!
| pseudosavant wrote:
| This is generally some pretty terrible advice. Really, don't
| follow it. At least not without testing its impact.
|
| Dithered 8-bit/256-color images will look 'better' than non-
| dithered 8-bit/265-color images, but it will almost always be
| worse that a 24-bit JPEG (no alpha) or 32-bit webP (includes
| alpha) _and_ have a much larger file size.
|
| I did some quick tests with https://squoosh.app. The 8-bit
| dithered PNG is >4x the size of the JPEG. It also shows some
| terrible banding on any kind of gradient in the image. The PNG is
| 5x larger than a better looking webP version of the same image.
|
| I tested a lot of images (photos, drawings, digital artwork, etc)
| and some of the images were 10x larger as dithered PNGs vs
| webP/JPEG. Only one was smaller as a dithered PNG.
| kixiQu wrote:
| A. It looks like Safari didn't support webP at the time?
| https://caniuse.com/webp Either way, they explicitly mention it
| anyway.
|
| B. If the comparisons keep the pixel size constant, they're not
| relying on the cool thing about dithering, which is that you
| can dither down to a small color count and quite small pixel
| size then display larger with image-rendering: crisp-edges; and
| it'll still look #aesthetic. From my experiments with the tool
| you linked, the scaled-up equivalently-sized webPs look potato.
| This is most relevant for big hero images.
| eliseumds wrote:
| Same here, tested dozens of images from our website (user
| avatars, product images and logos), and the vast majority ended
| up being larger and with much lower quality. We serve WebPs
| generated using the sharp library with quality=80.
| xemoka wrote:
| It can even be tested with the author's own tool[1] and the
| sample image he provides. I'm surprised the author didn't
| experiment themselves? Or maybe the did, and the it's the
| further reduced settings they decided should be used...
|
| [1]: https://doodad.dev/dither-me-this
| omalamo wrote:
| I like the dither aesthetic and underlying message, but it's
| possible to compress the first image of the dog (123 kB) to 64 kB
| with MozJPEG and still maintain the same quality.
|
| Modern compression algorithms with native lazy loading will
| probably offer the best of both worlds.
___________________________________________________________________
(page generated 2021-09-29 23:01 UTC)