Be nice. Or else.
Community Staff Founder at Bjango Joined over 4 years ago via an invitation from Christophe T. Marc has invited Matt Kelsh, Rene Ritchie, Dan V Peterson, Troy Mcilvena, Graham Clarke and 12 others, Jeremy Olson, Ramy M., Andrew Hart, Ricky Synnot, Aen Tan, Justin Velgos, Nik Fletcher, Rok Benedik, Nghia Nguyen, Jared Sinclair, Matt McDaniel, Elliot Jackson
In terms of saving PNGs, the best current approach is the same as before — just use Save for Web or Export As in Photoshop, or export as normal in Sketch.
But, the 2016 MacBook Pro and 5K iMacs do have wide gamut (Display P3) screens. They do complicate things a little. Design tools that are not colour managed will show wildly oversaturated colours (they’ll assume sRGB, but present the values in Display P3). In Photoshop, Illustrator and Affinity Designer, that’s fairly easy to work with — just set the document to use the sRGB colour space and everything should have the correct appearance.
Are you talking about saving PNGs used in iOS apps? Android apps? For the web? Or is the question more about general colour management and setup?
Actually embedding an ICC profile in your UI images won’t help much — if there’s no profile, iOS and Android treat them as sRGB. Web browser behaviour is a bit more complex, but Safari treats images with no profile as sRGB as well.
If you want to target Display P3 (as found on some new iOS devices), you will need to embed an ICC profile in your images though.
Sketch doesn’t embed ICC profiles in PNGs it saves. If you have “Save for web” turned on, it just includes a gamma chunk. If you turn “Save for web” off, it’ll just include an sRGB chunk (and no gamma info).
I’d like that. Stopping somewhere around 3× seems smart, and you’re right about the iPhone Plus models. Hopefully this year resolves that.
Yep, but what about 3×? That’s a common scale now. If you use 2× as your base, then 3× is 1.5 times 2×. And scaling by 1.5 means lots of blurry edges.
Far simpler and better to still work at 1×, so you can target 1×, 2×, 3×, 4× and 5× from the same base artwork. If you use 2× as your new base, things get a lot more difficult.
Yep, so Xcode renders those PDFs to PNGs with suffixes, negating any efficiencies you’ve gained by using PDFs — the overall app size will be the same (or potentially bigger, because now you don’t have a chance to optimise the PNGs).
Also, the PDF format doesn't have support for lots of things, so most tools will generate those features as 1× bitmaps inside the PDF. That means Xcode takes the PDFs with vector parts and 1× bitmaps, and scales them up to 3× bitmaps. Doing that looks bad.
Certain assets will be fine, but others will not. Using PDFs for iOS assets is a terrible idea. Here’s my take on it: https://bjango.com/articles/idontusepdfs/
I’m very aware of it, but haven’t found any need for app UI just yet. Display P3 certainly adds another level of complication to things.
Resolution and pixel precision will always matter! It’s true that high PPI displays are more forgiving, but having 1:1 mapped assets doesn't just improve image quality, it also reduces file sizes, reduces memory used, reduces memory bandwidth required, and as a cumulative effect, uses less battery.
Forcing titles to a max length seems like it would be a good solution?
Hopefully not, but 2×, 3× and 4× displays probably mean we’re stuck with supporting multiple densities for now, and maybe forever.
Android’s method of using different folders for each pixel density seems more sensible, and easier to evolve. macOS uses multi-part TIFFs that keep all the different densities in a single file. That’s neater, but requires Xcode or something like Xcode to author them, and you still need the @2x suffixed files as input.
So, yep. I think the @2x suffixed names are here to stay for iOS.
It’s going to be great… in 5 years’ time. :D