WebP and images in general

Destry · 2020-12-21 14:56:16

I recently caught up with the world regarding the prefers-color-choice media feature. Now I need to catch up with nextgen image formats, like WebP, which have been around a zillion years, apparently.

Also on my list of to-dos was to figure out how to make use of Txp’s new tag attributes power for handling image sizing for different expected situations between large and small screens.

I know some of you probably have both situations wired, so if you could show what you’ve got cooking, rather than me or anyone else having to reinvent the wheel, that would be swell.

What I’m aiming for here is to refactor my <txp::figure [attributes] /> shortcode to auto-handle image sizing between large and small screens via Txp tag attributes, and work in WebP to png fallback (and WebP to jpeg) for Safari because that still isn’t supported (we don’ts cares about IE, precious).

So, I’d suspect that for the two fallback situations, that would require a custom tag attribute (e.g. fallback="") for either the values ‘png’ or ‘jpeg’. I guess that means for every image used, there will be two files. Does Txp recognize webp format? (I have not tested.)

The image sizing part via tag attribute(s) I don’t know, and what I’m hoping you you tag wizards can enlighten me on.

I’m starting here, which is my current shortcode for image figures:

<txp:hide>  FIGURE SHORT-TAG
   Use this tag in an article:
       <txp::figure [attributes] />
   Attributes are:
     id=""      (Required.)
     class=""   (Optional. CSS selector on FIGURE element. Leave out if you want full-width figure.) 
                 Value options:
                   figleft (wraps text right of figure having 350px width)
                   figright (wraps text left of figure having 350px width)
     number=""  (Optional. Leave out if 'Figure n.' is not used, otherwise provide for 'n' only.)
     caption="" (Optional. Overrides image meta-caption in Images panel.)
                   Useful for when a simpler caption will suffice over the detailed meta-caption.
</txp:hide>

<figure<txp:if_yield name="class"> class="<txp:yield name="class" />"</txp:if_yield>>
   <txp:image id='<txp:yield name="id" />' width="0" height="0" />
   <txp:if_yield name="caption">
      <figcaption><txp:if_yield name="number"><b>Figure <txp:yield name="number" /></b>. </txp:if_yield><txp:yield name="caption" escape="tidy,textile" /></figcaption>
   <txp:else />
      <figcaption><txp:if_yield name="number"><b>Figure <txp:yield name="number" /></b>. </txp:if_yield><txp:image_info id='<txp:yield name="id" />' escape="tidy,textile" /></figcaption>
   </txp:if_yield>
</figure>

I’m not locked in to anything there; it’s entirely open to adjustment.

My current options for the class="" are where certain figure widths are added in those respective situations. It’s kind of a compromise between the flexibility of choosing any image width and knowing what specific width will work most of the time when figures are floated. It does require tailoring images (i.e. cropping, etc.) to precisely what part of an image works best in each case.

I think the only real tricky part to sizes is when using a full-width figure, and how to size that down to something suitable for portrait mode in a phone (that’s just how most people will look at it); a wide angle image doesn’t work well like that or it gets squashed to such a small size as to be pointless. Better, maybe, is to focus it to the middle 390px, or whatever and let the ends overflow out of sight, and that also becomes part of the initial image selection/tailoring process before uploading to Txp to ensure the desired middle is always what you get.

Anyway, all thoughts welcome. Let the group learning begin.

Bloke · 2020-12-21 15:22:28

I think Safari was late to the game because Apple were having a Betamax moment with HEIC/AVIF/WebP. I don’t have strong views on either format – they all have their place and their pros and cons – so to lock out one format because it isn’t invented here seemed short-sighted. They might have had other reasons, I dunno.

Anyway, in theory, you can specify a WebP resource first and if the browser supports it, great, otherwise it moves on to the next suitable format in the list until it finds one or drops off the end and falls back automatically on the base image in the tag. The hard part is making the damn resources in the first place and uploading them/disk space annoyance.

Also, Txp doesn’t support WebP right now. I have a local branch where I tried it and it worked great for 95% of cases, but sometimes the GD library choked on it and created black thumbnails. So I parked it until we have a better thumb-generating library in place or some better tools at least when uploading images.

With regards setting the appropriate image, well, that’s where the <picture> tag comes in because then it’s not down to the browser but to you to specify “use this image at this viewport”. I’d suggest checking out some Art Direction and responsive images tutorials, which shows how you can mix <picture> and srcset to deliver the best compromise of art direction (where you dictate what’s seen) and responsiveness (where the browser chooses based on viewport, bandwidth connection, etc).

Destry · 2020-12-21 15:56:57

Bloke wrote #327730:

With regards setting the appropriate image, well, that’s where the <picture> tag comes in because then it’s not down to the browser but to you to specify “use this image at this viewport”. I’d suggest checking out some Art Direction and responsive images tutorials, which shows how you can mix <picture> and srcset to deliver the best compromise of art direction (where you dictate what’s seen) and responsiveness (where the browser chooses based on viewport, bandwidth connection, etc).

Will read up there. Thanks.

Btw, one reason I was focused on WebP (versus others like AVIF, which is barely supported) is because that was what was recommended in the page weight tests. There seems to be a general focus there that way currently, all things considered

bici · 2020-12-21 17:23:59

Bloke wrote #327730:

