Image Scaling for High-Pixel-Density (i.e. Retina) Displays - Re: -webkit-image-set and <image>

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Image Scaling for High-Pixel-Density (i.e. Retina) Displays - Re: -webkit-image-set and <image>

Tom Penzer
Hi everybody,

I'm seeking feedback for my (hopefully relatively painless in practice  
compared to the alternatives - i.e. -webkit-image-set and html5  
<image>) proposal to solve the problem of 2x-res (double-resolution)  
images with our current HTML and CSS standards for devices with high-
resolution displays, such as 3rd Generation iPads and 4th generation  
iPhones and newer.

We add the following elements:

1) The new 'meta' attribute 'image-scaling' with arguments listed in  
the format {'scaling factor', 'scaling filename key'}, where the  
filename key is the often-standardized string added to the filename  
for 2x assets, i.e. '_2x' (it might even be possible to specify a  
different filename extension for the 2x asset by detecting whether the  
'scaling filename key' string contains a period i.e. 'xxx.xxx'). Sub-
attributes to the 'image-scaling' attribute would include the optional  
boolean (defaulted to 'true') attribute 'assume-present', and  
potentially the optional attribute 'image-scaling-path' for cases  
where sites store their various scaled image assets in different  
directories than their 1x images.

2) A new series of optional attributes to the img tag named after the  
scaling factor, i.e. '2x', '4x', etc., (possible values include  
'true', 'false', a string for the double-res filename key, or 'url()'  
to specify a completely different path for the asset corresponding to  
that scaling factor)

3) A series of new optional CSS properties named after the scaling  
factor, i.e. 'background-image-2x', 'border-image-2x' and 'list-style-
image-2x' (possible values for these include 'true', 'false', a string  
for the double-res filename key, or 'url()').

A simple example usage of these new capabilities would be the following:

<meta image-scaling="{2,'_2x'}" />

The effect of adding this single line to the page would be that a user  
agent that wishes to display double-res images would then attempt to  
access 'filename_2x.ext' whenever it encounters an img tag like '<img  
url=("filename.ext") />', or a CSS property like '.class {background-
image: url("filename.ext");}', '.class {border-image:  
url("filename.ext");}' or '.class {list-style-image:  
url("filename.ext");}'. For all these, in the case that the  
'filename_2x.ext' file does not exist, a second request is made for  
'filename.ext'.

If the bulk of the 2x-resolution images are located in a different  
directory than the 1x assets, the meta tag could be extended as such:

<meta image-scaling="{2,'_2x'}" image-scaling-path="{2,'2x_images/'}" />

Then, any 2x img or css-image assets would be requested from  
'2x_images/filename_2x.ext' instead of 'images/filename.ext'.

If a particular 2x img tag asset or css-image asset has a '@2x' double-
resolution filename key instead of '_2x' for some reason (maybe you're  
integrating with some 3rd party off-site content with a different 2x  
naming convention), you could add a '2x' attribute to its img tag,  
such as '<img 2x="@2x" />', or to its css properties, such as '.class  
{background-image-2x: "@2x";}'.

If a particular 2x-resolution img tag asset or css-image asset is not  
located in the same directory as the 1x asset, or if the filenames and/
or file formats are not identical to the 1x asset, a separate path  
could be specified by doing this: '<img 2x=url("path/to/
[hidden email]") />', or to its css properties by doing: '.class  
{background-image-2x: url("path/to/[hidden email]");}'.

In the case that a majority, but not all img and css-image assets are  
available in 2x resolution, the img assets that lack a 2x version  
would include the a tag such as, '<img 2x=false />, or a css property  
such as '.class{background-image-2x: false;}'.

In the case that a majority, but not all img and css-image assets are  
unavailable in 2x resolution, you would add the 'assume-
present="{2,false}' attribute to the meta 'image-scaling' attribute,  
such as '<meta image-scaling="{2,'_2x'}" assume-present="{2,false}" /
 >', and use the '2x' attribute to flag img assets with a double-
resolution asset available, such as '<img 2x=true />, and the css with  
'.class {background-image-2x: true;}'.

In the case that no double-resolution image assets are available, the  
meta 'image-scaling' attribute can be simply omitted.

By using this approach, we avoid the need to specify the same list of  
filenames varying only by scaling factor filename key for every single  
image asset, which is a bunch of busy work that just seems extremely  
redundant and clumsy to me. We are also able to achieve the same level  
of performance for those willing to put in the extra work to flag  
assets that deviate from the default setting (to minimize requests),  
and we allow the flexibility to be lazy or wrong, and have the user  
agent make two requests in those cases. This solution is also  
completely backwards-compatible with existing browsers.

As a corollary to this, a similar approach could be used to add  
support for different image formats without losing backwards-
compatibility, and again saving many precious developer-years. Imagine  
<meta image-formats="{jpeg2000, '.jp2'}" assume-
present="{jpeg2000,boolean}" />

-Tom Penzer
humble web coding noob


Reply | Threaded
Open this post in threaded view
|

Re: Image Scaling for High-Pixel-Density (i.e. Retina) Displays - Re: -webkit-image-set and <image>

Jason H-3
I think the approach of attacking it from setting a scaling is wrong.
The real approach is to set the final dimensions, and let the software give the appropriate scaling based on the image metadata.

If you want a double-density image, you're just asking for 100x100 to be rendered in 50x50. The image tag already supports this. <IMG HEIGHT=50 WIDTH=50 SRC="100x100.png"/> Far too often it is implied that the display density is identical to the sampling (pixel density) by not including the height and width attributes.

The real challenge as I see it, is having an efficient way of not sending over-sampled data across the wire, unless you mean to. Sending a double density image actually sends 4 times the data as a native resolution image. I would suggest we leave it up to java script to handle the pixel density matching, where it can dynamically assign the assets to the proper size-density, if needed. For the most part pick something not over sampled and let the browser scale it up if need be. A server-component could dynamically render and cache the common sizes of an image. But I don't see a need to change HTML.








From: Tom Penzer <[hidden email]>
To: [hidden email]
Sent: Friday, April 27, 2012 3:47 PM
Subject: Image Scaling for High-Pixel-Density (i.e. Retina) Displays - Re: -webkit-image-set and <image>

Hi everybody,

I'm seeking feedback for my (hopefully relatively painless in practice compared to the alternatives - i.e. -webkit-image-set and html5 <image>) proposal to solve the problem of 2x-res (double-resolution) images with our current HTML and CSS standards for devices with high-resolution displays, such as 3rd Generation iPads and 4th generation iPhones and newer.

We add the following elements:

1) The new 'meta' attribute 'image-scaling' with arguments listed in the format {'scaling factor', 'scaling filename key'}, where the filename key is the often-standardized string added to the filename for 2x assets, i.e. '_2x' (it might even be possible to specify a different filename extension for the 2x asset by detecting whether the 'scaling filename key' string contains a period i.e. 'xxx.xxx'). Sub-attributes to the 'image-scaling' attribute would include the optional boolean (defaulted to 'true') attribute 'assume-present', and potentially the optional attribute 'image-scaling-path' for cases where sites store their various scaled image assets in different directories than their 1x images.

2) A new series of optional attributes to the img tag named after the scaling factor, i.e. '2x', '4x', etc., (possible values include 'true', 'false', a string for the double-res filename key, or 'url()' to specify a completely different path for the asset corresponding to that scaling factor)

3) A series of new optional CSS properties named after the scaling factor, i.e. 'background-image-2x', 'border-image-2x' and 'list-style-image-2x' (possible values for these include 'true', 'false', a string for the double-res filename key, or 'url()').

A simple example usage of these new capabilities would be the following:

<meta image-scaling="{2,'_2x'}" />

The effect of adding this single line to the page would be that a user agent that wishes to display double-res images would then attempt to access 'filename_2x.ext' whenever it encounters an img tag like '<img url=("filename.ext") />', or a CSS property like '.class {background-image: url("filename.ext");}', '.class {border-image: url("filename.ext");}' or '.class {list-style-image: url("filename.ext");}'. For all these, in the case that the 'filename_2x.ext' file does not exist, a second request is made for 'filename.ext'.

