From my understanding of the DNG tech doc, the mosaic is retained in it's original form and is unaltered. I read the thing when I got the Mk2 as I wanted to archive a few shoots, after DNG supported it and before Apple did.
I did tests in DNG and RAW in Aperture on the mac 2 years ago when I got the 5D Mk2 and the files were identical. I exported them as PSD and did the difference calculation and they were pixel perfect dupes of each other. Your mileage may differ as they say, but you have to open both files in exactly the same way.
I thought long and hard about publishing a private message from Chris, but as it was no different from his forum entries, I decided to, along with my message of apology.
(My apology sent privately to Chris)
I wanted to offer an apology for some of the things I said in the recent forum thread.
A pressured deadline and failing software do not a good mix make. And been accused of lying over very real Adobe tech docs didn't help.
I managed to solve all the problem via google so in the end, despite lost time, things are almost back to normal and I managed to work something out with Spaces.
Just a thought. If PS is able to pull it's docs from other spaces in to it's correct space, as I've proved it can do, why not add it as an option? Not ideal but it's better than nothing.
You may hate Apple, they may even be wrong, but you could still make a life easier for people have invested in CS5 by thinking outside the box.
Again, there are NO APIs for Spaces -- the application does not know that Spaces is running, or have any way of dealing with Spaces.
I don't hate Apple - again, you made that up.
What I don't like is people who don't know what is going on blaming Adobe for something completely beyond Adobe's control.
Everything in Spaces - the bugs, and the features, is completely up to Apple.
We have no control over it.
(My apology sent privately to Chris and published here)
Thanks for the gracious reply Chris.
My workaround, if you read it, proves PS has some control over documents in Spaces, even if it's simply a quirk.
I didn't expect a hostile reply but there it is, and yet again you never read my words.
I said in my apology message, you MAY hate Apple, not that you did.
You said I made that up, as you did with the cross platform issue earlier on. I made up neither and repeatedly saying it won't make it true.
You may or may not hate Apple. It's not an assertion, more a possibility given the pain you clearly feel concerning their bugs and their impact on Adobe's reputation.
I said, none of my other software fails to switch to it's App space when I double click the doc in the finder. I asked what you were doing differently, as PS behaves differently from other Apps in that regard. The only other App that does that is Word, and that is well documented, and I believe, Microsoft and Apple worked to a solution within Word, not the OS. I may be wrong, but that's what I read.
I never said PS knew about Spaces, or that there were API's.
Please, please, stop saying I said one thing when I said another.
It's not right and it does not become someone of your education and experience.
I also said, PS can pull together doc windows that have got into other spaces, as my temp solution clearly showed if you read it. that shows PS, despite Apple's shortcomings, can affect docs lost in other Spaces.
I just figured, instead of blaming Apple, you could maybe utilise that ability in a more user friendly manner.
You know, for the sake of YOUR customers, not Apple. A quick, "bring doc windows back to PS" option. If I can do it with what's already there, why not save people the trouble of scouring the forums for solutions.
I was out of line in some of my messages, and I publicly acknowledged that, and personally apologised to you, but you still call me a liar and act in a hostile manner. Maybe that's your way. Maybe that's why I took exception to you.
I did find people through Goggle that found the same. Even found one person who asked you not to reply to any of his forum questions. I don't expect any support on here, these people either need you too much, or are your underlings, but I see an unapproachable, arrogance born from to much control.
You may make the software, but we pay for it, live with it's problems, and invest in it's upgrades.
I await your gracious apology for repeatedly calling me a liar for issues that are well documented on YOUR site.
I am in a certain amount of trepidation how hard it is to get a civil answer from a key PS developer.
Having Googled your forum replies going back many years on Google, I see I'm not the first to fail to get past that icy exterior. Even found someone who actually requested you didn't answer any of his questions on the forums --)
It's been an education Chris, and not the one I was hoping for.
A few further notes on Photoshop and Spaces.
Number of Spaces related APIs that Apple exposes to third party developers:
10.6: 1 - this is an API that let you ask "is this window in the current visible Space". In addition to this, Apple has added functionality that allows us to explicitly specify how a given Window should be interpreted by Spaces (in 10.5 this is implied).
Although 10.6 may not seem much better than 10.5, these changes do give 10.6 an edge when it come to Spaces, and I would personally recommend users of Photoshop & Spaces to consider using 10.6.x.
I can believe that CS3 and CS5 behaves differently, but that is likely to be caused by the fact that Carbon (which we use in CS3) and Cocoa (used in CS5) are different Apple technologies that may be using private Spaces SPIs differently.
The following is going to be vague as we do not have documentation from Apple describing the intended behavior of Spaces.
What we know, we learn from observation, and you should be aware that the Spaces functionality can change at any time (for example: in 10.5.4 Apple changed Spaces to allow the window that has keyboard input to be in a non active Space).
First note that Spaces is a technology that is window centric, meaning that the OSX window server looks at the windows of an application and determines what to do based on their "type". There is a distinction between document windows and UI windows. The typical, expected, behavior is that the user can place different document windows from an application in different Spaces. In order to allow the user to work on these documents (residing in different Spaces), an application will mark its UI windows as "show in the current active Space" meaning that when you activate a document window in Space X, then floating panels, toolbars, and control bars should also be visible in that same Space.
When you launch Photoshop out of the box you get the "non application frame" mode and in this mode there are no document windows. Therefore if you launch Photoshop, move to a different Space and then double click on a document in Finder, then Spaces will move your UI windows to the new (active) Space and open your new document in that Space.
As a test, quit and re-launch Photoshop. It will open in your preferred Space. Now turn on the Application frame (from the Window menu), and go to "Preferences > Interface" and turn off "Open Documents as Tabs". Now switch Space and double click on a Photoshop file. You will see that it correctly opens as a new floating document in your preferred Space.
This is because the application frame is a document window, and as such Spaces is able to switch back to your designated Space before the file is opened.
If I have an open document in Photoshop before I double-click on a file in Finder, then I also get a Space switch (to the Space that contains the active document). In this case, I see a z-order problem, where the document that was just opened does not appear at the top. I don't see the z-order problem without a Space change, and I therefore surmise that the z-order problem is cause by Spaces restoring windows incorrectly during an open/switch operation.
I am 90% sure that I saw in a bug that Apple was aware of the issue with applications that open without document windows, and that they had decided to not address the problem.
We'd like our users to be able to work with different documents in different Spaces, and as such the described behavior is the intended behavior by Apple.
Recovering "lost" documents - meaning move all documents to the active space, could also be done by the following:
- Choose Window > Arrange > Consolidate all to Tabs
- Choose Window > Arrange > Float all in Documents
Describing workflows related to Spaces is tricky, so I apologize in advance for any misunderstandings of your described workflows.
That is all great info and makes complete sense. I'd worked out the bring to tabs and float to windows would collect docs but the application frame means I no longer have to keep a token window open in PS in the correct Space.
Jesper, that was a great post and thank you kindly for taking the time to explain it, despite my not so great attitude over the last few painful days :-)
I respect Chris, apologised for my part in the diabolical and psycho exchange I got in to over it (me been psycho not Chris) but this was the kind of creative workaround I knew must be doable in PS if someone actually thought about it, accepted the limitations Apple have in this regard and thought about Adobe customers.
Had I known the Application frame would act as a an open document, that would have been ideal for my work around which used the following which you kindly confirmed works to bring lost docs back into line.
- Choose Window > Arrange > Consolidate all to Tabs
- Choose Window > Arrange > Float all in Documents
That was the best info and in addition to the above workaround, actually makes life in a Spaces environment very, very usable, in CS5.
Thank you so very much. Working in PS for hours on end, something like that can make the difference between it been a creative, fun time or a "i want to throw it out of the window" experience.
Again Jesper, big thanks.
I'm glad that my question has generated some discussion on this list. One of the last posts hit on some things that I wanted to inquire into. The thing about Photoshop as with MS Word is that they have two main components: 1) the frame of toolbars, and 2) the content window. OS X doesn't seem to be working with these two component in a way that is usual or expected. So, if you float an image inside PS's frame of toolbars (not sure what else to call it), the image behaves differently than the frame does, especially in spaces. The content can be moved to a space, but the frame doesn't come along for the ride. So content works with spaces but the program toolbar frame does not. The behaviour seems to be a bit different if you frame your content rather than float it. I find it very unexpected behaviour for a program to leave its content, but have the toolbar frame disappear when you click on the desktop beside the floating content! Is that a bug or is that intended behaviour? It seems to me that Adobe and Apple are not working together to make OS X play properly with CS5. No other program to my knowledge disappears when you click on the desktop! That strikes me as buggy behaviour. If a program is open and you click the desktop in OS X a program should remain floating in the window, NOT disappear. Has anyone reported this stuff or is this weirdness just expected on OS X?
I am not sure that I understand your question completely. A point of confusion is that Photoshop can work with or without an application frame, and this setting affects what you should expect to see.
If the application frame is turned off:
You move a document from Space 1 to Space 2 and then go to Space 2. You will see both your document and toolbars (and other UI) in Space 2.
If the application frame is turned on:
The application frame is in Space 1. You move a floating document from Space 1 to Space 2 and then go to Space 2 (you do not move the application frame away from Space 1). You will then see your document in Space 2 along with any UI that is not inside the application frame.
You will not see UI that is inside the application frame. This may be confusing, but is caused by the fact that an application frame acts both like a document window and a UI window (because it contains both documents and UI).
Therefore, if you work with documents across several Spaces, then you may want to consider to turn off the application frame.
You also ask: "... I find it very unexpected behaviour for a program to leave its content, but have the toolbar frame disappear when you click on the desktop beside the floating content! Is that a bug or is that intended behaviour.."
This seems like a question that is unrelated to Spaces and instead related to how floating UI windows behave on OSX. It is expected that floating UI windows are hidden when you switch to another application & when you click on the desktop you switch to Finder.
Thanx for the reply. You said a lot of interesting things in your post. However I'd like to say that I don't entirely agree with what you say at the end of your post. When you have ANY program running in OS X and the desktop is visible that program should never DISAPPEAR when you click on the desktop. It's true OS X switches to Finder, but this does not and should not affect whether a program window floating over the desktop should be hidden or disappear. This is NOT expected behaviour in OS X. Finder is visible in the menu bar and you can start a Finder window once you click on the desktop but no program window should be disappearing. PS is behaving in a way that is not expected. I think this is tied to the issue of Content windows and the UI Toolbars behaving as if they were separate, at least in Standard View, and this is why OS X Spaces is acting strangely. So, I think these issues are connected. If this is by design I personally fail to see the point. I would have expected a program to remain floating on the desktop until I instruct it to hide or minimize. If this is intentional then there should be an option to shut this behaviour off because it's quite annoying.
I guess that I am not entirely sure about what you mean when you say "disappear".
Neither floating documents, nor an application frame disappear when you click on the desktop. Floating UI windows disappear.
This is the same experience as you see if you to launch TextEdit, bring up the floating "Font" panel (by hitting command T), and then clicking on the desktop.
Yes that's the same behaviour. I find this behaviour odd for floating toolbars. The font preference pane in Textedit is not a floating toolbar like PS toolbars are. You are meant to set your font and close the pane out not leave it floating. I notice that if you use document frame and dock your toolbars this is not the behaviour. I take it this must be by design then? You click on the desktop so that the toolbars drop away and you can see more of the desktop when content windows are not framed? Is that the intention?
Yes it is by design.
One reason for this is that floating panels live above other windows. This is how they always stay above documents. If we did not hide them when you click on Finder, then you would find that your Photoshop toolbar (and other floating UI) would obscure (be in front of) your Finder windows (or your Mail windows).
Another reason is that if you use multiple applications, then it could be confusing to see UI windows that are unrelated to the current, active, application. Consider using Photoshop, Illustrator, and InDesign at the same time and having a layers panel floating in each application. If we did not hide panels for inactive applications, then you would see three layers panels at any given time. Clicking on the "wrong" panel would activate the application that then panel belongs to (and disrupt your work).
The net effect is less clutter on your desktop when you are not working with Photoshop.
Thanx again for your comments. You said that "If we did not hide them [PS toolbars] when you click on Finder, then you would find that your Photoshop toolbar (and other floating UI) would obscure (be in front of) your Finder windows (or your Mail windows)." I don't think I understand why the toolbars need to disappear the way they do as the fonts panel in textedit does when you click outside it. If finder was on top it would make more sense for the toolbars to take their place underneath finder, not disappear from the screen entirely. This strikes me as strange behaviour for a program. Why can't it just behave like a normal program window, or let me determine if I want it to disappear? Your argument seems to me to rely on a false choice between floating on top (top most) or disappearing from the screen. What about just floating unless you make another window active and then it could, like almost every other program except those you ask to always float on top, take its place underneath the active window!
You are correct in stating that the front argument is a consolidation of two separate issues:
- Cocoa has weak (actually no) good support for moving floating panels down into the document layer when the application deactivates (there are hacks, but they do not always work)
- Floating panels that exist in the document layer will still obscure icons on your desktop
The general idea is that (floating) UI exist to assist you in working with your current focus target. When Photoshop is in the background, you are targeting something else than a Photoshop document, so we hide the floating Photoshop UI.
(if you are interesting in Apple's take on floating UI, then you can read: http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/WinPanel/Concepts/U singPanels.html#//apple_ref/doc/uid/20000224 ).
Therefore, the current behavior is expected.
Besides posting on this forum, you may also use the following link to suggest new behaviors and features in Adobe products:
Does anybody else have issues with their entire system freezing and then logging out when switching Spaces with PS CS5 open? At first I thought it was an issue with Snow Leopard, but looking back I never had it happen when I had CS3. It only happens when I've got PS running, and it's a huge pain. Luckily it hasn't happened yet when I've had unsaved work, but I'm sure it will someday.
I haven't heard about this. If the system freezes & auto-logs out, then it is an Apple bug (because your error description indicates a failure in an OS service).
You may want to take a look in the OSX Console (in the utility folder).
The following assumes OSX 10.6.
See if you see anything that indicate a failure close to the time when your session froze.
Then click on "Show Log List"
- Navigate to FILES>"/private/var/log/windowserver.log" and look for suspicious entries.
- Navigate to FILES>"/private/var/log/system.log" and look for suspicious entries.
- Navigate to FILES>"/private/var/log/kernel.log" and look for suspicious entries.
Be aware that output to the console is hard to read, and most entries are perfectly harmless.
Since we have seen systemwide problems on OSX related to video card drivers, please make sure that your system is up to date.
Looking in the kernel.log I found this right around the time my system crashed:
Oct 15 12:28:24 Andrew-Philpotts-MacBook-Pro kernel: NVDA: Fatal error, failed to make a texture resident. GPU heap size is 666 MB with 6199 textures and 10 surfaces.
Oct 15 12:28:24 Andrew-Philpotts-MacBook-Pro kernel: The graphics driver has detected a corruption in its command stream.
My system is up to date, I update it frequently. I just don't understand why this never happened until I started using CS5 and why it only happens when PS CS5 is running unless it's in some way related.
This looks like a problem in your NVidia driver or in OSX.
CS5 uses OpenGL accelerated documents by default and this may trigger this bug (Expose & Spaces seem to also rely on OpenGL).
Try to go into your Photoshop preferences and Turn off "Enable OpenGL Drawing" in the Performance section.
You should also consider reporting this problem to Apple.