I think Safari was late to the game because Apple were having a Betamax moment with HEIC/AVIF/WebP.

i just discovered the HEIC image format yesterday when someone send me an image from their Android device. I was not able to open it on my MacOS desktop. My wife who uses a new iPad forward me the image. So somehow her OS knew how to handle it.

gaekwad · 2020-12-21 18:48:21

bici wrote #327734:

I was not able to open it on my MacOS desktop. My wife who uses a new iPad forward me the image. So somehow her OS knew how to handle it.

HEIC support landed in iOS 11, and I think High Sierra.

bici · 2020-12-21 18:49:59

gaekwad wrote #327735:

HEIC support landed in iOS 11, and I think High Sierra.

thanks. learned something new

phiw13 · 2020-12-21 23:20:30

Bloke wrote #327730:

I think Safari was late to the game because Apple were having a Betamax moment with HEIC/AVIF/WebP. I don’t have strong views on either format – they all have their place and their pros and cons – so to lock out one format because it isn’t invented here seemed short-sighted. They might have had other reasons, I dunno.

WebP was not supported before mostly due to potential patent issues (Google assurances are not worth much), then once cleared, it had to make its way into the OS (macOS/iOS) graphic libraries (now supported in iOS14/macOS11).

HEIC and AVIF are basically the same format with very minor differences. There is a faint taste of “not invented here” taste on the G. side about HEIC. AVIF is very new, came much too late on the scene to be included in the OS graphic libraries this year.

I am kinda meh on that WebP format. For line art (icons, graphs and figures, even screenshots from UI) well managed PNG files still beat the hell out of it – and think about reducing the number of colours in the file, as Eric Meyer recently reminded us again. For landscape / portrait etc, it is a toss, in my experience. I’ve seen quite a few images which are les crisp in some (shadow) details. Of course, people don’t really look at images.

bici · 2020-12-21 23:25:29

phiw13 wrote #327739:

WebP was not supported before mostly due to potential patent issues (Google assurances are not worth much),

HEIC and AVIF are basically the same format with very minor differences. There is a faint taste of “not invented here” taste on the G.

if it involves G i don’t care one bit for these formats. A pox on them.

Bloke · 2020-12-22 00:25:39

phiw13 wrote #327739:

WebP was not supported before mostly due to potential patent issues (Google assurances are not worth much)… There is a faint taste of “not invented here” taste on the G. side about HEIC.

Yeah, figured as much. Google were big on promoting WebP because I believe they had a hand in its creation, and their might probably helped push it. Plus, if Google were involved, it’d never be finished as they’d always be tinkering, so nobody else would be able to keep up and nail down a spec anyway.

I watched some stuff on how awesome WebP is (probably from a Google employee!) but even he said that it really depends on the type of image and the level of detail you’re trying to preserve. The takeaway was that it was nearly always smaller for similar perceived quality but if you zoom in (which, his argument was, that nobody does in real life) then you could see that JPEG was often richer in shadow detail.

Whether there’s room for VHS and Betamax or whether these image formats are another HD DVD vs Blu-Ray scenario, remains to be seen. JPEG and PNG work well enough for me, for now. I reserve the right to get excited all over again at various newer formats in future.

bici · 2020-12-22 00:30:29

Bloke wrote #327741:

Yeah, figured as much. Google were big on promoting WebP because I believe they had a hand in its creation, and their might probably helped push it. Plus, if Google were involved, it’d never be finished as they’d always be tinkering, so nobody else would be able to keep up and nail down a spec anyway.

I watched some stuff on how awesome WebP is (probably from a Google employee!) but even he said that it really depends on the type of image and the level of detail you’re trying to preserve. The takeaway was that it was nearly always smaller for similar perceived quality but if you zoom in (which, his argument was, that nobody does in real life) then you could see that JPEG was often richer in shadow detail.

Whether there’s room for VHS and Betamax or whether these image formats are another HD DVD vs Blu-Ray scenario, remains to be seen. JPEG and PNG work well enough for me, for now. I reserve the right to get excited all over again at various newer formats in future.

Ok … Now let me ask what is an accepted ARCHIVAL FORMAT? What does the Library of Congress specify. i think TIFF is one format.

phiw13 · 2020-12-22 00:45:20

bici wrote #327742:

[…] i think TIFF is one format.

TIFF is indeed a very good archival format, as it offers lossless compression, the full range of EXIF metadata, 48bit colour if memory does not betray me, support for a wide range of colour formats (RGB, CMYK, LAB,…). And patent free.

Destry · 2020-12-22 12:26:52

Taking it all in. Thanks.

After using the ImageOptim tool Pete suggested, my files dropped in size (that sure is an easy app to use). I wonder if WebP formats would even compare after that.

That would make an interesting test.

In the meantime, ImageOptim! (Or whatever it’s called.)

Btw, I don’t deal with high-quality images. I’ve never been able to use a camera to save my life, so needless to say don’t produce anything photoblog worthy. Thus I really don’t care about fine lines and shadows and whatever that some people need to care about. Just need to communicate a little sumpm’, sumpn’ with a screen crop or old thing in public domain, whatever.

Last edited by Destry (2020-12-22 12:32:46)

Textpattern CMS

Textpattern CMS support forum

#1 2020-12-21 14:56:16