If the bulk of the 2x-resolution images are located in a different directory than the 1x assets, the meta tag could be extended as such:

<meta image-scaling="{2,'_2x'}" image-scaling-path="{2,'2x_images/'}" />

Then, any 2x img or css-image assets would be requested from '2x_images/filename_2x.ext' instead of 'images/filename.ext'.

If a particular 2x img tag asset or css-image asset has a '@2x' double-resolution filename key instead of '_2x' for some reason (maybe you're integrating with some 3rd party off-site content with a different 2x naming convention), you could add a '2x' attribute to its img tag, such as '<img 2x="@2x" />', or to its css properties, such as '.class {background-image-2x: "@2x";}'.

If a particular 2x-resolution img tag asset or css-image asset is not located in the same directory as the 1x asset, or if the filenames and/or file formats are not identical to the 1x asset, a separate path could be specified by doing this: '<img 2x=url("path/to/[hidden email]") />', or to its css properties by doing: '.class {background-image-2x: url("path/to/[hidden email]");}'.

In the case that a majority, but not all img and css-image assets are available in 2x resolution, the img assets that lack a 2x version would include the a tag such as, '<img 2x=false />, or a css property such as '.class{background-image-2x: false;}'.

In the case that a majority, but not all img and css-image assets are unavailable in 2x resolution, you would add the 'assume-present="{2,false}' attribute to the meta 'image-scaling' attribute, such as '<meta image-scaling="{2,'_2x'}" assume-present="{2,false}" />', and use the '2x' attribute to flag img assets with a double-resolution asset available, such as '<img 2x=true />, and the css with '.class {background-image-2x: true;}'.

In the case that no double-resolution image assets are available, the meta 'image-scaling' attribute can be simply omitted.

By using this approach, we avoid the need to specify the same list of filenames varying only by scaling factor filename key for every single image asset, which is a bunch of busy work that just seems extremely redundant and clumsy to me. We are also able to achieve the same level of performance for those willing to put in the extra work to flag assets that deviate from the default setting (to minimize requests), and we allow the flexibility to be lazy or wrong, and have the user agent make two requests in those cases. This solution is also completely backwards-compatible with existing browsers.

As a corollary to this, a similar approach could be used to add support for different image formats without losing backwards-compatibility, and again saving many precious developer-years. Imagine <meta image-formats="{jpeg2000, '.jp2'}" assume-present="{jpeg2000,boolean}" />

-Tom Penzer
humble web coding noob




Reply | Threaded
Open this post in threaded view
|

Re: Image Scaling for High-Pixel-Density (i.e. Retina) Displays - Re: -webkit-image-set and <image>

Tom Penzer
The main advantages of doing it this way are:
1) You don't need to specify a different path for every scale of every image if you follow a naming convention.
2) the user agent makes the decision of which asset to request (based on factors such as screen resolution and network quality/value of bandwidth)
3) It's backwards-compatible and degrades gracefully.

-Tom


On Apr 27, 2012, at 1:50 PM, Jason H <[hidden email]> wrote:

I think the approach of attacking it from setting a scaling is wrong.
The real approach is to set the final dimensions, and let the software give the appropriate scaling based on the image metadata.

If you want a double-density image, you're just asking for 100x100 to be rendered in 50x50. The image tag already supports this. <IMG HEIGHT=50 WIDTH=50 SRC="100x100.png"/> Far too often it is implied that the display density is identical to the sampling (pixel density) by not including the height and width attributes.

The real challenge as I see it, is having an efficient way of not sending over-sampled data across the wire, unless you mean to. Sending a double density image actually sends 4 times the data as a native resolution image. I would suggest we leave it up to java script to handle the pixel density matching, where it can dynamically assign the assets to the proper size-density, if needed. For the most part pick something not over sampled and let the browser scale it up if need be. A server-component could dynamically render and cache the common sizes of an image. But I don't see a need to change HTML.








From: Tom Penzer <[hidden email]>
To: [hidden email]
Sent: Friday, April 27, 2012 3:47 PM
Subject: Image Scaling for High-Pixel-Density (i.e. Retina) Displays - Re: -webkit-image-set and <image>

Hi everybody,

I'm seeking feedback for my (hopefully relatively painless in practice compared to the alternatives - i.e. -webkit-image-set and html5 <image>) proposal to solve the problem of 2x-res (double-resolution) images with our current HTML and CSS standards for devices with high-resolution displays, such as 3rd Generation iPads and 4th generation iPhones and newer.

We add the following elements:

1) The new 'meta' attribute 'image-scaling' with arguments listed in the format {'scaling factor', 'scaling filename key'}, where the filename key is the often-standardized string added to the filename for 2x assets, i.e. '_2x' (it might even be possible to specify a different filename extension for the 2x asset by detecting whether the 'scaling filename key' string contains a period i.e. 'xxx.xxx'). Sub-attributes to the 'image-scaling' attribute would include the optional boolean (defaulted to 'true') attribute 'assume-present', and potentially the optional attribute 'image-scaling-path' for cases where sites store their various scaled image assets in different directories than their 1x images.

2) A new series of optional attributes to the img tag named after the scaling factor, i.e. '2x', '4x', etc., (possible values include 'true', 'false', a string for the double-res filename key, or 'url()' to specify a completely different path for the asset corresponding to that scaling factor)

3) A series of new optional CSS properties named after the scaling factor, i.e. 'background-image-2x', 'border-image-2x' and 'list-style-image-2x' (possible values for these include 'true', 'false', a string for the double-res filename key, or 'url()').

A simple example usage of these new capabilities would be the following:

<meta image-scaling="{2,'_2x'}" />

The effect of adding this single line to the page would be that a user agent that wishes to display double-res images would then attempt to access 'filename_2x.ext' whenever it encounters an img tag like '<img url=("filename.ext") />', or a CSS property like '.class {background-image: url("filename.ext");}', '.class {border-image: url("filename.ext");}' or '.class {list-style-image: url("filename.ext");}'. For all these, in the case that the 'filename_2x.ext' file does not exist, a second request is made for 'filename.ext'.

If the bulk of the 2x-resolution images are located in a different directory than the 1x assets, the meta tag could be extended as such:

<meta image-scaling="{2,'_2x'}" image-scaling-path="{2,'2x_images/'}" />

Then, any 2x img or css-image assets would be requested from '2x_images/filename_2x.ext' instead of 'images/filename.ext'.

