I found the answer on Google. I haven’t had to update any of my personnel sites in a while! Good to know. If any other print people come across this 1x, 2x, 3x issue, here’s a good link to see what’s what:
Thx all!
freewaytalk mailing list
email@hidden
Update your subscriptions at:
And… I just realized Duncan had the same link in his very detailed post to me. I didn’t see it because we apparently posted at the same time!!
Thanks Duncan, I very much appreciate your explanations and it has helped very much. I’m getting it!
Downloaded Sparkle and will take it for a spin.
joette/redfeather
freewaytalk mailing list
email@hidden
Update your subscriptions at:
Duncan is right to recommend “2x” (144ppi) at the largest pic size you will display. Three years ago I tested retina graphics extensively and found that 72ppi images look blurry and awful on retina iOS devices and Macs, but 144ppi looks very good, and 288ppi is great but almost too sharp. So 144ppi is the ideal in terms of look and filesize.
I usually can compress 144ppi JPGs to 44% in Photoshop without really seeing compression artifacts when displayed on a retina screen. But if there is a lot of tiny red text, I may need to take it up to a 50% compression to make it look nice. And when I need transparency, I tend to use PNG more than GIF because the filesize is smaller, and I use TinyPNG to compress my 24-bit PNGs into 8-bit files without noticeable loss in visual information.
So it seems that Sparkle will use your original pic as is, like a Freeway pass-thru image, when Sparkle displays that image at it’s actual 144ppi size, but Sparkle (or rather, the browser) will shrink the image when that same pic scales down on a responsive page, and Sparkle will present a lower rez 72ppi version of the pic when Sparkle wants to display it on non-retina machines. But how fuzzy or sharp that 72ppi image will be is not something I’ve tested in Sparkle, nor do I know if 8-bit PNGs will remain 8-bit PNGs (and so on) when Sparkle does it’s image manipulations. What I find in Photoshop is that if I make a 144ppi image to be 72ppi, it needs a little sharpening to look its best, unless I use the “sharper” resize antialias setting in Photoshop. So an extensive test in Sparkle would be necessary for one to know exactly graphics are output to both 72ppi and retina devices.
freewaytalk mailing list
email@hidden
Update your subscriptions at:
Duncan is right to recommend “2x” (144ppi) at the largest pic size you will display. Three years ago I tested retina graphics extensively and found that 72ppi images look blurry and awful on retina iOS devices and Macs, but 144ppi looks very good, and 288ppi is great but almost too sharp. So 144ppi is the ideal in terms of look and file size.
As mentioned “dpi” is an incorrect term. You might want to use it as a label but it’s rather abstract, 1x/2x/3x seem easier to remember. 3x would be 216dpi by that metric.
I usually can compress 144ppi JPGs to 44% in Photoshop without really seeing compression artifacts when displayed on a retina screen. But if there is a lot of tiny red text, I may need to take it up to a 50% compression to make it look nice.
The optimal JPG compression really depends a lot on the content, absolute figures like that aren’t a good rule of thumb. Optimal compression is still a bit of a research topic, Google built this tool which is a “psychovisual estimator" somewhat like mp3 uses psychoacoustics to compress best for music:
GitHub - google/butteraugli: butteraugli estimates the psychovisual difference between two images https://github.com/google/butteraugli
That said the smaller the pixel size the smaller and less noticeable compression artifacts are, the more you can compress the same image, so if you’re compressing the non-retina 1x jpg at 60% you might compress the 2x at 50% and the 3x at 40%. For example http://silev.org/test/Retina-resize.html http://silev.org/test/Retina-resize.html shows this.
And when I need transparency, I tend to use PNG more than GIF because the filesize is smaller, and I use TinyPNG to compress my 24-bit PNGs into 8-bit files without noticeable loss in visual information.
GIF is definitely a file format that should not be used anymore, for any reason including animation. 8-bit PNG only has 1 bit for alpha which most of the time really looks ugly.
So it seems that Sparkle will use your original pic as is, like a Freeway pass-thru image, when Sparkle displays that image at it’s actual 144ppi size, but Sparkle (or rather, the browser) will shrink the image when that same pic scales down on a responsive page, and Sparkle will present a lower rez 72ppi version of the pic when Sparkle wants to display it on non-retina machines. But how fuzzy or sharp that 72ppi image will be is not something I’ve tested in Sparkle, nor do I know if 8-bit PNGs will remain 8-bit PNGs (and so on) when Sparkle does it’s image manipulations. What I find in Photoshop is that if I make a 144ppi image to be 72ppi, it needs a little sharpening to look its best, unless I use the “sharper” resize antialias setting in Photoshop. So an extensive test in Sparkle would be necessary for one to know exactly graphics are output to both 72ppi and retina devices.
Yes Sparkle is applying light sharpening when resizing images.
Ultimately I have to wonder if all the hard earned knowledge is something that is worth clinging on to. I just came across this yesterday:
http://monkeyphil.co/blog/i-used-to-build-websites http://monkeyphil.co/blog/i-used-to-build-websites
So essentially the £5k and up website market is gone. And that figure is falling, fast.
Duncan
freewaytalk mailing list
email@hidden
Update your subscriptions at:
On 27 Aug 2016, 1:57 am, JDW wrote:
Three years ago I tested retina graphics extensively and found that 72ppi images look blurry and awful on retina iOS devices and Macs, but 144ppi looks very good, and 288ppi is great but almost too sharp. So 144ppi is the ideal in terms of look and file size.
Computer displays/monitors aren’t interested in ppi or dpi. You need to forget this idea.
Computers are only interested in pixels. So if an image is 1000x1000 pixels, then it will display as such on any monitor. That’s it. Setting it as being 72, or 100, 1000 pixels per inch will change nothing. IOW, a 1000ppi - 1000x1000 pixel image, will not appear as a 1 inch square image on your monitor.
So just choose the pixel dimensions you want. That’s it.
freewaytalk mailing list
email@hidden
Update your subscriptions at:
I disagree insofar as my eyes don’t lie, and I know how to save graphics in Photoshop and use them as pass through graphics in Freeway.
In Freeway, if I import a graphic into an HTML box (which makes it a “pass through” graphic) and I then checkmark the “high resolution” setting in the Inspector, that graphic will display at 50% size (50% of the pixel dimensions I set for that box in Freeway) but the graphics content be twice the resolution (i.e., 144ppi vs. 72ppi). And when I create my graphics in Photoshop, I set the dimensions (matched to the pixel dimensions of the HTML container box in Freeway) and choose 144ppi.
In that knowledge I had created a comparison in the past showing a 72ppi passthrough side-by-side with a 144ppi pass-through and a 288ppi pass-through. And the 144ppi looked best to my eyes and was a reasonable filesize too.
If I turn a blind eye to ppi, I will no longer what what I will get in the browser, at least not when I design in Freeway, using an HTML container box of known, fixed dimensions.
I fully understand that RESPONSIVE sites that scale graphics throw a monkey wrentch into this, but I have never created a responsive size that scales the graphics, so I am only thinking about a static “retina” graphic here that is viewed at 100% of its designed size in the browser.
Now with scalable graphics, it’s different insofar as you won’t know all the ways it will be scaled necessarily, but you still need a starting point. And I would assume my personal rule still applies with regard to the largest physical dimensions the graphic in question would be displayed. So for example, if the largest (default) size of the graphic is to be 1000x1000 pixels, then obviously that would be put into a box in the web design app that is half those dimensions in order to yield a 144ppi “retina” output (if the target output is intended for retina display devices). But if the web design app also saves a normal resolution 72ppi graphic for display on non-retina devices, then it would still display within the same physical dimensions but its resolution be would half the retina version. That would be the default, starting point size which would scale in the browser according to whatever algorithm the browser uses to scale graphics.
This is how I’ve always thought about graphics I design, and I see what I expect when I view my Freeway output in various browser on the Mac, Windows, and iOS devices, some with normal resolution and some with high-dpi screens.
So while some may dislike terminology, my eyes don’t lie. I know what I am seeing. I design for it with pixel perfect precision, and it looks good, and that satisfies me.
James Wages
freewaytalk mailing list
email@hidden
Update your subscriptions at:
DPI and PPI are printing terms. A monitor is not a print. Every image that doesn’t fit your monitor space precisely at 100%, is re-sized (interpolated) either up or down - ‘on the fly’. There’s nothing else to know. DPI and PPI on a monitor are meaningless.
freewaytalk mailing list
email@hidden
Update your subscriptions at:
Terms have meaning as long as one gives them meaning. You are preaching semantics without speaking specifically of what I wrote in my previous post. As such, I stand firmly behind everything written in my previous post and would like to direct everyone’s attention to it.
James Wages
freewaytalk mailing list
email@hidden
Update your subscriptions at:
Terms have specific meaning, and it doesn’t matter if you want to assign a different meaning to them, that’s still not going to change their actual meaning.
If you remember printing ink on paper, there you need to know DPI, and it refers to the halftone dot pitch – the distance between the centers of the dots of ink that fool your eye into seeing a continuous tone image.
Digital photos have a pixel dimension in the X and Y coordinates. They also have a header (metadata) that nominally sets the PPI (pixels per inch) of the file, but that’s just the divisor. If you have a 1000 pixel wide image, and it’s set to 200 PPI, that doesn’t make it higher or lower resolution, that just means that an application that cares about PPI will interpret it as being 5 “inches” wide, but since displays haven’t been 72PPI since they came with beige cases, that doesn’t mean 5 actual inches, either.
Web browsers do not care about inches. They only care about pixels. And even if you have a Retina screen, the browser still thinks it is painting a normal resolution screen. It just gets to use 4 (or more, if it’s an iPhone 6s Plus) actual pixels for each “pixel”, and the operating system deals with those details.
When you check that box in the inspector that marks an image as high resolution, all you are doing is telling Freeway to make the image twice as large (in pixels) when it resamples the original. The CSS tells the browser to make the image 50% of its actual pixel dimensions, and that means that twice the actual image data is available for the OS to fill in the 4 actual pixels for every “pixel” on the screen.
This actually gets us back to printing ink, if you think about it. Remember someone telling you that you needed to make your image file twice the PPI of the DPI of your dot pitch? That was for the same reason, because if you didn’t have enough resolution, you would not get a clean halftone.
Walter
On Aug 27, 2016, at 8:12 PM, JDW email@hidden wrote:
Terms have meaning as long as one gives them meaning. You are preaching semantics without speaking specifically of what I wrote in my previous post. As such, I stand firmly behind everything written in my previous post and would like to direct everyone’s attention to it.
James Wages
freewaytalk mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options
freewaytalk mailing list
email@hidden
Update your subscriptions at:
I haven’t assigned a different meaning to the same terms I’ve been using for decades. The only change I made in the past is in going from DPI to PPI lingo, and even we Freeway users had talks about that subject at the time with folks from SoftPress.
I understand your way of thinking. But all I have been saying is that I prefer to have a MEANINGFUL “frame of reference” for my brain to make perfect sense of pixel data, in light of the resolutions I wish to design for.
The following screencast with voiceover clearly shows why I said what I said in my previous two posts:
Thanks,
James Wages
freewaytalk mailing list
email@hidden
Update your subscriptions at:
I fully understand that RESPONSIVE sites that scale graphics throw a monkey wrentch into this, but I have never created a responsive size that scales the graphics, so I am only thinking about a static “retina” graphic here that is viewed at 100% of its designed size in the browser.
In some circumstance Sparkle can now create 30 variants of the same image. An image gallery with 10 images and 10 thumbnails would have 600 images. Would you be pixel peeping every one of those?
Duncan
freewaytalk mailing list
email@hidden
Update your subscriptions at:
No, Duncan. I probably wouldn’t. Then again, I don’t use image galleries.
Did you watch my screencast and understand my explanation though?
James W.
freewaytalk mailing list
email@hidden
Update your subscriptions at:
There is currently a browser rendering issue with retina images in recent versions of Webkit browsers when viewed on non-retina displays that leads to significant image softening. Safari seems worse than Chrome.
The fix (sort of) is to add some page CSS until the developers fix this properly, so it works like FireFox.
I’ve thrown up a couple pages showing this problem. You can see it at http://www.sunnymede.net/css/ and then follow the link to http://www.sunnymede.net/retina/ for comparison.
Ashley
freewaytalk mailing list
email@hidden
Update your subscriptions at:
On 28 Aug 2016, 12:12 am, JDW wrote:
Terms have meaning as long as one gives them meaning.
Quite hard to have a meaningful discussion with someone who is inventing their own meanings. 
Whatever works for you is fine. I was simply pointing out that you are misunderstanding what ppi and dpi mean as far as computer screens/monitors are concerned. It is a massively common misunderstanding, so don’t feel too concerned about it.
freewaytalk mailing list
email@hidden
Update your subscriptions at:
Ashley, I have discovered the same. On my Freeway sites, I have all my graphics changed to “High-Resolution” (2X, 144ppi, what have you), and I have noticed that my graphics are soft (non-ideal) in most browsers.
The solution here is for our web design tool to auto-generate sharpened 1x/72ppi/NormalRez graphics along side the Retina graphics, then sense the resolution of the viewer’s device and display the appropriate graphic. Freeway does NOT do that for us. But it seems that Sparkle does do that?
And again, for those who think ill of me for daring to use “ppi” please watch my screencast to see the logic behind using it as a mere “frame of reference for intelligent design purposes.”
As you can see in the screencast, that lingo is not exclusive to me. You’ll find it in any graphics editor. It makes a lot more sense to me than merely saying “2X” because when you say that you are left wondering “2X of WHAT?”
Thanks,
James Wages
freewaytalk mailing list
email@hidden
Update your subscriptions at:
@ Duncan
Do you now know why I wrote the allegedly offending topic above? The one you mentioned “against Sparkle”? The one I said “having nothing to do with Sparkle … having to do with results?”
“Even when the web-world thinks having the gist - a Freeway-user knows better!”
I basically was under the impression having understood “responsive concept”. But after reading all this stuff I’m not that sure anymore.
Very confusing - to be honest. And a good argument for Sparkle: Let the experts there decide what’s best. And I’m sure it’ll be a very good choice.
Cheers
Thomas
Shouting this from the corner of the room (although I should be banned from it anyway).
freewaytalk mailing list
email@hidden
Update your subscriptions at:
Very confusing - to be honest. And a good argument for Sparkle: Let the experts there decide what’s best. And I’m sure it’ll be a very good choice.
I figure you mean well. The point is the market for selling a handmade website doesn’t sustain the cost of keeping up with technologies.
Duncan
freewaytalk mailing list
email@hidden
Update your subscriptions at:
@JDW In testing I discovered I could obtain smaller file sizes and sharper results on non-retina displays with highly compressed retina resolution images thanks to the vagaries of pixel density. They also look great on retina displays where normal resolution images look soft.
All was well until changes were made a few months ago to webkit browsers and suddenly everything was mushy on Safari or Chrome. The CSS script I applied just about fixes it. I’ve not used Sparkle but this problem is browser based, therefore it’s the same for everybody.
In Rapidweaver there are various stacks and scripts that will load a non-retina image initially then serve up a retina version if they detect a retina resolution image. I tried a couple options but was never entirely satisfied.
Try visiting http://www.sunnymede.net/retina/ in Safari and drag the browser window with your mouse to make it wider or narrower. You should instantly see the images become sharper but the moment you release the mouse it becomes soft again.
I have reported this problem to both Google & Apple and I know Apple at least were taking a look, but nothing has yet been done. FireFox always looks great.
In theory, yes we could provide standard resolution images to non-retina displays, but that’s a step backwards when you can achieve smaller file sizes and sharper images using one set of retina ready images on all screens. Webkit needs to sort this out.
On a side note, I have found that automated tools for downsizing retina ready images tend to deliver poor results. The best method I have found is to save for web in Photoshop at double the intended size on screen, since Photoshop defaults to 72ppi, then preview at 50% and bring down the compression slider until the visual quality starts to suffer.
There are lots of additional factors to consider if performance is an issue, such as the way files are delivered via http or http2 and CloudFlare Pro offers a brilliant algorithm for compressing images without loss of quality, but that is a whole different topic.
Ashley
freewaytalk mailing list
email@hidden
Update your subscriptions at:
All was well until changes were made a few months ago to webkit browsers and suddenly everything was mushy on Safari or Chrome. The CSS script I applied just about fixes it. I’ve not used Sparkle but this problem is browser based, therefore it’s the same for everybody.
In Rapidweaver there are various stacks and scripts that will load a non-retina image initially then serve up a retina version if they detect a retina resolution image. I tried a couple options but was never entirely satisfied.
Sparkle does indeed use state of the art techniques to load the appropriate image, based on the browser used. This is more or less what it boils down to, the mix of HTML, CSS, Javascript and experimentation to nail this is quite a bit of work:
If you’re doing this manually you’ll be tempted to brush it off and say “meh that’s good enough”. In that case… more power to you?
There are lots of additional factors to consider if performance is an issue, such as the way files are delivered via http or http2 and CloudFlare Pro offers a brilliant algorithm for compressing images without loss of quality, but that is a whole different topic.
http2 actually only interleaves requests potentially reducing latency (but since servers aren’t optimized for short jobs it actually ends up increasing latency of smaller resources on average), CloudFlare’s Polish does compress images but most likely nothing you couldn’t do yourself.
Duncan
freewaytalk mailing list
email@hidden
Update your subscriptions at:
My reference to performance and servers was more about the way items can be downloaded concurrently, so a web page that weighs 1mb may not necessarily load any slower than one of 500kb or at least to within a few milliseconds. I also gather some of the traditional best practices for page speed performance are potentially counterproductive for http2.
CloudFlare’s Polish + Jpeg is helpful for those who would struggle to all of this on their own. Many people just save a Jpeg without too much thought and upload it to the server, so Polish might save well over 50% on the image size with the added bonus that images are cached near the user via the CDN. Mirage is another trick they offer for mobile.
I’m quite impressed Sparkle is taking those steps in the background for image handling, assuming the final results are quite good. It’s certainly an advanced approach for built in functionality.
Ashley
freewaytalk mailing list
email@hidden
Update your subscriptions at: