Archive for January 16, 2019

Wednesday, January 16, 2019 [Tweets] [Favorites]

Google Pixel’s Night Sight

Jeremy Burge:

Whatever Apple does with the iPhone camera this year, they need to be able to compete with Pixel night mode. All taken on 18 month old Pixel 2 in challenging / dark conditions, and no iPhone photo at night comes close[…]

[…]

Seriously Google camera team: great job. You took a tiny sensor, put magic in the software and the results are unbelievable for a phone camera.

[…]

For those who haven’t used night sight on Pixel, it’s not ~just~ the magic in software. Pics also look better because the mode takes 2-5 seconds to take a photo. More light is captured, and movement stabilised. That’s what gives it the edge. That’s why iOS should offer this mode

[…]

No before/after pics online will do justice to photographing a near pitch-black room and getting a usable photo. Genuinely mind blowing.

Vlad Savov:

Google’s Pixel phones have already changed and improved smartphone photography dramatically, but the latest addition to them might be the biggest leap forward yet. Night Sight is the next evolution of Google’s computational photography, combining machine learning, clever algorithms, and up to four seconds of exposure to generate shockingly good low-light images. I’ve tried it ahead of its upcoming release, courtesy of a camera app tweak released by XDA Developers user cstark27, and the results are nothing short of amazing. Even in its pre-official state before Google is officially happy enough to ship it, this new night mode makes any Pixel phone that uses it the best low-light camera.

Previously: Google Pixel 3 and 3 XL, iPhone XS Users Complain About Skin-Smoothing Selfie Camera, The iPhone XS and Its Camera, iPhone and Android Cameras.

Update (2019-02-05): Stephen Sullivan:

As for a Night Sight comparison:

no flash was used, one photo is from the iPhone XR and one from the Pixel 3 with Night Sight feature on. 😯

Swift Community Podcast

Episode 1 (tweet):

Welcome to the Swift Community Podcast — a podcast for the Swift community, by the Swift community. On this initial episode, John Sundell, Garric Nahapetian and Chris Lattner introduce the concept of the show and why it was created — and recount their first impressions of Swift and the evolution of the community, starting with Chris’ initial prototype back in 2010.

Update (2019-02-18): Ole Begemann:

This is a transcript (edited for readability) of the parts I found most interesting. You’ll see I mainly quoted Chris Lattner because I think his account of how Swift was created is the most relevant to preserve for posterity.

[…]

John Sundell: And then he brought you out, right? That was the classic line: the “Objective-C without the C”.

Chris Lattner: Which honestly I have mixed feelings about, because that’s really not what it’s about.

John Sundell: It’s a good tagline.

Chris Lattner: It was the right thing to say to the community at the time.

[…]

Chris Lattner: The reason it is conflicting to me is that from the beginning of the project, my goal was to build a full-stack system. It was to look at all the existing systems out there, see what’s good or bad about each of them, and then cherry-pick the best ideas from systems wherever they come from. And the goal was really to build something that you could write firmware in or that you could do scripting in, that you could write mobile apps or server apps or low-level systems code, and have it be great at all of those, not just some terrible compromise.

So that positioning was absolutely the right thing to do [at the time]. But hopefully, Swift will grow over time in kinds of what it is able to do.

Previously:

Turning Type Sideways

Jonathan Hoefler (via John Gruber):

This month, researchers made official something that typeface designers have long known: that horizontal lines appear thicker than vertical ones. At left, a square made from equally thick strokes; at right, the one that feels equally weighted, its vertical strokes nearly 7% thicker than the horizontals. This phenomenon, central to typeface design, has implications for the design of logos, interfaces, diagrams, and wayfinding systems, indeed anywhere a reader is likely to encounter a box, an arrow, or a line.

[…]

Is it possible that all of typography’s many optical illusions can be correlated with misapplied learning from our experience of the real world? So much of perception involves reflexively adjusting for the effects of context, light, or perspective, in order to make quick judgments about size, distance, color, or mass. Do we perceive round letters as shorter than flat ones because we intuitively understand something about the weight of cubes and spheres? Is it a lifetime of looking at foreshortened things above us that leads us to expect a well-balanced letterform to be smaller on top than on the bottom?

On Public Bug Trackers

Brent Simmons:

Decisions about what to work on — and when, and by whom — are complicated. From the outside it might look like it’s as simple as picking the next feature request with the most votes, but it’s not that simple.

[…]

But if you have a public bug tracker, you’d likely find that you’re having to explain your decisions all the time. You’d be constantly defending your plans to people who remind you that Feature X has all these votes, so why hasn’t it shipped yet?

Smokey Ardisson:

Sadly, this is just as true for open-source software projects as for commercial ones, but there’s no way around it in an open-source case (there are, of course, some ways to ameliorate the effects). But at least now you can point everyone to Simmons’s list of reasons why you might not be working on that thing they’re interested in, instead of having to type out the reason(s) yourself ☺︎

Customer Support for Failing App Downloads

Bruno Virlet (tweet):

On reportaproblem.apple.com, if the customer selects the option “App fails to install or won’t download”, the customer receives the suggestion to contact the app developer correctly:

If you’re having issues with this app, please contact the app’s developer directly, they may have more specific troubleshooting steps for their app. Click on the App Site button to open the developer’s support page.

Of course, this isn’t due to a bug in the app because the App Store hasn’t even downloaded it yet. Despite my selling far more software through direct downloads than through the Mac App Store, customers report more download/installation problems when using the store. Another case where the App Store reality is not what one would have predicted. It’s galling that this remains unreliable when Apple controls every aspect of the process—and then blames the developer. These are some of the worst e-mails to get. The customer is rightly upset that I’ve just taken their money, yet they can’t download the app, and there’s not a lot I can do to help them.

Previously: Apple Support Tells Customers to Ask Developer for Refund.