If a particular 2x img tag asset or css-image asset has a '@2x' double-resolution filename key instead of '_2x' for some reason (maybe you're integrating with some 3rd party off-site content with a different 2x naming convention), you could add a '2x' attribute to its img tag, such as '<img 2x="@2x" />', or to its css properties, such as '.class {background-image-2x: "@2x";}'.

If a particular 2x-resolution img tag asset or css-image asset is not located in the same directory as the 1x asset, or if the filenames and/or file formats are not identical to the 1x asset, a separate path could be specified by doing this: '<img 2x=url("path/to/[hidden email]") />', or to its css properties by doing: '.class {background-image-2x: url("path/to/[hidden email]");}'.

In the case that a majority, but not all img and css-image assets are available in 2x resolution, the img assets that lack a 2x version would include the a tag such as, '<img 2x=false />, or a css property such as '.class{background-image-2x: false;}'.

In the case that a majority, but not all img and css-image assets are unavailable in 2x resolution, you would add the 'assume-present="{2,false}' attribute to the meta 'image-scaling' attribute, such as '<meta image-scaling="{2,'_2x'}" assume-present="{2,false}" />', and use the '2x' attribute to flag img assets with a double-resolution asset available, such as '<img 2x=true />, and the css with '.class {background-image-2x: true;}'.

In the case that no double-resolution image assets are available, the meta 'image-scaling' attribute can be simply omitted.

By using this approach, we avoid the need to specify the same list of filenames varying only by scaling factor filename key for every single image asset, which is a bunch of busy work that just seems extremely redundant and clumsy to me. We are also able to achieve the same level of performance for those willing to put in the extra work to flag assets that deviate from the default setting (to minimize requests), and we allow the flexibility to be lazy or wrong, and have the user agent make two requests in those cases. This solution is also completely backwards-compatible with existing browsers.

As a corollary to this, a similar approach could be used to add support for different image formats without losing backwards-compatibility, and again saving many precious developer-years. Imagine <meta image-formats="{jpeg2000, '.jp2'}" assume-present="{jpeg2000,boolean}" />

-Tom Penzer
humble web coding noob




Reply | Threaded
Open this post in threaded view
|

Re: Image Scaling for High-Pixel-Density (i.e. Retina) Displays - Re: -webkit-image-set and <image>

Jason H-3
1. To my knowledge w3c has never specified file naming conventions. Maybe extensions, as they are related to mime types, but this would be a new function of filename itself that would affect rendeing quality. What about images that already exist out there that are named as such? No, we should not use the filename for metadata.
2. The user agent can use Javascript to do this already.
3. The JS method is backwards compatible and requires no changes. To say it degrades gracefully, I think is the wrong direction. Initial sources should be low-res, then upgrade accordingly.


From: Tom Penzer <[hidden email]>
To: Jason H <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Sent: Friday, April 27, 2012 4:57 PM
Subject: Re: Image Scaling for High-Pixel-Density (i.e. Retina) Displays - Re: -webkit-image-set and <image>

The main advantages of doing it this way are:
1) You don't need to specify a different path for every scale of every image if you follow a naming convention.
2) the user agent makes the decision of which asset to request (based on factors such as screen resolution and network quality/value of bandwidth)
3) It's backwards-compatible and degrades gracefully.

-Tom


On Apr 27, 2012, at 1:50 PM, Jason H <[hidden email]> wrote:

I think the approach of attacking it from setting a scaling is wrong.
The real approach is to set the final dimensions, and let the software give the appropriate scaling based on the image metadata.

If you want a double-density image, you're just asking for 100x100 to be rendered in 50x50. The image tag already supports this. <IMG HEIGHT=50 WIDTH=50 SRC="100x100.png"/> Far too often it is implied that the display density is identical to the sampling (pixel density) by not including the height and width attributes.

The real challenge as I see it, is having an efficient way of not sending over-sampled data across the wire, unless you mean to. Sending a double density image actually sends 4 times the data as a native resolution image. I would suggest we leave it up to java script to handle the pixel density matching, where it can dynamically assign the assets to the proper size-density, if needed. For the most part pick something not over sampled and let the browser scale it up if need be. A server-component could dynamically render and cache the common sizes of an image. But I don't see a need to change HTML.








From: Tom Penzer <[hidden email]>
To: [hidden email]
Sent: Friday, April 27, 2012 3:47 PM
Subject: Image Scaling for High-Pixel-Density (i.e. Retina) Displays - Re: -webkit-image-set and <image>

Hi everybody,

I'm seeking feedback for my (hopefully relatively painless in practice compared to the alternatives - i.e. -webkit-image-set and html5 <image>) proposal to solve the problem of 2x-res (double-resolution) images with our current HTML and CSS standards for devices with high-resolution displays, such as 3rd Generation iPads and 4th generation iPhones and newer.

We add the following elements:

1) The new 'meta' attribute 'image-scaling' with arguments listed in the format {'scaling factor', 'scaling filename key'}, where the filename key is the often-standardized string added to the filename for 2x assets, i.e. '_2x' (it might even be possible to specify a different filename extension for the 2x asset by detecting whether the 'scaling filename key' string contains a period i.e. 'xxx.xxx'). Sub-attributes to the 'image-scaling' attribute would include the optional boolean (defaulted to 'true') attribute 'assume-present', and potentially the optional attribute 'image-scaling-path' for cases where sites store their various scaled image assets in different directories than their 1x images.

2) A new series of optional attributes to the img tag named after the scaling factor, i.e. '2x', '4x', etc., (possible values include 'true', 'false', a string for the double-res filename key, or 'url()' to specify a completely different path for the asset corresponding to that scaling factor)

3) A series of new optional CSS properties named after the scaling factor, i.e. 'background-image-2x', 'border-image-2x' and 'list-style-image-2x' (possible values for these include 'true', 'false', a string for the double-res filename key, or 'url()').

A simple example usage of these new capabilities would be the following:

<meta image-scaling="{2,'_2x'}" />

The effect of adding this single line to the page would be that a user agent that wishes to display double-res images would then attempt to access 'filename_2x.ext' whenever it encounters an img tag like '<img url=("filename.ext") />', or a CSS property like '.class {background-image: url("filename.ext");}', '.class {border-image: url("filename.ext");}' or '.class {list-style-image: url("filename.ext");}'. For all these, in the case that the 'filename_2x.ext' file does not exist, a second request is made for 'filename.ext'.

If the bulk of the 2x-resolution images are located in a different directory than the 1x assets, the meta tag could be extended as such:

<meta image-scaling="{2,'_2x'}" image-scaling-path="{2,'2x_images/'}" />

Then, any 2x img or css-image assets would be requested from '2x_images/filename_2x.ext' instead of 'images/filename.ext'.

If a particular 2x img tag asset or css-image asset has a '@2x' double-resolution filename key instead of '_2x' for some reason (maybe you're integrating with some 3rd party off-site content with a different 2x naming convention), you could add a '2x' attribute to its img tag, such as '<img 2x="@2x" />', or to its css properties, such as '.class {background-image-2x: "@2x";}'.

If a particular 2x-resolution img tag asset or css-image asset is not located in the same directory as the 1x asset, or if the filenames and/or file formats are not identical to the 1x asset, a separate path could be specified by doing this: '<img 2x=url("path/to/[hidden email]") />', or to its css properties by doing: '.class {background-image-2x: url("path/to/[hidden email]");}'.

In the case that a majority, but not all img and css-image assets are available in 2x resolution, the img assets that lack a 2x version would include the a tag such as, '<img 2x=false />, or a css property such as '.class{background-image-2x: false;}'.

In the case that a majority, but not all img and css-image assets are unavailable in 2x resolution, you would add the 'assume-present="{2,false}' attribute to the meta 'image-scaling' attribute, such as '<meta image-scaling="{2,'_2x'}" assume-present="{2,false}" />', and use the '2x' attribute to flag img assets with a double-resolution asset available, such as '<img 2x=true />, and the css with '.class {background-image-2x: true;}'.

In the case that no double-resolution image assets are available, the meta 'image-scaling' attribute can be simply omitted.

By using this approach, we avoid the need to specify the same list of filenames varying only by scaling factor filename key for every single image asset, which is a bunch of busy work that just seems extremely redundant and clumsy to me. We are also able to achieve the same level of performance for those willing to put in the extra work to flag assets that deviate from the default setting (to minimize requests), and we allow the flexibility to be lazy or wrong, and have the user agent make two requests in those cases. This solution is also completely backwards-compatible with existing browsers.

As a corollary to this, a similar approach could be used to add support for different image formats without losing backwards-compatibility, and again saving many precious developer-years. Imagine <meta image-formats="{jpeg2000, '.jp2'}" assume-present="{jpeg2000,boolean}" />

-Tom Penzer
humble web coding noob






Reply | Threaded
Open this post in threaded view
|

Re: Image Scaling for High-Pixel-Density (i.e. Retina) Displays - Re: -webkit-image-set and <image>

Tom Penzer
On Apr 27, 2012, at 2:49 PM, Jason H <[hidden email]> wrote:

1. To my knowledge w3c has never specified file naming conventions. Maybe extensions, as they are related to mime types, but this would be a new function of filename itself that would affect rendeing quality. What about images that already exist out there that are named as such? No, we should not use the filename for metadata.

But it's what humans are already using, and it allows for a powerful and flexible system. Perhaps we should start using the file name and filename extension as  meta data, and not make our lives harder than they need to be.



2. The user agent can use Javascript to do this already.

How can this be standardized, where the various browsers make an informed decision which image scale to request?


3. The JS method is backwards compatible and requires no changes. To say it degrades gracefully, I think is the wrong direction. Initial sources should be low-res, then upgrade accordingly.

That's how this works. You have the following code:
<meta image-scaling={2,"_2x"} />
<img src="path/to/filename.ext" />

And then the browser loads the 2x asset at 'path/to/filename_2x.ext' if it understands the image-scaling meta attribute, or just the default 1x asset at 'path/to/filename.ext/' otherwise.




From: Tom Penzer <[hidden email]>
To: Jason H <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Sent: Friday, April 27, 2012 4:57 PM
Subject: Re: Image Scaling for High-Pixel-Density (i.e. Retina) Displays - Re: -webkit-image-set and <image>

The main advantages of doing it this way are:
1) You don't need to specify a different path for every scale of every image if you follow a naming convention.
2) the user agent makes the decision of which asset to request (based on factors such as screen resolution and network quality/value of bandwidth)
3) It's backwards-compatible and degrades gracefully.

