Wouldn't Photoshop have a problem with resolution independence? If Leopard let's me set-up my display as taking advantage of 150ppi resolution screen then what is Photoshop to do with it? Especially at 100 % magnification which is supposed to be 1 pixel = 1 pixel display -- wouldn't that mean that a 72 ppi photo would take up roughly half the screen real estate that the same photo would take up on a 72 ppi screen? It would seem that editing a 72 ppi icon for a website would become very difficult on a screen that was running at 150 ppi.
If I don't get it, please explain it to me.
It doesn't have to be all or nothing.
The program elements such as the menus and tool windows could benefit from this.
Raster images such as the photo's you are working on could stay the way they are, with PS's standard way of magnifying them.
The program elements such as the menus and tool windows could benefit from this.
Raster images such as the photo's you are working on could stay the way they are, with PS's standard way of magnifying them.
No problem there.
So you're saying that there would be, or could be, in essence two different resolutions at play in a Photoshop screen...one for the menu items and another for the file display.
Or perhaps it's more like the menus could take advantage of a capability that the file display area couldn't?
In either case, it could solve some problems with the palette displays in Photoshop, Illustrator and InDesign, allowing them to be smaller and still be legible.
So you're saying that there would be, or could be, in essence two different resolutions at play in a Photoshop screen...one for the menu items and another for the file display.
Or perhaps it's more like the menus could take advantage of a capability that the file display area couldn't?
In either case, it could solve some problems with the palette displays in Photoshop, Illustrator and InDesign, allowing them to be smaller and still be legible.
It isn't that the file COULDN'T take advantage of it, but, what would be the point?
You could possibly change the magnification of the menus and palettes. It would be easier to select a color from some of the palettes if they were larger.
With a second monitor, you could increase the size of the palettes to fill the screen, and make hitting a control, or selection, or color, that much easier
I suppose this means that the new MBP's that launch in April will have way better screens then, hmm?
I have to admit that I'm not as eager to invest in a new Mac Pro before Leopard comes out with hardware designed to take advantage of all the new features. Might cost me more but might also get me another year or so out of the box before the next upgrade becomes necessary.
Actually, it would use percentages. There is no way for the software to know how big the screen is, only the number of pixels available to it.
Of course there is, that's what EDID / DDC is for. Without that information the OS wouldn't be able to set your DPI automatically in the first place.
Now while the OS needs this and can access this info, whether the physical size (as opposed to DPI) should be exposed to applications is another question.
No, they already exist. But last I heard thet went for about $100,000.00 for a 30" (a couple years ago). Los Alamos has several for simulation data representation.
Well, of course open documents in Photoshop would still be pixel-for-pixel (at 100% mag). It would be a rediculous implementation of resolution independance to not allow the application decide what elements of it's interface can be scaled.
No, they already exist. But last I heard thet went for about $100,000.00 for a 30" (a couple years ago). Los Alamos has several for simulation data representation.
In other words, you'll probably be waiting for a long time to get one.
Instead of speculating about what it means, ADC Select and Premier members can view the WWDC 2006 session on Resolution Independence (also known as HI-DPI) by logging in to ADC and clicking the "Log In To ADC on iTunes" link. From iTunes you can download and view all of the ADC technical sessions including an excellent one on Resolution Independence.
Of course there is, that's what EDID / DDC is for. Without that information the OS wouldn't be able to set your DPI automatically in the first place.
Now while the OS needs this and can access this info, whether the physical size (as opposed to DPI) should be exposed to applications is another question.
No, they already exist. But last I heard thet went for about $100,000.00 for a 30" (a couple years ago). Los Alamos has several for simulation data representation.
And there is a 107" Plasma Tv, but we don't talk about that either when we talk about Tv's. It also costs about that.
Remember the IBM/Viewsonic?
That cost an arm and a leg, and was much lower rez. Not made any more.
And there is a 107" Plasma Tv, but we don't talk about that either when we talk about Tv's. It also costs about that.
Remember the IBM/Viewsonic?
That cost an arm and a leg, and was much lower rez. Not made any more.
And I just responded to one of your posts in the OpenGL 2.1 thread that next years 8-core CPU desktop with a paired SLI GPU will equal or better the processing power of a $5 million SGI Reality Monster mainframe install in 2000. a 500:1 price decrease over 7 years.
That would make the $100,000 monitor a cool $200 in 2009. I don't feel like running the exponential curve to project that to a year from now, but I don't think that wait will be a long one. They will still be expensive, but we bought $4,000 22" cinema displays 5 years ago and $15,000 32" plasma screens, we will jump at a $5,000 30" 300dpi monitor when they get here.
And I just responded to one of your posts in the OpenGL 2.1 thread that next years 8-core CPU desktop with a paired SLI GPU will equal or better the processing power of a $5 million SGI Reality Monster mainframe install in 2000. a 500:1 price decrease over 7 years.
That would make the $100,000 monitor a cool $200 in 2009. I don't feel like running the exponential curve to project that to a year from now, but I don't think that wait will be a long one. They will still be expensive, but we bought $4,000 22" cinema displays 5 years ago and $15,000 32" plasma screens, we will jump at a $5,000 30" 300dpi monitor when they get here.
Will this have a good effect or any effect on the Zoom feature in Mac OS X? You know the nifty one with the Mighty mouse scrollball. In other words will text be clear when you Zoom in on it?
Quote:
Originally Posted by Mr. H
Resolution independence doesn't help there. But higher resolution displays would.
I think you misunderstood his question. He meant, when using the accessibility zoom function on the screen, will text still look pixelated when blown up, and the answer is that no, it won't because it will be rerendered as a vector at higher rez rather than just expanding the prerendered bitmap.
So in fact the answer to his question is yes, this will help make zoomed text clearer.
So would this mean you could build applications with vector-based interfaces?
You already can. It does mean there's a bit more reason to do so, now...
Quote:
Originally Posted by Chucker
Incorrect. OS X does not use any vector-based widgets. Rather, with Tiger and Leopard, Apple has been introducing much-higher-resolution widgets, to the point that you simply can't tell any more that they're scaled pixel graphics.
Wrong.
Apple are already recommending vector based widgets. They're not appropriate for everything, and for the rest a high resolution bitmap will do. PDF is the vector format of choice, and they're pushing hard to make developers use it for widgets
Quote:
Originally Posted by admactanium
no, actually i think that's exactly where it would be of benefit. the display zooming in osx is a nice feature but it looks like hell right now because all the text and widgets are displayed as rasters. so display zoom up to the toolbar or in a webpage and the text gets bitmappy looking. resolution independence would keep all of those elements perfectly smooth at any magnification.
Sadly, it does not seem like the zoom feature is tied in to the resolution independence API. I wish it was.
Quote:
Originally Posted by donebylee
Am I missing something here?*
Wouldn't Photoshop have a problem with resolution independence? If Leopard let's me set-up my display as taking advantage of 150ppi resolution screen then what is Photoshop to do with it? Especially at 100 % magnification which is supposed to be 1 pixel = 1 pixel display -- wouldn't that mean that a 72 ppi photo would take up roughly half the screen real estate that the same photo would take up on a 72 ppi screen? It would seem that editing a 72 ppi icon for a website would become very difficult on a screen that was running at 150 ppi.
If I don't get it, please explain it to me.
You have the right idea, just an incorrect assumption. "100 % magnification ... is supposed to be 1 pixel = 1 pixel display" -- that assumption was true before resolution independence but is no longer true.
What happens is an image will look the same physical size (e.g. 1 inch wide) regardless of the pixel density of your display. So if your screen is running at 150 ppi, the photo will look the same size as on a 72 ppi screen, but will be using twice as many pixels to display. Currently, on the aformentioned 150 ppi screen, the photo would display at half the size as on a 72 ppi screen.
Quote:
Originally Posted by donebylee
So you're saying that there would be, or could be, in essence two different resolutions at play in a Photoshop screen...one for the menu items and another for the file display.*
Or perhaps it's more like the menus could take advantage of a capability that the file display area couldn't?
In either case, it could solve some problems with the palette displays in Photoshop, Illustrator and InDesign, allowing them to be smaller and still be legible.
What he's saying is that the resolution independence scaling stuff will be applied to the file itself... because the OS applies it to everything. But it will not give the user any benefit there.
Quote:
Originally Posted by WhiteRabbit
Well, of course open documents in Photoshop would still be pixel-for-pixel (at 100% mag). It would be a rediculous implementation of resolution independance to not allow the application decide what elements of it's interface can be scaled.
"Not all applications will rev to support resolution independence in the short term, but we still want to offer a reasonable experience in unmodified applications when the user has chosen a non-1.0 scale factor. To this end, HIToolbox automatically "magnifies" windows that are not resolution independence savvy."
Photoshop could decide that its image windows not be scaled... although they'll look stupidly out of place in the new OS. To do so, they would have to explicitly specify that. Resolution independence is opt-out, not opt-in. (And only carbon apps can opt out. Cocoa apps have no choice!)
Quote:
Originally Posted by Socrates
I think you misunderstood his question. He meant, when using the accessibility zoom function on the screen, will text still look pixelated when blown up, and the answer is that no, it won't because it will be rerendered as a vector at higher rez rather than just expanding the prerendered bitmap.
So in fact the answer to his question is yes, this will help make zoomed text clearer.
Socrates
Well, I'd like to hope so, but currently the zoom expands the bitmap screen buffer, rather than re-rendering anything. Perhaps this will change...
Apple are already recommending vector based widgets. They're not appropriate for everything, and for the rest a high resolution bitmap will do. PDF is the vector format of choice, and they're pushing hard to make developers use it for widgets
Where the heck do you see vector-based widgets, and if Apple are "recommending" them, why aren't they using them, but instead using higher-resolution versions of the same old widgets?
MS can often claim they've done something first and that others copied...but MS puts out so many inept implementations that it would be stupid to say MS put it out first.
It's always the same old story on Mac/PC boards such as Ars Technica. "MS had Exposé first". This last example is someone talking about the Windows feature that allows one to tile windows on screen without any overlaps. Can you imagine? There are countless examples where people compare shitty implementations to OS X implementations and claim they were the first to do it.
Apple will get it right...it won't bring us some dastardly interface that offers a few different sizes with pixelated icons and window content that doesn't even scale with the rest of the interface widgets.
I totally agree! From now on lets use the phrase, "Apple was the first to do it right."
You have the right idea, just an incorrect assumption. "100 % magnification ... is supposed to be 1 pixel = 1 pixel display" -- that assumption was true before resolution independence but is no longer true.
What happens is an image will look the same physical size (e.g. 1 inch wide) regardless of the pixel density of your display. So if your screen is running at 150 ppi, the photo will look the same size as on a 72 ppi screen, but will be using twice as many pixels to display. Currently, on the aformentioned 150 ppi screen, the photo would display at half the size as on a 72 ppi screen.
As to displaying the image in its assigned size, will this require additional information that is not currently encoded in the file?
If a file is designated as being 72x72 pixels and it is then displayed on a resolution independent screen, does the file need to contain additional information to tell the OS to display as a 1x1 inch file, or is that the assumption (72 pixels = 1 inch) built into resolution independence?
Could this cause any significant overhead processing with older apps? If the OS is having to run these calculations on the fly, would this add to its processing load, i.e. more Rosetta style slow-downs?
As to displaying the image in its assigned size, will this require additional information that is not currently encoded in the file?
If a file is designated as being 72x72 pixels and it is then displayed on a resolution independent screen, does the file need to contain additional information to tell the OS to display as a 1x1 inch file, or is that the assumption (72 pixels = 1 inch) built into resolution independence?
You are right, many image formats don't contain the physical size that I am aware, so they would have to assume 72 unless otherwise told. My installations of Photoshop assumes 72 unless I tell it otherwise, on a per-image bases. Also, the display's size information is apparently unreliable so if the user wants accuracy, they would have to punch that information in too.
Quote:
Could this cause any significant overhead processing with older apps? If the OS is having to run these calculations on the fly, would this add to its processing load, i.e. more Rosetta style slow-downs?
I don't think it would put a major load on the CPU, it might be done in the GPU.
Comments
Am I missing something here?
Wouldn't Photoshop have a problem with resolution independence? If Leopard let's me set-up my display as taking advantage of 150ppi resolution screen then what is Photoshop to do with it? Especially at 100 % magnification which is supposed to be 1 pixel = 1 pixel display -- wouldn't that mean that a 72 ppi photo would take up roughly half the screen real estate that the same photo would take up on a 72 ppi screen? It would seem that editing a 72 ppi icon for a website would become very difficult on a screen that was running at 150 ppi.
If I don't get it, please explain it to me.
It doesn't have to be all or nothing.
The program elements such as the menus and tool windows could benefit from this.
Raster images such as the photo's you are working on could stay the way they are, with PS's standard way of magnifying them.
No problem there.
It doesn't have to be all or nothing.
The program elements such as the menus and tool windows could benefit from this.
Raster images such as the photo's you are working on could stay the way they are, with PS's standard way of magnifying them.
No problem there.
So you're saying that there would be, or could be, in essence two different resolutions at play in a Photoshop screen...one for the menu items and another for the file display.
Or perhaps it's more like the menus could take advantage of a capability that the file display area couldn't?
In either case, it could solve some problems with the palette displays in Photoshop, Illustrator and InDesign, allowing them to be smaller and still be legible.
So you're saying that there would be, or could be, in essence two different resolutions at play in a Photoshop screen...one for the menu items and another for the file display.
Or perhaps it's more like the menus could take advantage of a capability that the file display area couldn't?
In either case, it could solve some problems with the palette displays in Photoshop, Illustrator and InDesign, allowing them to be smaller and still be legible.
It isn't that the file COULDN'T take advantage of it, but, what would be the point?
You could possibly change the magnification of the menus and palettes. It would be easier to select a color from some of the palettes if they were larger.
With a second monitor, you could increase the size of the palettes to fill the screen, and make hitting a control, or selection, or color, that much easier
I suppose this means that the new MBP's that launch in April will have way better screens then, hmm?
I have to admit that I'm not as eager to invest in a new Mac Pro before Leopard comes out with hardware designed to take advantage of all the new features. Might cost me more but might also get me another year or so out of the box before the next upgrade becomes necessary.
Actually, it would use percentages. There is no way for the software to know how big the screen is, only the number of pixels available to it.
Of course there is, that's what EDID / DDC is for. Without that information the OS wouldn't be able to set your DPI automatically in the first place.
Now while the OS needs this and can access this info, whether the physical size (as opposed to DPI) should be exposed to applications is another question.
You'll wait a long time.
No, they already exist. But last I heard thet went for about $100,000.00 for a 30" (a couple years ago). Los Alamos has several for simulation data representation.
No, they already exist. But last I heard thet went for about $100,000.00 for a 30" (a couple years ago). Los Alamos has several for simulation data representation.
In other words, you'll probably be waiting for a long time to get one.
Of course there is, that's what EDID / DDC is for. Without that information the OS wouldn't be able to set your DPI automatically in the first place.
Now while the OS needs this and can access this info, whether the physical size (as opposed to DPI) should be exposed to applications is another question.
Very few monitors comply with that standard.
No, they already exist. But last I heard thet went for about $100,000.00 for a 30" (a couple years ago). Los Alamos has several for simulation data representation.
And there is a 107" Plasma Tv, but we don't talk about that either when we talk about Tv's. It also costs about that.
Remember the IBM/Viewsonic?
That cost an arm and a leg, and was much lower rez. Not made any more.
And there is a 107" Plasma Tv, but we don't talk about that either when we talk about Tv's. It also costs about that.
Remember the IBM/Viewsonic?
That cost an arm and a leg, and was much lower rez. Not made any more.
And I just responded to one of your posts in the OpenGL 2.1 thread that next years 8-core CPU desktop with a paired SLI GPU will equal or better the processing power of a $5 million SGI Reality Monster mainframe install in 2000. a 500:1 price decrease over 7 years.
That would make the $100,000 monitor a cool $200 in 2009. I don't feel like running the exponential curve to project that to a year from now, but I don't think that wait will be a long one. They will still be expensive, but we bought $4,000 22" cinema displays 5 years ago and $15,000 32" plasma screens, we will jump at a $5,000 30" 300dpi monitor when they get here.
And I just responded to one of your posts in the OpenGL 2.1 thread that next years 8-core CPU desktop with a paired SLI GPU will equal or better the processing power of a $5 million SGI Reality Monster mainframe install in 2000. a 500:1 price decrease over 7 years.
That would make the $100,000 monitor a cool $200 in 2009. I don't feel like running the exponential curve to project that to a year from now, but I don't think that wait will be a long one. They will still be expensive, but we bought $4,000 22" cinema displays 5 years ago and $15,000 32" plasma screens, we will jump at a $5,000 30" 300dpi monitor when they get here.
That's very funny, but?no.
Will this have a good effect or any effect on the Zoom feature in Mac OS X? You know the nifty one with the Mighty mouse scrollball. In other words will text be clear when you Zoom in on it?
Resolution independence doesn't help there. But higher resolution displays would.
I think you misunderstood his question. He meant, when using the accessibility zoom function on the screen, will text still look pixelated when blown up, and the answer is that no, it won't because it will be rerendered as a vector at higher rez rather than just expanding the prerendered bitmap.
So in fact the answer to his question is yes, this will help make zoomed text clearer.
Socrates
So would this mean you could build applications with vector-based interfaces?
You already can. It does mean there's a bit more reason to do so, now...
Incorrect. OS X does not use any vector-based widgets. Rather, with Tiger and Leopard, Apple has been introducing much-higher-resolution widgets, to the point that you simply can't tell any more that they're scaled pixel graphics.
Wrong.
Apple are already recommending vector based widgets. They're not appropriate for everything, and for the rest a high resolution bitmap will do. PDF is the vector format of choice, and they're pushing hard to make developers use it for widgets
no, actually i think that's exactly where it would be of benefit. the display zooming in osx is a nice feature but it looks like hell right now because all the text and widgets are displayed as rasters. so display zoom up to the toolbar or in a webpage and the text gets bitmappy looking. resolution independence would keep all of those elements perfectly smooth at any magnification.
Sadly, it does not seem like the zoom feature is tied in to the resolution independence API. I wish it was.
Am I missing something here?*
Wouldn't Photoshop have a problem with resolution independence? If Leopard let's me set-up my display as taking advantage of 150ppi resolution screen then what is Photoshop to do with it? Especially at 100 % magnification which is supposed to be 1 pixel = 1 pixel display -- wouldn't that mean that a 72 ppi photo would take up roughly half the screen real estate that the same photo would take up on a 72 ppi screen? It would seem that editing a 72 ppi icon for a website would become very difficult on a screen that was running at 150 ppi.
If I don't get it, please explain it to me.
You have the right idea, just an incorrect assumption. "100 % magnification ... is supposed to be 1 pixel = 1 pixel display" -- that assumption was true before resolution independence but is no longer true.
What happens is an image will look the same physical size (e.g. 1 inch wide) regardless of the pixel density of your display. So if your screen is running at 150 ppi, the photo will look the same size as on a 72 ppi screen, but will be using twice as many pixels to display. Currently, on the aformentioned 150 ppi screen, the photo would display at half the size as on a 72 ppi screen.
So you're saying that there would be, or could be, in essence two different resolutions at play in a Photoshop screen...one for the menu items and another for the file display.*
Or perhaps it's more like the menus could take advantage of a capability that the file display area couldn't?
In either case, it could solve some problems with the palette displays in Photoshop, Illustrator and InDesign, allowing them to be smaller and still be legible.
What he's saying is that the resolution independence scaling stuff will be applied to the file itself... because the OS applies it to everything. But it will not give the user any benefit there.
Well, of course open documents in Photoshop would still be pixel-for-pixel (at 100% mag). It would be a rediculous implementation of resolution independance to not allow the application decide what elements of it's interface can be scaled.
"Not all applications will rev to support resolution independence in the short term, but we still want to offer a reasonable experience in unmodified applications when the user has chosen a non-1.0 scale factor. To this end, HIToolbox automatically "magnifies" windows that are not resolution independence savvy."
Photoshop could decide that its image windows not be scaled... although they'll look stupidly out of place in the new OS. To do so, they would have to explicitly specify that. Resolution independence is opt-out, not opt-in. (And only carbon apps can opt out. Cocoa apps have no choice!)
I think you misunderstood his question. He meant, when using the accessibility zoom function on the screen, will text still look pixelated when blown up, and the answer is that no, it won't because it will be rerendered as a vector at higher rez rather than just expanding the prerendered bitmap.
So in fact the answer to his question is yes, this will help make zoomed text clearer.
Socrates
Well, I'd like to hope so, but currently the zoom expands the bitmap screen buffer, rather than re-rendering anything. Perhaps this will change...
Wrong.
Apple are already recommending vector based widgets. They're not appropriate for everything, and for the rest a high resolution bitmap will do. PDF is the vector format of choice, and they're pushing hard to make developers use it for widgets
Where the heck do you see vector-based widgets, and if Apple are "recommending" them, why aren't they using them, but instead using higher-resolution versions of the same old widgets?
MS can often claim they've done something first and that others copied...but MS puts out so many inept implementations that it would be stupid to say MS put it out first.
It's always the same old story on Mac/PC boards such as Ars Technica. "MS had Exposé first". This last example is someone talking about the Windows feature that allows one to tile windows on screen without any overlaps. Can you imagine? There are countless examples where people compare shitty implementations to OS X implementations and claim they were the first to do it.
Apple will get it right...it won't bring us some dastardly interface that offers a few different sizes with pixelated icons and window content that doesn't even scale with the rest of the interface widgets.
I totally agree! From now on lets use the phrase, "Apple was the first to do it right."
You have the right idea, just an incorrect assumption. "100 % magnification ... is supposed to be 1 pixel = 1 pixel display" -- that assumption was true before resolution independence but is no longer true.
What happens is an image will look the same physical size (e.g. 1 inch wide) regardless of the pixel density of your display. So if your screen is running at 150 ppi, the photo will look the same size as on a 72 ppi screen, but will be using twice as many pixels to display. Currently, on the aformentioned 150 ppi screen, the photo would display at half the size as on a 72 ppi screen.
As to displaying the image in its assigned size, will this require additional information that is not currently encoded in the file?
If a file is designated as being 72x72 pixels and it is then displayed on a resolution independent screen, does the file need to contain additional information to tell the OS to display as a 1x1 inch file, or is that the assumption (72 pixels = 1 inch) built into resolution independence?
Could this cause any significant overhead processing with older apps? If the OS is having to run these calculations on the fly, would this add to its processing load, i.e. more Rosetta style slow-downs?
Thanks for the info.
As to displaying the image in its assigned size, will this require additional information that is not currently encoded in the file?
If a file is designated as being 72x72 pixels and it is then displayed on a resolution independent screen, does the file need to contain additional information to tell the OS to display as a 1x1 inch file, or is that the assumption (72 pixels = 1 inch) built into resolution independence?
You are right, many image formats don't contain the physical size that I am aware, so they would have to assume 72 unless otherwise told. My installations of Photoshop assumes 72 unless I tell it otherwise, on a per-image bases. Also, the display's size information is apparently unreliable so if the user wants accuracy, they would have to punch that information in too.
Could this cause any significant overhead processing with older apps? If the OS is having to run these calculations on the fly, would this add to its processing load, i.e. more Rosetta style slow-downs?
I don't think it would put a major load on the CPU, it might be done in the GPU.