Yeah, good point about the HDMI carrying the audio from the back already. I think I’m out of touch since I use an old receiver that doesn’t have HDMI. It’s funny that this is the one place Apple considered the convenience to its wired headphone users.
In what environment do you work where you need such low quality images though? In my web environment I only want the highest quality I can get at a reasonable size and I've never been interested in slightly less awful looking tiny images. In another comment I wrote about using jpegli at its default distance of 1 for everything and being happy with that size, so maybe I work in a completely different environment to you.
A normal one like everyone else I guess. No need to waste bandwidth and storage if you don't have to. If an image looks good to me, I'll try going lower until it doesn't look good, then go back one step. I've been surprised many times by just how low it can go and still look good. That script I wrote defaults to what I've settled on. (AVIF between 0.5 and 1 bpp at 1 megapixel, increasing or decreasing by square root of total pixels in image, plus JPEG fallback.)
If I change my mind, I keep high resolution originals of everything to do it again.
Pretty good news! I imagine that it'll take a while before libjxl and jpegli won't both supply a cjpegli binary so that'll be mildly annoying at the start, but hopefully this way it'll be adopted quicker so it'll accept more input formats and image software will switch over to jpegli native export instead of using the libjpeg compatible controls.
It's a really excellent software. Its default output quality is storage quality, while the file size is acceptable for mobile data and cloud storage of pictures in most countries. It producing progressive pictures by default still helps when quickly swiping through a whole album of vacation pictures stored on cloud storage, and its progressive output actually reduces size rather than add to it. And it's compatible with everything so now I just throw everything lossy I produce through its default settings until JXL becomes natively supported in Chrome and Windows.
Is it really 1.5× longer in practice? The N100s are efficient, and you can simply choose a lower power profile by sending a different energy/performance preference to the CPU, and it finishes tasks quicker.
If you were able to make do with cheaper GPUs, then you didn't need FP64 so you didn't need H100s in the first place right? Then you made the right choice in buying a drill for your screw work instead of renting a jackhammer even if the jackhammer would've seemed cooler to you at the time.
I think we're splitting hairs here, it was more about choosing a good combination of least effort, time and money involved. When you're spending that amount of money, things are not so black and white... rented H100s get the job done faster and easier than whatever we can piece together ourselves. L40 (cheaper but no FP64) was also brand new at the time. Also our code was custom OpenCL and could have taken advantage of FP64 to go faster if we had the devices for it.
Mm, that's not exactly true. Having done a bit of Android development, these days you're rarely operating on a "home directory" structure like you might be familiar with from Windows, Linux, etc. Instead you're saving files to a "container" filesystem that's exposed to the user in a few facets: Downloads, Photos, Music, etc.
What's even more confusing is that some apps save images directly to the "Gallery" which is separate from the "file and folder" view you get otherwise. So (as an inaccurate example), Fujifilm's app might download directly to your "Camera Roll" while GoPro's app might create a "GoPro" directory to dump photos/videos in, which offers more separation but doesn't appear in the "Photos" app by default.
Some apps even have toggles to switch between these two methods of saving files - though if I recall correctly, the non-Gallery/Camera Roll method (while desirable to many users) of saving images has technically been deprecated for a while.
My apologies, what I meant was "saved" to. Different applications have different default locations without ever prompting for it. I did figure out where FF mobile downloads files.
But attempting to save an attachment (from Telegram, WhatsApp, Viber...) and then either open it or attach it from another program leaves me perplexed. I generally rely on "share with" to avoid this, but I am guessing not all apps register proper MIME types or detect them properly so the option I need doesn't show up every time.
I guess the fact that I mostly moved from DOS to Linux never really got me away from thinking about files and directories, and inconsistency in Android really bothers me.
>I guess the fact that I mostly moved from DOS to Linux never really got me away from thinking about files and directories, and inconsistency in Android really bothers me.
Been there too. After some (maybe a lot) investigation I learned that this "inconsistency" in Android happens, because some apps use "private" directories which you (or other apps) aren't allowed to look at. Think of these as directories of user Linux users who turned off read access for others, i.e. "chmog og-r $HOME"
After finding apps like Solid Explorer and especially Termux, I learned to comprehend what's going on. But I still hate it that apps (and Android) prevent me from looking at my data the way I like to do it. For "security reasons" I not allowed to view things on my devices? Sheesh!
Nice apps like Markor or Diary (from Bill Farmer) store their data in user visible directories. As such apps exist, I tend to ignore those with limiting my access.
I get your frustration, that was an inconsistency I disliked about Android too. I felt like it was fairly normal for "power users" to have an 3rd party file browser with more functions to help manage the files on the phone.
One thing I appreciate about iOS is there's a Files app/UI, and if your app wants to save some user-facing data, it can go into the Files app. From there it's a simplified Explorer/Finder type file browser. It's not perfect but its consistent to me.
I loved that feature of my old Pixel. Even in the middle of Germany, with no cell reception whatsoever, I'd surprise people by looking at the always-on-display to see what song was playing somewhere.
Yeah it's pretty cool that it runs off-line. I wonder how large the local database is? They did add a second togglable option that lets you chose an online search if the song not recognized.
I don't know if it's actually easier to read in a sentence compared to the standard of Frutiger and Frutiger-likes. That's what you'll likely see on your medicine packaging and train- and road signs. It does try to be unambiguous by differentiating glyphs, which can be helpful with some standalone words.
ASML's success is partly (gross simplification) because it was the biggest local tech company (Philips) realising that they're too big to be effective, so they made a startup-esque new company which allowed them to be lean and engineering-focused. It's a good story of proper accounting allowing good company structures to persist inside of a bloated company.
Van den Brink gave a great interview some time ago, I'll see if I can translate it and post it here.
reply