-Tom


On Apr 27, 2012, at 1:50 PM, Jason H <[hidden email]> wrote:

I think the approach of attacking it from setting a scaling is wrong.
The real approach is to set the final dimensions, and let the software give the appropriate scaling based on the image metadata.

If you want a double-density image, you're just asking for 100x100 to be rendered in 50x50. The image tag already supports this. <IMG HEIGHT=50 WIDTH=50 SRC="100x100.png"/> Far too often it is implied that the display density is identical to the sampling (pixel density) by not including the height and width attributes.

The real challenge as I see it, is having an efficient way of not sending over-sampled data across the wire, unless you mean to. Sending a double density image actually sends 4 times the data as a native resolution image. I would suggest we leave it up to java script to handle the pixel density matching, where it can dynamically assign the assets to the proper size-density, if needed. For the most part pick something not over sampled and let the browser scale it up if need be. A server-component could dynamically render and cache the common sizes of an image. But I don't see a need to change HTML.








From: Tom Penzer <[hidden email]>
To: [hidden email]
Sent: Friday, April 27, 2012 3:47 PM
Subject: Image Scaling for High-Pixel-Density (i.e. Retina) Displays - Re: -webkit-image-set and <image>

Hi everybody,

I'm seeking feedback for my (hopefully relatively painless in practice compared to the alternatives - i.e. -webkit-image-set and html5 <image>) proposal to solve the problem of 2x-res (double-resolution) images with our current HTML and CSS standards for devices with high-resolution displays, such as 3rd Generation iPads and 4th generation iPhones and newer.

We add the following elements:

1) The new 'meta' attribute 'image-scaling' with arguments listed in the format {'scaling factor', 'scaling filename key'}, where the filename key is the often-standardized string added to the filename for 2x assets, i.e. '_2x' (it might even be possible to specify a different filename extension for the 2x asset by detecting whether the 'scaling filename key' string contains a period i.e. 'xxx.xxx'). Sub-attributes to the 'image-scaling' attribute would include the optional boolean (defaulted to 'true') attribute 'assume-present', and potentially the optional attribute 'image-scaling-path' for cases where sites store their various scaled image assets in different directories than their 1x images.

2) A new series of optional attributes to the img tag named after the scaling factor, i.e. '2x', '4x', etc., (possible values include 'true', 'false', a string for the double-res filename key, or 'url()' to specify a completely different path for the asset corresponding to that scaling factor)

3) A series of new optional CSS properties named after the scaling factor, i.e. 'background-image-2x', 'border-image-2x' and 'list-style-image-2x' (possible values for these include 'true', 'false', a string for the double-res filename key, or 'url()').

A simple example usage of these new capabilities would be the following:

<meta image-scaling="{2,'_2x'}" />

The effect of adding this single line to the page would be that a user agent that wishes to display double-res images would then attempt to access 'filename_2x.ext' whenever it encounters an img tag like '<img url=("filename.ext") />', or a CSS property like '.class {background-image: url("filename.ext");}', '.class {border-image: url("filename.ext");}' or '.class {list-style-image: url("filename.ext");}'. For all these, in the case that the 'filename_2x.ext' file does not exist, a second request is made for 'filename.ext'.

If the bulk of the 2x-resolution images are located in a different directory than the 1x assets, the meta tag could be extended as such:

<meta image-scaling="{2,'_2x'}" image-scaling-path="{2,'2x_images/'}" />

Then, any 2x img or css-image assets would be requested from '2x_images/filename_2x.ext' instead of 'images/filename.ext'.

If a particular 2x img tag asset or css-image asset has a '@2x' double-resolution filename key instead of '_2x' for some reason (maybe you're integrating with some 3rd party off-site content with a different 2x naming convention), you could add a '2x' attribute to its img tag, such as '<img 2x="@2x" />', or to its css properties, such as '.class {background-image-2x: "@2x";}'.

If a particular 2x-resolution img tag asset or css-image asset is not located in the same directory as the 1x asset, or if the filenames and/or file formats are not identical to the 1x asset, a separate path could be specified by doing this: '<img 2x=url("path/to/[hidden email]") />', or to its css properties by doing: '.class {background-image-2x: url("path/to/[hidden email]");}'.

In the case that a majority, but not all img and css-image assets are available in 2x resolution, the img assets that lack a 2x version would include the a tag such as, '<img 2x=false />, or a css property such as '.class{background-image-2x: false;}'.

In the case that a majority, but not all img and css-image assets are unavailable in 2x resolution, you would add the 'assume-present="{2,false}' attribute to the meta 'image-scaling' attribute, such as '<meta image-scaling="{2,'_2x'}" assume-present="{2,false}" />', and use the '2x' attribute to flag img assets with a double-resolution asset available, such as '<img 2x=true />, and the css with '.class {background-image-2x: true;}'.

In the case that no double-resolution image assets are available, the meta 'image-scaling' attribute can be simply omitted.

By using this approach, we avoid the need to specify the same list of filenames varying only by scaling factor filename key for every single image asset, which is a bunch of busy work that just seems extremely redundant and clumsy to me. We are also able to achieve the same level of performance for those willing to put in the extra work to flag assets that deviate from the default setting (to minimize requests), and we allow the flexibility to be lazy or wrong, and have the user agent make two requests in those cases. This solution is also completely backwards-compatible with existing browsers.

As a corollary to this, a similar approach could be used to add support for different image formats without losing backwards-compatibility, and again saving many precious developer-years. Imagine <meta image-formats="{jpeg2000, '.jp2'}" assume-present="{jpeg2000,boolean}" />

-Tom Penzer
humble web coding noob






Reply | Threaded
Open this post in threaded view
|

Re: Image Scaling for High-Pixel-Density (i.e. Retina) Displays - Re: -webkit-image-set and <image>

Jason H-3
Oh, I see what you're trying to do. Why can't you just do:
<IMG SRC="javascript:assetForAgent(navigator.userAgent, 'asset.png')" />

Where assetForAgent is a javascript function to apply whatever function to the asset filename you want?<html>
<body onload="setImages()">

<script language="javascript">

function setImages()
{
    imageForAgent(navigator.userAgent, 'asset', 'imag0902.jpg');
}

function imageForAgent(ua, id, image)
{
var e = document.getElementById(id);
e.src = image; // do some function on the name here based on ua
}
</script>

<IMG ID="asset" height="100" width="100"/>

</body>
</html>

I'm using the UA here because I don't know how to get the DPI otherwise.




From: Tom Penzer <[hidden email]>
To: Jason H <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Sent: Friday, April 27, 2012 6:25 PM
Subject: Re: Image Scaling for High-Pixel-Density (i.e. Retina) Displays - Re: -webkit-image-set and <image>

On Apr 27, 2012, at 2:49 PM, Jason H <[hidden email]> wrote:

1. To my knowledge w3c has never specified file naming conventions. Maybe extensions, as they are related to mime types, but this would be a new function of filename itself that would affect rendeing quality. What about images that already exist out there that are named as such? No, we should not use the filename for metadata.

But it's what humans are already using, and it allows for a powerful and flexible system. Perhaps we should start using the file name and filename extension as  meta data, and not make our lives harder than they need to be.



2. The user agent can use Javascript to do this already.

How can this be standardized, where the various browsers make an informed decision which image scale to request?


3. The JS method is backwards compatible and requires no changes. To say it degrades gracefully, I think is the wrong direction. Initial sources should be low-res, then upgrade accordingly.

That's how this works. You have the following code:
<meta image-scaling={2,"_2x"} />
<img src="path/to/filename.ext" />

And then the browser loads the 2x asset at 'path/to/filename_2x.ext' if it understands the image-scaling meta attribute, or just the default 1x asset at 'path/to/filename.ext/' otherwise.




From: Tom Penzer <[hidden email]>
To: Jason H <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Sent: Friday, April 27, 2012 4:57 PM
Subject: Re: Image Scaling for High-Pixel-Density (i.e. Retina) Displays - Re: -webkit-image-set and <image>

The main advantages of doing it this way are:
1) You don't need to specify a different path for every scale of every image if you follow a naming convention.
2) the user agent makes the decision of which asset to request (based on factors such as screen resolution and network quality/value of bandwidth)
3) It's backwards-compatible and degrades gracefully.

