zeus ⁧ ⁧ ∽↯∼

Aye so bottom line, we’re stuck with what exists until new formats are forced upon everybody… ¯_(ツ)_/¯

yeah… :(

Raw isn’t a format, it’s supposed to just be unaltered stream from the imager, so every camera model is unique in that regard. But DNG is a way to describe that data so it’s more readable to programs unfamiliar with the specific model. And well, some makers prefer to use their own proprietary models.

ah fair enough, i didn’t know that

Actually AAC is mostly Apple’s format and support for it is pretty great. I’m not super familiar with the details but it sounds like a similar situation as with webp.

is it? i didn’t think any android players supported it apart from specifically apple music? and i’m pretty sure ms’ groove music couldn’t play them^?

It’s not. The web site you’re uploading to has to support it to allow you the upload in the first place, and to process it to make previews or lower-res versions for the web pages or apps.

alright yeah i guess. to be honest i was more talking about using images i’ve made on my own site, or publishers using an image format on their own websites. as for uploading to other sites it’s a complete mess: even tumblr doesn’t allow uploading webp, but it then automatically converts to webp which makes a horrible blurry mess

Do believe me, recently I’ve started converting those I want to keep to mp4 and I’m saving gigabytes.

i wasn’t being sarcastic! i do believe you. and yeah, i’d do the same

It’s not all that well supported in lots of those cases I mention. And where it did get, it only got because Apple has actually billions of devices out there and has the power to make the format default among them with one worldwide update. Yet it still has to convert to jpg when sharing elsewhere by default. That’s how huge the resistance is.

sorry, i was talking about jxl here. i agree heif hasn’t got anywhere; but that is, again, mostly due to licencing issues (unsurprisingly, given it’s apple)

I’m not advocating for these formats specifically (definitely not jpeg2000 haha), but I’m saying licences and royalties aren’t that super important when it comes to how supported something becomes.

Hell look at Apple… Everything is proprietary.

yeah exactly - none of apple’s formats are supported outside of apple devices (and i guess itunes for windows)

Or when it comes to formats, mp3 is still the most widely supported audio format (non-free), and DivX has been the most widely supported video format for much longer than anything else… Also non-free.

that’s a fair point, and i can’t really explain that - i can only assume it’s big for the same reason as gif: it was good enough at the time, and got standardised by cds

Haha hardware camera makers are the slowest dinosaurs when it comes to technology. Took them fucking ages for some to support DNG raw format, and before h264 was already getting grey, most would record videos only in mjpeg.

really? now admittedly i don’t know much about cameras, but i’ve had a couple of filmmaker friends and i was under the impression raw was universally supported

But it’s more about phone cameras anyway. And well with those we’ll only have webp and heif at most, so I guess we have to deal with that anyway.

i’m not sure about that - even google camera doesn’t support webp (i mean, it’s called “web picture”, i think they see it as a web format primarily). i think phone cameras will continue to be solely jpg for a long time

Maybe if Mozilla had not abandoned their FF OS, maybe that would’ve been a camera supporting jpegxl now.

that’d be nice. i do wish mozilla wasn’t so catastrophically mismanaged all around

That’s not how people use images. For an image format to be viable, you need your camera to support it, your gallery app/program to support it, the web sites you upload it to, the messaging platforms you share it through.

yes. i agree. but that’s my exact point. if i make an image then upload it to the internet - the only software that’s involved is on my side (gimp, ps, whatever^[1]) and the browser of the person viewing it. if it was supported in chromium, that’s automatically available in chrome, edge, vivaldi, brave, discord, element, spotify, whatever other chromium-embedded or electron apps you care to name. given the (unfortunate) prominence of electron-based programmes nowadays; that’s good enough for anyone who isn’t a professional, and they’re already fine. fuck it, it has the joint photographic experts group behind it - they’re quite a big name in photography

Oh you’d be surprised… Gaming videos on Steam, screen recordings, porn clips by amateurs, or just random clips, the amount of low-res gifs with 10s of MB in size is crazy.

meh, i haven’t seen any in the past ~5 years apart from ones specifically chosen for that 256 colour æsthetic; but i will believe you

Sure, it’s shitty of Google to drop the support, but from experience I’m still unfortunately 100% sure it wouldn’t have gotten anywhere.

Heck, Apple has been using HEIF for years and that’s a trillion dollar company with a huge market share, and you still get shitton of places where you can’t use it.

it did get places. it has got places. again, it’s very new and is already well supported

jpeg2k failed because of licencing and royalty issues^[2]. heif hasn’t spread because of licencing and royalty issues. ^{in my personal opinion, webp has licencing issues.} png didn’t. jpeg (sort of) didn’t. jxl doesn’t.

but anyways, this isn’t a pro-jxl comment; it’s an anti-webp comment. i used jxl as an example of why webp, and its adoption, is making the web worse even though it’s better than png from a technical standpoint

Sorry, 5 graphics programs isn’t “support”. You need support from the millon mobile apps, web sites and image and web libraries. A format that you can only use by yourself or with a handful professionals is useless in practice.

i gave those because they’re the most pertinent programmes for people dealing with creating & editing images. there are mobile (or at least android) libraries; and web is the issue i’m talking about - it’s hampered by chromium. there are more here if you’re interested.

and i’d say that’s not bad for a format that’s only a few years old

Ed: look at the list of formats supported by XnView

i don’t know what this is supposed to mean. xnview supports jxl

There’s been hundreds of new image formats in the last ~20 years, and none has gotten anywhere.

because png is good. i’m not defending gif or jpeg, they suck. but png is simple, fast to decode, and open by design. there have been better formats, but not paradigm shiftingly better. it may not be the best as an image format, but it is good

Even PNG needed a decade for some things to support it properly, and that one really had a brand new massive use case.

yeah that’s my point, jxl has been adopted faster than png or webp (it was only officially standardised in 2022!)

People use gif to make videos for crying out loud, and bitch about webp all the time, that’s how massive the pushback against new formats is.

i really don’t think many people use gif. most people use gifv or similar (usually webm) without realising it. apart from its very specific use case, gif sucks; so most software automatically converts to something else

Do you really think jpegxl would get anywhere by itself? No, it would be the same as with jpeg2000 and tons of other formats - first supported by a handful of programs, but not used by anyone else and then forgotten.

jpeg2k had major issues other than a lack of support - jxl has deliberately avoided those pitfalls

jpegxl actually has pretty good support - affinity, photoshop, gimp, krita, etc. all support it fine

it’s only chrome/electron that’s holding it back (even firefox supported it until chrome dropped support). i don’t think it’s lazyness

i have no love for gif (hence i use apng), but all the other alternatives are either videos so show controls by default, not widely supported, or webp. i realise webp is objectively the better format for most things, but i still argue it’s existence is a net negative effect

webp may be open (although actually i’d argue it isn’t, the licences for the decoder and the format itself are both very woolly), but as it’s actively contributing to enshittification by holding back truly open formats i’d say that doesn’t really matter

now whilst i know why people like webp, maybe we could stop using formats owned by google…

until jpegxl becomes viable (which it mainly isn’t because it compete[s/d] with webp), lets stick to nice formats not owned by tech giants, like apng^?

well that’s better than i expected^[1]. thank you for answering!

just out of interest db0, did this thread in any way change your opinion on webp?^[1] i’m just constructing a pet theory on internet discussions

(sorry to necro an old thread, and i’m sure you have other things on your plate right now; i’m just interested)

(also completely off-topic; i’m surprised your blog still has the wordpress favicon. i would have thought you of all people would have changed that)

well it’d obviously have to be digital, and it would be nice if it were secure as well

maybe down the line we could get a high capacity version, or even xtreme capacity

at the time; the great suspender (although that’s dead on chrome now too)

project naptha is the only one that has stuck with me since i left chrome, and has no firefox alternative to my knowledge

Left or right edge, it’s the same. If you are holding your phone with your right hand, your thumb is either holding the phone by the right edge, or is just hovering on top of it.

OH. alright, i didn’t know that, that’s much better

At least on LineageOS it can register a diagonal swipe as long as it sorta fits into a 45° angle, either downwards or upwards.

yeah alright, that seems pretty reasonable then. i think that does sound fairly consistent and predictable

You don’t need to reach the middle bottom of the screen, any area on the bottom can trigger the home/recents gesture.

okay actually that is good then. that’s perfectly fine. (although when compared to buttons, i still don’t know how i’m supposed to reach the left edge to go back)

The notification drawer has a bigger and more visible trigger area, tho.

yeah fair point, but it’s still the same paradigm of an item that gets dragged into the screen

I thought you were talking about system gestures, not nav drawer

i was sort of talking about interaction inconsistencies, but alright let me rephrase: a swipe right goes back, but a diagonal swipe does [presumably] nothing despite them being pretty semantically similar

I made it implicit, but forgot to say out loud: While system gestures makes the open-drawer-edge-gesture worse to the point of unusable, I think that looking back it wasn’t that good to begin with. Which is why I think Material Design never officially supported it in the first place, way before gesture navigation was a thing.

i mean, i’d say it’s better than nothing. otherwise one has to reach all the way up to the top to press the hamburger menu

The pill-thingy is anchored to the bottom of the screen, so basically it always point to the ground, the back gesture is on the side. It isn’t uncomfortable because it matches the easiest point to reach, which is the side of the screen relative to the user, not the device. This very old image shows the most reachable areas of a screen:

that doesn’t seem hugely ergonomic - i can hardly reach the bottom middle of my phone, let alone the left edge

Either that, or you were reaching into the realm beyond the screen to bring it on. That is something that I never quite liked for app gestures, because not only is it implied that things exist outside the screen(which is fine), but that you can somehow reach for them.

well yeah, it’s this exactly. your finger starts from off-screen, where the drawer is currently hanging out, and drag it on-screen. almost exactly the same as the notification drawer, the control centre on ios, or that stupid “charms” thingy on win8

Erm, there is no diagonal swipes, at least officially from Google. You just swipe perpendicular to the edge of the screen. So from the bottom edge you swipe up, from the left edge you swipe right, right edge to the left

i thought that was how one opened nav drawers with gestures enabled? a diagonal swipe; or swipe, wait, then swipe a bit more (which i’m not even going to go into how awful that is). including in official google apps?

ah, i see. in that case i can’t say i agree. i’d say that it’s fairly predictable - i can’t think of a single app with a drawer in which it didn’t work, until they introduced gesture navigation and broke it.

with a back button, it’s always in the same corner; with a back gesture what happens when the phone is rotated? (i genuinely don’t know) does it stay on the side it was on, or does it move so it’s now on the left? wouldn’t that make it very hard to reach with one hand?

A swipe from the edge to open a side sheet has a trigger area that extends far beyond the confines of the Hamburger Icon.

yes, but it doesn’t extend beyond the confines of the drawer. in my head it’s more like the drawer is always there, and you can trigger it with the hamburger, or “drag” it into view manually

And if any of the other gestures are present, then the edge gesture conflicts with them.

not really - one is from the edge, one is not. it doesn’t conflict any more than scrolling up conflicts with the new home gesture (and is far less often accidentally triggered)

Even worse is, the gesture with no visible area is “on top” of the others that have a predictable area, despite the fact that they exist on the “same plane”.

that is reasonable. i can’t say anything to refute that

Like, with the edge gesture to open a drawer, you need to keep the app elements in mind as if there is some physical elevation inside the app. The edge gesture is on top of the tab gesture, and things like that

i mean yeah, that’s the very point of material design. the whole spec goes on and on about the information conveyed by implied depth

but even before that, drawers and menus usually had some type of drop shadow to imply depth (practical skeuomorphism at work^!)

With the system gesture, the elevation itself is between the app and the system. Almost like if the system gestures are a glass panel on top of the app. It is a predictable rule.

yeah, i subjectively don’t like that. with nav buttons and a status bar, that’s where the system was and that’s how you interact with it. now it’s an invisible layer over the whole screen that’s not predictable at all; as a swipe right goes back, but a diagonal swipe does something else. that’s two gestures on the same metaphorical “layer”, one a system action and one an app action. weird.

Alright, but wasn’t the tab gesture also available on the holo era?

honestly i couldn’t say with absolute certainty, but i don’t think so?

The benefit is less conflicting gesture triggers occupying the same area. A swipeable card/list-item has the entire card/list-card as the visible trigger. A Tab has the entire content as the trigger area. The Navigation Drawer gesture is an invisible area that can be placed on top of the visible triggers of other components.

i’m not entirely sure that i’m following this correctly, but assuming i am: it’s the same number of gesture triggers

• old design
  • swipe from edge: nav drawer
  • swipe from anywhere: switch tabs (or whatever)
  • tap back btn: navigate back
• your design
  • swipe from edge: navigate back
  • swipe from anywhere: nav drawer
  • missing input: switch tabs (or whatever)

The issue is that the hamburger button is not the only button that can appear in that that place, a back button is common on that same area.

that’s a fair criticism

The trigger area isn’t the width of a button, but the width of a very specific button, and worse, it extends far beyond the edges of the button and shares the same height as the screen.

this i’m also not sure what you’re saying? it seems like a good thing to me - it takes up no space, and can be accessed from any height

I do see your point that “anywhere” isn’t an improvement, but I have to disagree, as that is fundamentally the same gesture to swap tabs, and you can predict the area trigger as being “just any old fucking where”.

i wasn’t strictly saying that, i was more refuting what i thought your point was: that “it’s not a discoverable gesture unless it’s tutorialised, because most people won’t randomly swipe in from the edge”; which i think in most instances is a very fair point, but in this specific instance i think it is discoverable because the drawer pulls in from the side. (source: i discovered it without a tutorial, or reading the md docs)

Yesn’t. Material Design 1 and 2 guidelines have a bunch of sections regarding interaction, way more than M3 (although M3 guidelines aren’t “finished” yet), but they lack a section regarding that gesture in particular.

Like, M1 guidelines mention swiping on content to swap tabs, heck, you can even find the same on the current Material Design 3 guidelines

fair enough. although in that specific example you could construe that as a warning of unforeseen conflicts, rather than a recommendation to implement swipe gestures. like, it doesn’t say “use swipe gestures for navigating between tabs”, it just mentions it as though it’s something the dev should already know (in the m1 guidelines, not m3 i guess)

I think it was a conscious design decision from the Material Design team to not use that gesture in particular? Because it isn’t due to conflict with other components, in the tab guidelines they call attention to be careful when the content itself is swipeable.

possibly? although i still maintain it’s likely that they saw it as part of holo, so there was no need to respecify it for md^? the same that they don’t specify that you can scroll down to move the content field^? especially as all of google’s own apps supported that gesture

I mean, you already can’t have certain gestures with other gestures. Like you can’t (or shouldn’t) have swipe on a card to upvote at the same time you have swipe content to change tabs.

yes; but my point is that it reduces the available actions for no discernible benefit. it’s not like they’ve added some spare buttons in the old place, like maybe bringing back the old universal menu button.

I’d argue this restriction is better for the user because with discord’s implementation it is very clear what the trigger area is, because the entire view is the trigger area.

maybe? i’m not sure about that though, as the hamburger button is on that side, and the drawer appears there; and i’d say “the edge from whence the drawer appears” is a lot clearer than “just any old fucking where”, but maybe that’s me

It’s funny, but I tried looking around the old Material Design guidelines and I haven’t come across any mention of swiping to open a drawer. I know it was on Android Developers, but it appears that from the point of view of the design team, it wasn’t really “officially” recommended?

i found this: https://web.archive.org/web/20140110123608/developer.android.com/design/patterns/navigation-drawer.html (alternative link in case archive.org is down) - i presume they removed it from the old spec when they introduced the gesture navigation, so people don’t use it because it interferes with the gestures?

wait never mind i misread this paragraph. i presume it wasn’t in the design spec as a) it’s an interaction behaviour, not a visual design behaviour, and b) it was also a thing in holo design (& older[?]), so they didn’t consider it part of the “material design spec”?

Regardless, Discord, IMO, offers a better implementation for side sheets, as the metaphor isn’t that you drag something from beyond the screen into view, you just drag the view itself to the side and that reveals the side sheet. And it works in the middle of the screen so it doesn’t interfere with the system gestures

it’s not a bad idea if you’re working around gestures, but it means you can’t have something where you swipe between tabs when not from the edge, and get the drawer when from the edge

or, for example, swiping to reply/forward in a messaging app, or upvote/downvote on a lemmy client

(also, subjectively, it’s kind of a bit ugly)

i’ve no mobility issues, but i can’t stand that back gesture. it interferes with the ability to open drawers; and i can’t spam it quickly to get out of a “deep” page in an app

gestures do have pros (for instance, the ability to hold and scroll through recents) but the back gesture just seems straight up worse to me

i’d never noticed how much the twitter logo looks like an upside-down sonic the hedgehog