I think his statement is reasonable. Sometimes we notice things in retrospect. For example, the iPad rendering the iPhone 4 at 1:1 without the ugly 2x option. I had thought of that, but then wondered why it hadn't been mentioned earlier by someone more clever than me.
Totally valid. I hope this means the up-scaling of iPhone apps on an iPad running iOS4 will get the same enhancement too. Hopefully along with some general bit-image resolution enhancement too.
No, if anything, they should be more streamlined. Bitmapped images are usually larger in size and do not scale, while a vector graphic is the same size or smaller if made correctly and will scale with the resolution of the screen.
That's great, but who uses vector graphics for web sites layouts? It's not widely practiced. I don't think iOS 4 will change that. I don't think larger raster images would be difficult or prohibitive. I think web sites will probably stay the same except for some proof of concepts and a few enthusiastic fans.
Quote:
Originally Posted by McDave
Totally valid. I hope this means the up-scaling of iPhone apps on an iPad running iOS4 will get the same enhancement too. Hopefully along with some general bit-image resolution enhancement too.
There was a small amount of speculation about whether the iPad upscaling would render text natively to the screen or just be a fuzzy or blocky upscale. Now that the iPhone gets this capability, I think it's far more likely than not the iPad will do this too unless there is some hang-up they can't solve, even then, I think it will happen eventually. The devices are so similar that it's almost not funny, the differences are almost totally irrelevant to the question of resolution independence.
That's great, but who uses vector graphics for web sites layouts? It's not widely practiced. I don't think iOS 4 will change that. I don't think larger raster images would be difficult or prohibitive. I think web sites will probably stay the same except for some proof of concepts and a few enthusiastic fans.
I believe HTML5 includes native support for SVG which is also XML based. This could mean big changes in many images and graphics which can now be dynamically data driven.
I want one for sure. Hope it will help my iSight, because I started wearing reading glasses few months after I got my first iPhone in June 2007. But then most people my age use glasses for reading.
Well sights like ai are tough on the eyes for us more experinced folks.
I don't know. Maybe there is a way programatically to take advantage of higher resolution but when you scale images in the browser bad things happen to the quality.
I made a sample test. There are four images, the top two are jpg and the bottom two are png. Actually the results are the same so it is irrelevant which file format you use. The point is, the top image of each pair is a high res image scaled and the bottom one is regular 72 dpi not scaled. You can see for yourself that the high res image is inferior due to scaling.
Interesting test. Now however it depends on the scaling methodology when scaling down images. Your test probably used the default of "bilinear sampling" which always smooths out images when scaling down. There are other rendering methods which preserve resolution better and preserve sharpness so that the high res image ends up very close to the unscaled image.
That said, it depends on the scaling engine used by the iPhone 4.
At the end of the day, there are two points I think most relevant:
1. When it comes to website, the higher ppi of the iPhone 4 will mean that people can view websites without having to zoom-in as much. If they are viewing at the same zoom levels, then for image-heavy websites there may not be as much benefit than viewing text-heavy websites.
2. A lot of the goals of the iPhone 4's Retina display is oriented towards applications, rather than websites. As some mentioned, right now there is no conventional way of "encoding" a bitmap in a web page to display according to the ppi of the display device. So, it's about the apps, which *will* have the ability to display the right bitmaps according to the ppi of the display device. In other words apps will be the primary area where we will move towards (not quite there yet) resolution-independent user interfaces.
I'm by no means an expert on graphics so please correct me if I'm wrong, but I am under the impression that vectored images are best when try don't contain a lot of detail and at small sizes can be significantly larger than bitmaps.
Not the size of the AI logo In the arrticle. What would be the file size for that same image, since it is simple? Is their proxessing overhead for vector over bitmap that can slow down the page render? If vector images are generally ideal why does Apple offer Icon Composer and create all it's apps as 16^2, 32^2, 128^2, 256^2, and 512^2 as bitmaps?
Quote:
Originally Posted by ajmas
As you indicated, It all depends on the complexity of the image and the supported features of the vector format. Also, is the vector format binary, text, or compressed text. Any comparison would have to be done with JPG or PNG vs SVG. Then again, this presumes that the resolution of the image is suitable for all display devices and scales. Bitmaps would have to be available in multiple sizes, whereas a vector can be scaled to almost any resolution.
You see, raster vs vector was one of the big battlegrounds in web design before the whole Flash debate came to the forefront.
Currently almost all sites do not incorporate vector graphics in web pages, except for Flash elements. The only thing that could be considered "vector-based" would be background colors, and "div tag and table layouts". Yes, there is SVG, and CSS provides some vector tools. But by convention, for the most part, SVG and CSS shapes are not used (although CSS may be gradually used for eg. drop shadows and rounded corners). If you think Flash is a big deal, the SVG/CSS vector issue has been smoldering for much longer. SVG was supposed to be a saviour in all kinds of ways but it just didn't pan out. In fact PNG support became more important because it offered non-lossy compression as well as alpha channel (transparency).
In an ideal situation everything would be vector based so that it can be rendered at an extremely wide range of sizes and still look fine. Two challenges exist, mainly because the industry did not go this way.
One is the file size, as pointed out in previous posts. Bitmaps provide mostly predictable file sizes and thus can be planned for accordingly. Could intelligent compression be applied to complex vector files in the future? No doubt, and even now sometimes really complex vector files can be surprisingly small.
Two, and more significant, I think, is the rendering of vector files. Let's say for the icons on a Mac desktop. Let's say you open your Applications folder, and have 20 to 40 icons displayed, and you scaled them up and down. At this stage, on Mac or PC, rendering using bitmaps is a heck of a lot faster. Again, I don't think this is a hardware limitation. In the bitmap-based solution, the icons are usually encoded as PNG so they have to be decoded anyway, and the Finder has to resample icons on the fly and display them antialiased with transparency. So the Finder is doing some non-trivial work there already. Another example is we have fast decoding and displaying of demanding video compression eg. H.264, even before GPU acceleration came into the picture.
So if the effort was put into storing, compressing and rendering vector graphics, we could really have had everything really vector based.
I am no expert on early computing and machine/assembly code but I think all this stems from when graphics was first used in personal computers. In those situations, literally bit-mapping each pixel to one bit of data was the most efficient way of displaying complex images. Later, with 256 colours, then 64k(?) then millions of colours, it was just an extension of bit-mapping, only this time applying more bits for each pixel to store colour information. You wanted larger, clearer pictures? Just display more pixels, and give each pixel more bits of colour information. You wanted transparency for blending images over each other? Just give each pixel an additional set of bits on it's level of opacity. But it was still pixel-oriented.
So at the end of the day, only with HTML 5, newer CSS, PDF, Core Image, 3D gaming, 3D interfaces and so on, are we starting to move away from a bitmap-oriented world. But as you see with web pages, existing OS interfaces and disasters like the Wired application, we are still stuck with mapping bits.
While I'm at it, this situation is actually what led to the tremendous rise of Flash circa 2000-2008. Because you could display a lot of vectorised graphics, effects, eg. text layers, transparency, drop shadows, curves, rounded corners and it would scale well (later on bitmaps in Flash would also scale well) to a really wide range of resolutions and look good (and interaction etc would work predictably across browsers!) on almost any computer, albeit it had to have the appropriate Flash version (but each new version of Flash was suitably backwards compatible with older Flash files). Rendering of complex vector art (eg. illustrations) was pretty fast too, so that led to the rise of Flash gaming and Flash advertising... Though said rendering would be crazy sluggish on Macs, and now a big burden on mobile devices.
For the rest of us, would I be right to say that what this really means is we'll get sharper images on the iphone 4 when we pinch and zoom in, i.e., there wouldn't be much of a difference if we stuck to viewing the default screen in either the 4 or the 3GS?
For the rest of us, would I be right to say that what this really means is we'll get sharper images on the iphone 4 when we pinch and zoom in, i.e., there wouldn't be much of a difference if we stuck to viewing the default screen in either the 4 or the 3GS?
Actually, when viewing the default zoomed-out screen of a web page, it will look very sharp on the iPhone 4 compared to the 3GS. Because there is a lot more resolution there to make everything look like a "fine printed book". Depending on your eyesight you may be able to read a lot more of a web page without having to zoom in.
When you pinch and zoom in, there will be an irregularity more noticeable in the 4 than the 3GS. On the 4, when zoomed-in, images may look either alright or slightly blocky, while text will look very, very crisp.
The iPhone 4 web page viewing, I predict, will be best, when somewhere *between* fully zoomed out and very zoomed in. In this regard it will look much better overall compared to the 3G/3GS.
This is a bit of a segue from the topic at hand, but I found the info interesting. Especially the initial use of -webkit-gradient which was slowing down this iPad web app by creating bitmap images.
Comments
I think his statement is reasonable. Sometimes we notice things in retrospect. For example, the iPad rendering the iPhone 4 at 1:1 without the ugly 2x option. I had thought of that, but then wondered why it hadn't been mentioned earlier by someone more clever than me.
Totally valid. I hope this means the up-scaling of iPhone apps on an iPad running iOS4 will get the same enhancement too. Hopefully along with some general bit-image resolution enhancement too.
McD
No, if anything, they should be more streamlined. Bitmapped images are usually larger in size and do not scale, while a vector graphic is the same size or smaller if made correctly and will scale with the resolution of the screen.
That's great, but who uses vector graphics for web sites layouts? It's not widely practiced. I don't think iOS 4 will change that. I don't think larger raster images would be difficult or prohibitive. I think web sites will probably stay the same except for some proof of concepts and a few enthusiastic fans.
Totally valid. I hope this means the up-scaling of iPhone apps on an iPad running iOS4 will get the same enhancement too. Hopefully along with some general bit-image resolution enhancement too.
There was a small amount of speculation about whether the iPad upscaling would render text natively to the screen or just be a fuzzy or blocky upscale. Now that the iPhone gets this capability, I think it's far more likely than not the iPad will do this too unless there is some hang-up they can't solve, even then, I think it will happen eventually. The devices are so similar that it's almost not funny, the differences are almost totally irrelevant to the question of resolution independence.
That's great, but who uses vector graphics for web sites layouts? It's not widely practiced. I don't think iOS 4 will change that. I don't think larger raster images would be difficult or prohibitive. I think web sites will probably stay the same except for some proof of concepts and a few enthusiastic fans.
I believe HTML5 includes native support for SVG which is also XML based. This could mean big changes in many images and graphics which can now be dynamically data driven.
I want one for sure. Hope it will help my iSight, because I started wearing reading glasses few months after I got my first iPhone in June 2007. But then most people my age use glasses for reading.
Well sights like ai are tough on the eyes for us more experinced folks.
I don't know. Maybe there is a way programatically to take advantage of higher resolution but when you scale images in the browser bad things happen to the quality.
I made a sample test. There are four images, the top two are jpg and the bottom two are png. Actually the results are the same so it is irrelevant which file format you use. The point is, the top image of each pair is a high res image scaled and the bottom one is regular 72 dpi not scaled. You can see for yourself that the high res image is inferior due to scaling.
Test Page
Interesting test. Now however it depends on the scaling methodology when scaling down images. Your test probably used the default of "bilinear sampling" which always smooths out images when scaling down. There are other rendering methods which preserve resolution better and preserve sharpness so that the high res image ends up very close to the unscaled image.
That said, it depends on the scaling engine used by the iPhone 4.
At the end of the day, there are two points I think most relevant:
1. When it comes to website, the higher ppi of the iPhone 4 will mean that people can view websites without having to zoom-in as much. If they are viewing at the same zoom levels, then for image-heavy websites there may not be as much benefit than viewing text-heavy websites.
2. A lot of the goals of the iPhone 4's Retina display is oriented towards applications, rather than websites. As some mentioned, right now there is no conventional way of "encoding" a bitmap in a web page to display according to the ppi of the display device. So, it's about the apps, which *will* have the ability to display the right bitmaps according to the ppi of the display device. In other words apps will be the primary area where we will move towards (not quite there yet) resolution-independent user interfaces.
I'm by no means an expert on graphics so please correct me if I'm wrong, but I am under the impression that vectored images are best when try don't contain a lot of detail and at small sizes can be significantly larger than bitmaps.
Not the size of the AI logo In the arrticle. What would be the file size for that same image, since it is simple? Is their proxessing overhead for vector over bitmap that can slow down the page render? If vector images are generally ideal why does Apple offer Icon Composer and create all it's apps as 16^2, 32^2, 128^2, 256^2, and 512^2 as bitmaps?
As you indicated, It all depends on the complexity of the image and the supported features of the vector format. Also, is the vector format binary, text, or compressed text. Any comparison would have to be done with JPG or PNG vs SVG. Then again, this presumes that the resolution of the image is suitable for all display devices and scales. Bitmaps would have to be available in multiple sizes, whereas a vector can be scaled to almost any resolution.
You see, raster vs vector was one of the big battlegrounds in web design before the whole Flash debate came to the forefront.
Currently almost all sites do not incorporate vector graphics in web pages, except for Flash elements. The only thing that could be considered "vector-based" would be background colors, and "div tag and table layouts". Yes, there is SVG, and CSS provides some vector tools. But by convention, for the most part, SVG and CSS shapes are not used (although CSS may be gradually used for eg. drop shadows and rounded corners). If you think Flash is a big deal, the SVG/CSS vector issue has been smoldering for much longer. SVG was supposed to be a saviour in all kinds of ways but it just didn't pan out. In fact PNG support became more important because it offered non-lossy compression as well as alpha channel (transparency).
In an ideal situation everything would be vector based so that it can be rendered at an extremely wide range of sizes and still look fine. Two challenges exist, mainly because the industry did not go this way.
One is the file size, as pointed out in previous posts. Bitmaps provide mostly predictable file sizes and thus can be planned for accordingly. Could intelligent compression be applied to complex vector files in the future? No doubt, and even now sometimes really complex vector files can be surprisingly small.
Two, and more significant, I think, is the rendering of vector files. Let's say for the icons on a Mac desktop. Let's say you open your Applications folder, and have 20 to 40 icons displayed, and you scaled them up and down. At this stage, on Mac or PC, rendering using bitmaps is a heck of a lot faster. Again, I don't think this is a hardware limitation. In the bitmap-based solution, the icons are usually encoded as PNG so they have to be decoded anyway, and the Finder has to resample icons on the fly and display them antialiased with transparency. So the Finder is doing some non-trivial work there already. Another example is we have fast decoding and displaying of demanding video compression eg. H.264, even before GPU acceleration came into the picture.
So if the effort was put into storing, compressing and rendering vector graphics, we could really have had everything really vector based.
I am no expert on early computing and machine/assembly code but I think all this stems from when graphics was first used in personal computers. In those situations, literally bit-mapping each pixel to one bit of data was the most efficient way of displaying complex images. Later, with 256 colours, then 64k(?) then millions of colours, it was just an extension of bit-mapping, only this time applying more bits for each pixel to store colour information. You wanted larger, clearer pictures? Just display more pixels, and give each pixel more bits of colour information. You wanted transparency for blending images over each other? Just give each pixel an additional set of bits on it's level of opacity. But it was still pixel-oriented.
So at the end of the day, only with HTML 5, newer CSS, PDF, Core Image, 3D gaming, 3D interfaces and so on, are we starting to move away from a bitmap-oriented world. But as you see with web pages, existing OS interfaces and disasters like the Wired application, we are still stuck with mapping bits.
While I'm at it, this situation is actually what led to the tremendous rise of Flash circa 2000-2008. Because you could display a lot of vectorised graphics, effects, eg. text layers, transparency, drop shadows, curves, rounded corners and it would scale well (later on bitmaps in Flash would also scale well) to a really wide range of resolutions and look good (and interaction etc would work predictably across browsers!) on almost any computer, albeit it had to have the appropriate Flash version (but each new version of Flash was suitably backwards compatible with older Flash files). Rendering of complex vector art (eg. illustrations) was pretty fast too, so that led to the rise of Flash gaming and Flash advertising... Though said rendering would be crazy sluggish on Macs, and now a big burden on mobile devices.
For the rest of us, would I be right to say that what this really means is we'll get sharper images on the iphone 4 when we pinch and zoom in, i.e., there wouldn't be much of a difference if we stuck to viewing the default screen in either the 4 or the 3GS?
Actually, when viewing the default zoomed-out screen of a web page, it will look very sharp on the iPhone 4 compared to the 3GS. Because there is a lot more resolution there to make everything look like a "fine printed book". Depending on your eyesight you may be able to read a lot more of a web page without having to zoom in.
When you pinch and zoom in, there will be an irregularity more noticeable in the 4 than the 3GS. On the 4, when zoomed-in, images may look either alright or slightly blocky, while text will look very, very crisp.
The iPhone 4 web page viewing, I predict, will be best, when somewhere *between* fully zoomed out and very zoomed in. In this regard it will look much better overall compared to the 3G/3GS.
icons look great too!
for anyone interested, i'll post some side-by-side comparisons of our app in 1x and 2x, in a moment.
WiCKED!