-Tom


On Apr 27, 2012, at 1:50 PM, Jason H <[hidden email]> wrote:

I think the approach of attacking it from setting a scaling is wrong.
The real approach is to set the final dimensions, and let the software give the appropriate scaling based on the image metadata.

If you want a double-density image, you're just asking for 100x100 to be rendered in 50x50. The image tag already supports this. <IMG HEIGHT=50 WIDTH=50 SRC="100x100.png"/> Far too often it is implied that the display density is identical to the sampling (pixel density) by not including the height and width attributes.

The real challenge as I see it, is having an efficient way of not sending over-sampled data across the wire, unless you mean to. Sending a double density image actually sends 4 times the data as a native resolution image. I would suggest we leave it up to java script to handle the pixel density matching, where it can dynamically assign the assets to the proper size-density, if needed. For the most part pick something not over sampled and let the browser scale it up if need be. A server-component could dynamically render and cache the common sizes of an image. But I don't see a need to change HTML.








From: Tom Penzer <[hidden email]>
To: [hidden email]
Sent: Friday, April 27, 2012 3:47 PM
Subject: Image Scaling for High-Pixel-Density (i.e. Retina) Displays - Re: -webkit-image-set and <image>

Hi everybody,

I'm seeking feedback for my (hopefully relatively painless in practice compared to the alternatives - i.e. -webkit-image-set and html5 <image>) proposal to solve the problem of 2x-res (double-resolution) images with our current HTML and CSS standards for devices with high-resolution displays, such as 3rd Generation iPads and 4th generation iPhones and newer.

We add the following elements:

1) The new 'meta' attribute 'image-scaling' with arguments listed in the format {'scaling factor', 'scaling filename key'}, where the filename key is the often-standardized string added to the filename for 2x assets, i.e. '_2x' (it might even be possible to specify a different filename extension for the 2x asset by detecting whether the 'scaling filename key' string contains a period i.e. 'xxx.xxx'). Sub-attributes to the 'image-scaling' attribute would include the optional boolean (defaulted to 'true') attribute 'assume-present', and potentially the optional attribute 'image-scaling-path' for cases where sites store their various scaled image assets in different directories than their 1x images.

2) A new series of optional attributes to the img tag named after the scaling factor, i.e. '2x', '4x', etc., (possible values include 'true', 'false', a string for the double-res filename key, or 'url()' to specify a completely different path for the asset corresponding to that scaling factor)

3) A series of new optional CSS properties named after the scaling factor, i.e. 'background-image-2x', 'border-image-2x' and 'list-style-image-2x' (possible values for these include 'true', 'false', a string for the double-res filename key, or 'url()').

A simple example usage of these new capabilities would be the following:

<meta image-scaling="{2,'_2x'}" />

The effect of adding this single line to the page would be that a user agent that wishes to display double-res images would then attempt to access 'filename_2x.ext' whenever it encounters an img tag like '<img url=("filename.ext") />', or a CSS property like '.class {background-image: url("filename.ext");}', '.class {border-image: url("filename.ext");}' or '.class {list-style-image: url("filename.ext");}'. For all these, in the case that the 'filename_2x.ext' file does not exist, a second request is made for 'filename.ext'.

If the bulk of the 2x-resolution images are located in a different directory than the 1x assets, the meta tag could be extended as such:

<meta image-scaling="{2,'_2x'}" image-scaling-path="{2,'2x_images/'}" />

Then, any 2x img or css-image assets would be requested from '2x_images/filename_2x.ext' instead of 'images/filename.ext'.

If a particular 2x img tag asset or css-image asset has a '@2x' double-resolution filename key instead of '_2x' for some reason (maybe you're integrating with some 3rd party off-site content with a different 2x naming convention), you could add a '2x' attribute to its img tag, such as '<img 2x="@2x" />', or to its css properties, such as '.class {background-image-2x: "@2x";}'.

If a particular 2x-resolution img tag asset or css-image asset is not located in the same directory as the 1x asset, or if the filenames and/or file formats are not identical to the 1x asset, a separate path could be specified by doing this: '<img 2x=url("path/to/[hidden email]") />', or to its css properties by doing: '.class {background-image-2x: url("path/to/[hidden email]");}'.

In the case that a majority, but not all img and css-image assets are available in 2x resolution, the img assets that lack a 2x version would include the a tag such as, '<img 2x=false />, or a css property such as '.class{background-image-2x: false;}'.

In the case that a majority, but not all img and css-image assets are unavailable in 2x resolution, you would add the 'assume-present="{2,false}' attribute to the meta 'image-scaling' attribute, such as '<meta image-scaling="{2,'_2x'}" assume-present="{2,false}" />', and use the '2x' attribute to flag img assets with a double-resolution asset available, such as '<img 2x=true />, and the css with '.class {background-image-2x: true;}'.

In the case that no double-resolution image assets are available, the meta 'image-scaling' attribute can be simply omitted.

By using this approach, we avoid the need to specify the same list of filenames varying only by scaling factor filename key for every single image asset, which is a bunch of busy work that just seems extremely redundant and clumsy to me. We are also able to achieve the same level of performance for those willing to put in the extra work to flag assets that deviate from the default setting (to minimize requests), and we allow the flexibility to be lazy or wrong, and have the user agent make two requests in those cases. This solution is also completely backwards-compatible with existing browsers.

As a corollary to this, a similar approach could be used to add support for different image formats without losing backwards-compatibility, and again saving many precious developer-years. Imagine <meta image-formats="{jpeg2000, '.jp2'}" assume-present="{jpeg2000,boolean}" />

-Tom Penzer
humble web coding noob








Reply | Threaded
Open this post in threaded view
|

Re: Image Scaling for High-Pixel-Density (i.e. Retina) Displays - Re: -webkit-image-set and <image>

Tom Penzer
I still say the approach you suggest has two significant drawbacks:

1) You require the use of JavaScript; you patch around the HTML and CSS instead of fixing it, and raise the barrier to entry for novices.

2) That's still having your routine determine which asset is appropriate for that user agent string rather than having the user agent (the browser executable operating on behalf of the user, not the string) make that determination. That is not the right way to go about it.



On Apr 27, 2012, at 4:41 PM, Jason H <[hidden email]> wrote:

Oh, I see what you're trying to do. Why can't you just do:
<IMG SRC="javascript:assetForAgent(navigator.userAgent, 'asset.png')" />

Where assetForAgent is a javascript function to apply whatever function to the asset filename you want?<html>
<body onload="setImages()">

<script language="javascript">

function setImages()
{
    imageForAgent(navigator.userAgent, 'asset', 'imag0902.jpg');
}

function imageForAgent(ua, id, image)
{
var e = document.getElementById(id);
e.src = image; // do some function on the name here based on ua
}
</script>

<IMG ID="asset" height="100" width="100"/>

</body>
</html>

I'm using the UA here because I don't know how to get the DPI otherwise.




From: Tom Penzer <[hidden email]>
To: Jason H <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Sent: Friday, April 27, 2012 6:25 PM
Subject: Re: Image Scaling for High-Pixel-Density (i.e. Retina) Displays - Re: -webkit-image-set and <image>

On Apr 27, 2012, at 2:49 PM, Jason H <[hidden email]> wrote:

1. To my knowledge w3c has never specified file naming conventions. Maybe extensions, as they are related to mime types, but this would be a new function of filename itself that would affect rendeing quality. What about images that already exist out there that are named as such? No, we should not use the filename for metadata.

But it's what humans are already using, and it allows for a powerful and flexible system. Perhaps we should start using the file name and filename extension as  meta data, and not make our lives harder than they need to be.



2. The user agent can use Javascript to do this already.

How can this be standardized, where the various browsers make an informed decision which image scale to request?


3. The JS method is backwards compatible and requires no changes. To say it degrades gracefully, I think is the wrong direction. Initial sources should be low-res, then upgrade accordingly.

That's how this works. You have the following code:
<meta image-scaling={2,"_2x"} />
<img src="path/to/filename.ext" />

And then the browser loads the 2x asset at 'path/to/filename_2x.ext' if it understands the image-scaling meta attribute, or just the default 1x asset at 'path/to/filename.ext/' otherwise.




From: Tom Penzer <[hidden email]>
To: Jason H <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Sent: Friday, April 27, 2012 4:57 PM
Subject: Re: Image Scaling for High-Pixel-Density (i.e. Retina) Displays - Re: -webkit-image-set and <image>

The main advantages of doing it this way are:
1) You don't need to specify a different path for every scale of every image if you follow a naming convention.
2) the user agent makes the decision of which asset to request (based on factors such as screen resolution and network quality/value of bandwidth)
3) It's backwards-compatible and degrades gracefully.

-Tom


On Apr 27, 2012, at 1:50 PM, Jason H <[hidden email]> wrote:

I think the approach of attacking it from setting a scaling is wrong.
The real approach is to set the final dimensions, and let the software give the appropriate scaling based on the image metadata.

If you want a double-density image, you're just asking for 100x100 to be rendered in 50x50. The image tag already supports this. <IMG HEIGHT=50 WIDTH=50 SRC="100x100.png"/> Far too often it is implied that the display density is identical to the sampling (pixel density) by not including the height and width attributes.

The real challenge as I see it, is having an efficient way of not sending over-sampled data across the wire, unless you mean to. Sending a double density image actually sends 4 times the data as a native resolution image. I would suggest we leave it up to java script to handle the pixel density matching, where it can dynamically assign the assets to the proper size-density, if needed. For the most part pick something not over sampled and let the browser scale it up if need be. A server-component could dynamically render and cache the common sizes of an image. But I don't see a need to change HTML.








From: Tom Penzer <[hidden email]>
To: [hidden email]
Sent: Friday, April 27, 2012 3:47 PM
Subject: Image Scaling for High-Pixel-Density (i.e. Retina) Displays - Re: -webkit-image-set and <image>

Hi everybody,

I'm seeking feedback for my (hopefully relatively painless in practice compared to the alternatives - i.e. -webkit-image-set and html5 <image>) proposal to solve the problem of 2x-res (double-resolution) images with our current HTML and CSS standards for devices with high-resolution displays, such as 3rd Generation iPads and 4th generation iPhones and newer.

We add the following elements:

1) The new 'meta' attribute 'image-scaling' with arguments listed in the format {'scaling factor', 'scaling filename key'}, where the filename key is the often-standardized string added to the filename for 2x assets, i.e. '_2x' (it might even be possible to specify a different filename extension for the 2x asset by detecting whether the 'scaling filename key' string contains a period i.e. 'xxx.xxx'). Sub-attributes to the 'image-scaling' attribute would include the optional boolean (defaulted to 'true') attribute 'assume-present', and potentially the optional attribute 'image-scaling-path' for cases where sites store their various scaled image assets in different directories than their 1x images.

2) A new series of optional attributes to the img tag named after the scaling factor, i.e. '2x', '4x', etc., (possible values include 'true', 'false', a string for the double-res filename key, or 'url()' to specify a completely different path for the asset corresponding to that scaling factor)

3) A series of new optional CSS properties named after the scaling factor, i.e. 'background-image-2x', 'border-image-2x' and 'list-style-image-2x' (possible values for these include 'true', 'false', a string for the double-res filename key, or 'url()').

A simple example usage of these new capabilities would be the following:

<meta image-scaling="{2,'_2x'}" />

The effect of adding this single line to the page would be that a user agent that wishes to display double-res images would then attempt to access 'filename_2x.ext' whenever it encounters an img tag like '<img url=("filename.ext") />', or a CSS property like '.class {background-image: url("filename.ext");}', '.class {border-image: url("filename.ext");}' or '.class {list-style-image: url("filename.ext");}'. For all these, in the case that the 'filename_2x.ext' file does not exist, a second request is made for 'filename.ext'.

If the bulk of the 2x-resolution images are located in a different directory than the 1x assets, the meta tag could be extended as such:

<meta image-scaling="{2,'_2x'}" image-scaling-path="{2,'2x_images/'}" />

Then, any 2x img or css-image assets would be requested from '2x_images/filename_2x.ext' instead of 'images/filename.ext'.

If a particular 2x img tag asset or css-image asset has a '@2x' double-resolution filename key instead of '_2x' for some reason (maybe you're integrating with some 3rd party off-site content with a different 2x naming convention), you could add a '2x' attribute to its img tag, such as '<img 2x="@2x" />', or to its css properties, such as '.class {background-image-2x: "@2x";}'.

If a particular 2x-resolution img tag asset or css-image asset is not located in the same directory as the 1x asset, or if the filenames and/or file formats are not identical to the 1x asset, a separate path could be specified by doing this: '<img 2x=url("path/to/[hidden email]") />', or to its css properties by doing: '.class {background-image-2x: url("path/to/[hidden email]");}'.

In the case that a majority, but not all img and css-image assets are available in 2x resolution, the img assets that lack a 2x version would include the a tag such as, '<img 2x=false />, or a css property such as '.class{background-image-2x: false;}'.

In the case that a majority, but not all img and css-image assets are unavailable in 2x resolution, you would add the 'assume-present="{2,false}' attribute to the meta 'image-scaling' attribute, such as '<meta image-scaling="{2,'_2x'}" assume-present="{2,false}" />', and use the '2x' attribute to flag img assets with a double-resolution asset available, such as '<img 2x=true />, and the css with '.class {background-image-2x: true;}'.

In the case that no double-resolution image assets are available, the meta 'image-scaling' attribute can be simply omitted.

By using this approach, we avoid the need to specify the same list of filenames varying only by scaling factor filename key for every single image asset, which is a bunch of busy work that just seems extremely redundant and clumsy to me. We are also able to achieve the same level of performance for those willing to put in the extra work to flag assets that deviate from the default setting (to minimize requests), and we allow the flexibility to be lazy or wrong, and have the user agent make two requests in those cases. This solution is also completely backwards-compatible with existing browsers.

As a corollary to this, a similar approach could be used to add support for different image formats without losing backwards-compatibility, and again saving many precious developer-years. Imagine <meta image-formats="{jpeg2000, '.jp2'}" assume-present="{jpeg2000,boolean}" />

-Tom Penzer
humble web coding noob








Reply | Threaded
Open this post in threaded view
|

Re: Image Scaling for High-Pixel-Density (i.e. Retina) Displays - Re: -webkit-image-set and <image>

Arthur Clifford
In reply to this post by Jason H-3
Wouldn't it be better if the user agent sent back pixels-per-inch or some other measure of bit-density information along with the User-agent metadata and then server-side scripting could be adapted to return imagery based on the user agent.

In fact if you used a server-side script, say getmedia.php, for the src of your images you could currently check the user agent data and figure out if it is an iphone/android/whatever and choose the version of the requested asset to return. You would have full control in getmedia.php over detecting the mime type of the requested asset and depending how you store the asset could determine whether any dynamic resampling of the asset is required; or at least choose a high vs low-res version. including additional parameters on the url like getmedia.php?&res=low or getmedia.php?&res=hi or &res=4x or whatever would allow an explicit resolution to be requested.

This just seems to me to be more of a server-side rather than client side thing; and I don't necessarily think that all servers should be expected to be media servers. If pixel-density is not currently User-Agent provided header/metadata, then I think that would be a better request. If one were to develop a server-side library for handling the user-agent metadata with pixel density and do light-wieght media serving with support for resolution specific settings, then those who want that functionality could use such a library and those who could care less could elect not to worry about it. In fact I would be very surprised if somebody hasn't created such a library already.

Art C

On Apr 27, 2012, at 2:49 PM, Jason H wrote:

1. To my knowledge w3c has never specified file naming conventions. Maybe extensions, as they are related to mime types, but this would be a new function of filename itself that would affect rendeing quality. What about images that already exist out there that are named as such? No, we should not use the filename for metadata.
2. The user agent can use Javascript to do this already.
3. The JS method is backwards compatible and requires no changes. To say it degrades gracefully, I think is the wrong direction. Initial sources should be low-res, then upgrade accordingly.


From: Tom Penzer <[hidden email]>
To: Jason H <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Sent: Friday, April 27, 2012 4:57 PM
Subject: Re: Image Scaling for High-Pixel-Density (i.e. Retina) Displays - Re: -webkit-image-set and <image>

The main advantages of doing it this way are:
1) You don't need to specify a different path for every scale of every image if you follow a naming convention.
2) the user agent makes the decision of which asset to request (based on factors such as screen resolution and network quality/value of bandwidth)
3) It's backwards-compatible and degrades gracefully.

-Tom


On Apr 27, 2012, at 1:50 PM, Jason H <[hidden email]> wrote:

I think the approach of attacking it from setting a scaling is wrong.
The real approach is to set the final dimensions, and let the software give the appropriate scaling based on the image metadata.

If you want a double-density image, you're just asking for 100x100 to be rendered in 50x50. The image tag already supports this. <IMG HEIGHT=50 WIDTH=50 SRC="100x100.png"/> Far too often it is implied that the display density is identical to the sampling (pixel density) by not including the height and width attributes.

The real challenge as I see it, is having an efficient way of not sending over-sampled data across the wire, unless you mean to. Sending a double density image actually sends 4 times the data as a native resolution image. I would suggest we leave it up to java script to handle the pixel density matching, where it can dynamically assign the assets to the proper size-density, if needed. For the most part pick something not over sampled and let the browser scale it up if need be. A server-component could dynamically render and cache the common sizes of an image. But I don't see a need to change HTML.








From: Tom Penzer <[hidden email]>
To: [hidden email]
Sent: Friday, April 27, 2012 3:47 PM
Subject: Image Scaling for High-Pixel-Density (i.e. Retina) Displays - Re: -webkit-image-set and <image>

Hi everybody,

I'm seeking feedback for my (hopefully relatively painless in practice compared to the alternatives - i.e. -webkit-image-set and html5 <image>) proposal to solve the problem of 2x-res (double-resolution) images with our current HTML and CSS standards for devices with high-resolution displays, such as 3rd Generation iPads and 4th generation iPhones and newer.

We add the following elements:

1) The new 'meta' attribute 'image-scaling' with arguments listed in the format {'scaling factor', 'scaling filename key'}, where the filename key is the often-standardized string added to the filename for 2x assets, i.e. '_2x' (it might even be possible to specify a different filename extension for the 2x asset by detecting whether the 'scaling filename key' string contains a period i.e. 'xxx.xxx'). Sub-attributes to the 'image-scaling' attribute would include the optional boolean (defaulted to 'true') attribute 'assume-present', and potentially the optional attribute 'image-scaling-path' for cases where sites store their various scaled image assets in different directories than their 1x images.

2) A new series of optional attributes to the img tag named after the scaling factor, i.e. '2x', '4x', etc., (possible values include 'true', 'false', a string for the double-res filename key, or 'url()' to specify a completely different path for the asset corresponding to that scaling factor)

3) A series of new optional CSS properties named after the scaling factor, i.e. 'background-image-2x', 'border-image-2x' and 'list-style-image-2x' (possible values for these include 'true', 'false', a string for the double-res filename key, or 'url()').

A simple example usage of these new capabilities would be the following:

<meta image-scaling="{2,'_2x'}" />

The effect of adding this single line to the page would be that a user agent that wishes to display double-res images would then attempt to access 'filename_2x.ext' whenever it encounters an img tag like '<img url=("filename.ext") />', or a CSS property like '.class {background-image: url("filename.ext");}', '.class {border-image: url("filename.ext");}' or '.class {list-style-image: url("filename.ext");}'. For all these, in the case that the 'filename_2x.ext' file does not exist, a second request is made for 'filename.ext'.

If the bulk of the 2x-resolution images are located in a different directory than the 1x assets, the meta tag could be extended as such:

<meta image-scaling="{2,'_2x'}" image-scaling-path="{2,'2x_images/'}" />

Then, any 2x img or css-image assets would be requested from '2x_images/filename_2x.ext' instead of 'images/filename.ext'.

If a particular 2x img tag asset or css-image asset has a '@2x' double-resolution filename key instead of '_2x' for some reason (maybe you're integrating with some 3rd party off-site content with a different 2x naming convention), you could add a '2x' attribute to its img tag, such as '<img 2x="@2x" />', or to its css properties, such as '.class {background-image-2x: "@2x";}'.

If a particular 2x-resolution img tag asset or css-image asset is not located in the same directory as the 1x asset, or if the filenames and/or file formats are not identical to the 1x asset, a separate path could be specified by doing this: '<img 2x=url("path/to/[hidden email]") />', or to its css properties by doing: '.class {background-image-2x: url("path/to/[hidden email]");}'.

In the case that a majority, but not all img and css-image assets are available in 2x resolution, the img assets that lack a 2x version would include the a tag such as, '<img 2x=false />, or a css property such as '.class{background-image-2x: false;}'.

In the case that a majority, but not all img and css-image assets are unavailable in 2x resolution, you would add the 'assume-present="{2,false}' attribute to the meta 'image-scaling' attribute, such as '<meta image-scaling="{2,'_2x'}" assume-present="{2,false}" />', and use the '2x' attribute to flag img assets with a double-resolution asset available, such as '<img 2x=true />, and the css with '.class {background-image-2x: true;}'.

In the case that no double-resolution image assets are available, the meta 'image-scaling' attribute can be simply omitted.

By using this approach, we avoid the need to specify the same list of filenames varying only by scaling factor filename key for every single image asset, which is a bunch of busy work that just seems extremely redundant and clumsy to me. We are also able to achieve the same level of performance for those willing to put in the extra work to flag assets that deviate from the default setting (to minimize requests), and we allow the flexibility to be lazy or wrong, and have the user agent make two requests in those cases. This solution is also completely backwards-compatible with existing browsers.

As a corollary to this, a similar approach could be used to add support for different image formats without losing backwards-compatibility, and again saving many precious developer-years. Imagine <meta image-formats="{jpeg2000, '.jp2'}" assume-present="{jpeg2000,boolean}" />

-Tom Penzer
humble web coding noob







Reply | Threaded
Open this post in threaded view
|

Re: Image Scaling for High-Pixel-Density (i.e. Retina) Displays - Re: -webkit-image-set and <image>

Tom Penzer
The problem with having the decision being made server-side is it's a complex decision whose factors are fluid, involving more than simply the screen resolution. Requesting 2x images also requires ~4x the data, and when devices are on mobile networks, they might wish to request 1x images instead of 2x, even though they have a screen capable of displaying the 2x image. Or they might want to let the user choose which images they prefer on mobile networks. And when they're on Wifi, they might want the 2x image instead. In the future, when the mobile networks are faster, that might no longer be the case, and the right decision today will be wrong tomorrow. That's why the user agent needs to choose, not the server. 

-Tom P.

On Apr 27, 2012, at 7:53 PM, Arthur Clifford wrote:

Wouldn't it be better if the user agent sent back pixels-per-inch or some other measure of bit-density information along with the User-agent metadata and then server-side scripting could be adapted to return imagery based on the user agent.

In fact if you used a server-side script, say getmedia.php, for the src of your images you could currently check the user agent data and figure out if it is an iphone/android/whatever and choose the version of the requested asset to return. You would have full control in getmedia.php over detecting the mime type of the requested asset and depending how you store the asset could determine whether any dynamic resampling of the asset is required; or at least choose a high vs low-res version. including additional parameters on the url like getmedia.php?&res=low or getmedia.php?&res=hi or &res=4x or whatever would allow an explicit resolution to be requested.

This just seems to me to be more of a server-side rather than client side thing; and I don't necessarily think that all servers should be expected to be media servers. If pixel-density is not currently User-Agent provided header/metadata, then I think that would be a better request. If one were to develop a server-side library for handling the user-agent metadata with pixel density and do light-wieght media serving with support for resolution specific settings, then those who want that functionality could use such a library and those who could care less could elect not to worry about it. In fact I would be very surprised if somebody hasn't created such a library already.

Art C

On Apr 27, 2012, at 2:49 PM, Jason H wrote:

1. To my knowledge w3c has never specified file naming conventions. Maybe extensions, as they are related to mime types, but this would be a new function of filename itself that would affect rendeing quality. What about images that already exist out there that are named as such? No, we should not use the filename for metadata.
2. The user agent can use Javascript to do this already.
3. The JS method is backwards compatible and requires no changes. To say it degrades gracefully, I think is the wrong direction. Initial sources should be low-res, then upgrade accordingly.


From: Tom Penzer <[hidden email]>
To: Jason H <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Sent: Friday, April 27, 2012 4:57 PM
Subject: Re: Image Scaling for High-Pixel-Density (i.e. Retina) Displays - Re: -webkit-image-set and <image>

The main advantages of doing it this way are:
1) You don't need to specify a different path for every scale of every image if you follow a naming convention.
2) the user agent makes the decision of which asset to request (based on factors such as screen resolution and network quality/value of bandwidth)
3) It's backwards-compatible and degrades gracefully.

-Tom


On Apr 27, 2012, at 1:50 PM, Jason H <[hidden email]> wrote:

I think the approach of attacking it from setting a scaling is wrong.
The real approach is to set the final dimensions, and let the software give the appropriate scaling based on the image metadata.

If you want a double-density image, you're just asking for 100x100 to be rendered in 50x50. The image tag already supports this. <IMG HEIGHT=50 WIDTH=50 SRC="100x100.png"/> Far too often it is implied that the display density is identical to the sampling (pixel density) by not including the height and width attributes.

The real challenge as I see it, is having an efficient way of not sending over-sampled data across the wire, unless you mean to. Sending a double density image actually sends 4 times the data as a native resolution image. I would suggest we leave it up to java script to handle the pixel density matching, where it can dynamically assign the assets to the proper size-density, if needed. For the most part pick something not over sampled and let the browser scale it up if need be. A server-component could dynamically render and cache the common sizes of an image. But I don't see a need to change HTML.








From: Tom Penzer <[hidden email]>
To: [hidden email]
Sent: Friday, April 27, 2012 3:47 PM
Subject: Image Scaling for High-Pixel-Density (i.e. Retina) Displays - Re: -webkit-image-set and <image>

Hi everybody,

I'm seeking feedback for my (hopefully relatively painless in practice compared to the alternatives - i.e. -webkit-image-set and html5 <image>) proposal to solve the problem of 2x-res (double-resolution) images with our current HTML and CSS standards for devices with high-resolution displays, such as 3rd Generation iPads and 4th generation iPhones and newer.

We add the following elements:

1) The new 'meta' attribute 'image-scaling' with arguments listed in the format {'scaling factor', 'scaling filename key'}, where the filename key is the often-standardized string added to the filename for 2x assets, i.e. '_2x' (it might even be possible to specify a different filename extension for the 2x asset by detecting whether the 'scaling filename key' string contains a period i.e. 'xxx.xxx'). Sub-attributes to the 'image-scaling' attribute would include the optional boolean (defaulted to 'true') attribute 'assume-present', and potentially the optional attribute 'image-scaling-path' for cases where sites store their various scaled image assets in different directories than their 1x images.

2) A new series of optional attributes to the img tag named after the scaling factor, i.e. '2x', '4x', etc., (possible values include 'true', 'false', a string for the double-res filename key, or 'url()' to specify a completely different path for the asset corresponding to that scaling factor)

3) A series of new optional CSS properties named after the scaling factor, i.e. 'background-image-2x', 'border-image-2x' and 'list-style-image-2x' (possible values for these include 'true', 'false', a string for the double-res filename key, or 'url()').

A simple example usage of these new capabilities would be the following:

<meta image-scaling="{2,'_2x'}" />

The effect of adding this single line to the page would be that a user agent that wishes to display double-res images would then attempt to access 'filename_2x.ext' whenever it encounters an img tag like '<img url=("filename.ext") />', or a CSS property like '.class {background-image: url("filename.ext");}', '.class {border-image: url("filename.ext");}' or '.class {list-style-image: url("filename.ext");}'. For all these, in the case that the 'filename_2x.ext' file does not exist, a second request is made for 'filename.ext'.

If the bulk of the 2x-resolution images are located in a different directory than the 1x assets, the meta tag could be extended as such:

<meta image-scaling="{2,'_2x'}" image-scaling-path="{2,'2x_images/'}" />

Then, any 2x img or css-image assets would be requested from '2x_images/filename_2x.ext' instead of 'images/filename.ext'.

If a particular 2x img tag asset or css-image asset has a '@2x' double-resolution filename key instead of '_2x' for some reason (maybe you're integrating with some 3rd party off-site content with a different 2x naming convention), you could add a '2x' attribute to its img tag, such as '<img 2x="@2x" />', or to its css properties, such as '.class {background-image-2x: "@2x";}'.

If a particular 2x-resolution img tag asset or css-image asset is not located in the same directory as the 1x asset, or if the filenames and/or file formats are not identical to the 1x asset, a separate path could be specified by doing this: '<img 2x=url("path/to/[hidden email]") />', or to its css properties by doing: '.class {background-image-2x: url("path/to/[hidden email]");}'.

In the case that a majority, but not all img and css-image assets are available in 2x resolution, the img assets that lack a 2x version would include the a tag such as, '<img 2x=false />, or a css property such as '.class{background-image-2x: false;}'.

In the case that a majority, but not all img and css-image assets are unavailable in 2x resolution, you would add the 'assume-present="{2,false}' attribute to the meta 'image-scaling' attribute, such as '<meta image-scaling="{2,'_2x'}" assume-present="{2,false}" />', and use the '2x' attribute to flag img assets with a double-resolution asset available, such as '<img 2x=true />, and the css with '.class {background-image-2x: true;}'.

In the case that no double-resolution image assets are available, the meta 'image-scaling' attribute can be simply omitted.

By using this approach, we avoid the need to specify the same list of filenames varying only by scaling factor filename key for every single image asset, which is a bunch of busy work that just seems extremely redundant and clumsy to me. We are also able to achieve the same level of performance for those willing to put in the extra work to flag assets that deviate from the default setting (to minimize requests), and we allow the flexibility to be lazy or wrong, and have the user agent make two requests in those cases. This solution is also completely backwards-compatible with existing browsers.

As a corollary to this, a similar approach could be used to add support for different image formats without losing backwards-compatibility, and again saving many precious developer-years. Imagine <meta image-formats="{jpeg2000, '.jp2'}" assume-present="{jpeg2000,boolean}" />

-Tom Penzer
humble web coding noob