Luminous Landscape Forum
Raw & Post Processing, Printing => Adobe Lightroom Q&A => Topic started by: RikkFlohr on July 26, 2016, 11:04:00 am
-
http://blogs.adobe.com/lightroomjournal/2016/07/lightroom-cc-2015-6-1-now-available.html
-
http://blogs.adobe.com/lightroomjournal/2016/07/lightroom-cc-2015-6-1-now-available.html
Page Not Found in the link
Edit: Nevermind, fixed now...
-
Thank you for letting us know Rikk.
-
Thanks, Rikk !!! Hopefully it will show up in my CC app soon and I'll be able to update.
-
Thanks, Rikk !!! Hopefully it will show up in my CC app soon and I'll be able to update.
Ron,
The update did not show up until I refreshed the CC App. After doing that it showed up.
Cheers!
Stu
-
Can anyone confirm that this update does indeed fix the OS X color sync printing issue?
I'm not going to jump in early ... I've wasted too much time rolling back of late.
-
Can anyone confirm that this update does indeed fix the OS X color sync printing issue?
I'm not going to jump in early ... I've wasted too much time rolling back of late.
Yes it does.
But Adobe makes it darn difficult to tell WTF they are going to do when you select to update in the CC app. Here's a copy and paste I just wrote publicly on the Adobe Family web site out of more frustration in how this is supposed to work:
It is incredibly difficult to figure out what you folks are telling us is the latest version to download based on the CC app. It does tell me there's a new version. When I click on "What's New" link from the CC menu item (Mac) it takes me to a page that doesn't tell me anything like what the version is I'm going to download or the fixes, just 'newer' features in general. This URL is far more specific and what I'd expect CC would take me to: http://blogs.adobe.com/lightroomjournal/2016/07/lightroom-cc-2015-6-1-now-available.html (http://blogs.adobe.com/lightroomjournal/2016/07/lightroom-cc-2015-6-1-now-available.html)
I do have a previous release with the print bug fix you folks supplied me to test. All I see in Get Info on the Mac is this: (Build 1083169) and Adobe Lightroom [1083169]. But in this newer version, selecting "about Lightroom" tells me this is version 2015.6.1 so I'm not sure why CC thinks I need an update. I will do so but now I'm not sure if I need to print and measure targets again just to ensure all is well.
Could you people perhaps consider putting that useful info (2015.6.1) in the Get Info window too? Build 1083169 is meaningless in comparison.
Oh, in the CC app, after selecting update, all it shows me is "You're updating to CC 2015". Big engineering to tell me EXACTLY what version ( 2015.6.1 )?
-
Yes it does.
Thanks Andrew,
So I'm guessing the problem wasn't an OS X or Printer driver issue?
-
So I'm guessing the problem wasn't an OS X or Printer driver issue?
That was Adobe's fantasies and no, it was purely a bug of their own creation for both Photoshop and LR (the former is fixed too FWIW). In fact, Apple's Preview and ColorSync utility printed correctly and much like my 'control', Photoshop CS6. Simply ridiculous to think this was an Apple bug or a print driver bug.
-
The update did not show up until I refreshed the CC App. After doing that it showed up.
still not showing up for me, refreshed CC app, also tried logging out of CC app and logging back in.
-
Yes it does.
But Adobe makes it darn difficult to tell WTF they are going to do when you select to update in the CC app. Here's a copy and paste I just wrote publicly on the Adobe Family web site out of more frustration in how this is supposed to work:
It is incredibly difficult to figure out what you folks are telling us is the latest version to download based on the CC app. It does tell me there's a new version. When I click on "What's New" link from the CC menu item (Mac) it takes me to a page that doesn't tell me anything like what the version is I'm going to download or the fixes, just 'newer' features in general. This URL is far more specific and what I'd expect CC would take me to: http://blogs.adobe.com/lightroomjournal/2016/07/lightroom-cc-2015-6-1-now-available.html (http://blogs.adobe.com/lightroomjournal/2016/07/lightroom-cc-2015-6-1-now-available.html)
I do have a previous release with the print bug fix you folks supplied me to test. All I see in Get Info on the Mac is this: (Build 1083169) and Adobe Lightroom [1083169]. But in this newer version, selecting "about Lightroom" tells me this is version 2015.6.1 so I'm not sure why CC thinks I need an update. I will do so but now I'm not sure if I need to print and measure targets again just to ensure all is well.
Could you people perhaps consider putting that useful info (2015.6.1) in the Get Info window too? Build 1083169 is meaningless in comparison.
Oh, in the CC app, after selecting update, all it shows me is "You're updating to CC 2015". Big engineering to tell me EXACTLY what version ( 2015.6.1 )?
I don't know what the problem is. We both probably received the same beta to test early last week (and I can confirm it works fine). Anyhow, if you click on "Lightroom" and then on "About Adobe Photoshop Lightroom" you get a credits screen that looks like the attached, and in small print under the title it says "2015.6.1". The defective version was 2015.6 (without the point-one). So it's pretty clear what's what, provided the official release is also 2015.6.1.
-
I don't know what the problem is.
Problem 1 is the CC app which doesn't tell us the exact version (it doesn't show 2015.6.1).
Problem 2 is in the CC app, when you want to know what's new, you're taken to a general site about LR and it's general newer features. There's nothing there that tells you about what this dot release provides.
Problem 3 is Adobe can't seem to put the version number into the Get Info dialog on Mac and rather tells us something useless: Adobe Lightroom [1083169]
Problem 4 for me (and maybe you) is that the CC app thinks there's a new update even though we have it and worse, can't install it. I had to do an Uninstall then use the CC app to install the 'official' version.
Problem 5 is I don't trust this new version per se so yes, I'm measuring targets again (wet, close enough) to be absolutely sure what's getting downloaded by the Adobe CC app really is a fix.
-
That was Adobe's fantasies and no, it was purely a bug of their own creation for both Photoshop and LR (the former is fixed too FWIW). In fact, Apple's Preview and ColorSync utility printed correctly and much like my 'control', Photoshop CS6. Simply ridiculous to think this was an Apple bug or a print driver bug.
From what I understand reading various posts, the reality is a bit more complicated, but the responsibility isn't. I understand based on what I read in the Adobe Forum that the problem started with Apple deleting or amending some APIs that affected LR and PS for Mac OSX. I also understand that when Apple intends to make these changes, they provide them to developers about six months before publication allowing those developers to update their applications as necessary. If this is all correct, then one could credibly surmise that Adobe did not implement the necessary modifications to LR and PS print pipelines correctly, and also failed to adequately quality check their implementation. As I've mentioned elsewhere, in the final analysis, unless each developer remains responsible for their own applications, there is chaos; and if implementing that responsibility requires collaboration with the OS provider so be it. Now, even if Apple had not provided enough time or information to assure a faultless updating at Adobe, one could also credibly argue that with proper QA, the issue would have been detected before release and the two companies would talk enough to fix whatever. Anyhow, all this is now history.
Not to say history should be dismissed - we can do so as consumers provided the product is now OK, which I think it is; however, for the company it is a different story. There is something in the corporate environment (generally, not specific to any one industry) called "Lessons of Experience". I've lived through years of this, so I have a pretty clear view of what it involves. The basic philosophy is that when screw-ups occur, which for all kinds of reasons they can, it's important to diagnose exactly what happened, how, why, and what could have been done, with the benefit of hindsight, to apprehend them. The more thorough and probing the analysis, the more useful the results. The findings go into a report which becomes part of the corporation's "institutional memory". Then the next time a similar project or set of actions comes up, it is the responsibility of the quality checkers to make sure the project team has reviewed the relevant "Lessons of Experience" and taken the indicated measures to prevent a re-occurrence. One fervently hopes that Adobe has or will have such internal "Lessons of Experience" procedures in place to minimize the risk of future issues interfering with the smooth transition of the applications from one version to the next.
-
Testing the new release (2015.6.1) versus the control (Photoshop CS6) but assigning Adobe RGB rather than sRGB to the target. PRINTS 'wet' right out of the printer!!!!
--------------------------------------------------
dE Report
Number of Samples: 700
Delta-E Formula dE2000
Overall - (700 colors)
--------------------------------------------------
Average dE: 0.69
Max dE: 2.60
Min dE: 0.02
StdDev dE: 0.39
Best 90% - (629 colors)
--------------------------------------------------
Average dE: 0.61
Max dE: 1.19
Min dE: 0.02
StdDev dE: 0.29
Worst 10% - (71 colors)
--------------------------------------------------
Average dE: 1.46
Max dE: 2.60
Min dE: 1.20
StdDev dE: 0.33
--------------------------------------------------
Higher max dE than using sRGB with dry targets. Need to let targets dry but it appears that the build from the CC servers has a fix (it's not a dE of 16)!
Will update finding after giving targets some time to dry. It's not uncommon to see a dE of over 1 with a wet target.
-
From what I understand reading various posts, the reality is a bit more complicated, but the responsibility isn't. I understand based on what I read in the Adobe Forum that the problem started with Apple deleting or amending some APIs that affected LR and PS for Mac OSX.
I am not buying that Mark. And I'm getting data directly, behind closed doors, from Adobe engineers (yes, originally that was their story and no, they are not unofficially sticking to it).
It makes zero sense that Apple would do this yet NOT fix their own two app's that print.
It makes zero sense that Adobe released two products with a broken print path and had to have end users bring it to their attention IF what they reported about Apple and print drivers were true.
-
Problem 1 is the CC app which doesn't tell us the exact version (it doesn't show 2015.6.1).
Problem 2 is in the CC app, when you want to know what's new, you're taken to a general site about LR and it's general newer features. There's nothing there that tells you about what this dot release provides.
Problem 3 is Adobe can't seem to put the version number into the Get Info dialog on Mac and rather tells us something useless: Adobe Lightroom [1083169]
Problem 4 for me (and maybe you) is that the CC app thinks there's a new update even though we have it and worse, can't install it. I had to do an Uninstall then use the CC app to install the 'official' version.
Problem 5 is I don't trust this new version per se so yes, I'm measuring targets again (wet, close enough) to be absolutely sure what's getting downloaded by the Adobe CC app really is a fix.
OK - now I see where you are coming from:
Problem (1): correct, and they should.
Problem (2) is that they haven't updated the "What's New" page when you go for "More information", so the version history is incomplete and there we are stuck. I assume we are supposed to take their word for it that we are now installing 2015.6.1. - perhaps OK, but one likes the reassurance anyhow.
Problem (3); More generally, I don't understand why 2016 versions are still being called 2015 and yes, the exact version and build numbers for apps should be in "Get Info".
Problem (4): I was pre-advised to uninstall the test version before downloading the commercial version, because once we download from a separate source, CC loses track. However, this is not an issue that will affect anyone other than application testers. We are meant to suffer through the hoops :-)
Problem (5): Out of abundance of caution one can of course re-measure as you are doing, but I'm more of the view that if what they posted differs in any way from what they sent us, we would/should have been pre-advised. As you are anyhow doing it, I'll wait for your final outcome before either installing or testing the commercial update release - on dry prints.
-
As you are anyhow doing it, I'll wait for your final outcome before either installing or testing the commercial update release - on dry prints.
Well with an average dE of 0.69 with this new build, I'm 99.99% sure it's fixed. Yes, the max dE of one patch is 2.60 rather than 16 and I think that's the dry down issues. As far as I'm concerned, whatever Adobe's servers are providing us is a fix to this print bug. PS should be coming soon too. So for LR, download and print away.
-
I am not buying that Mark. And I'm getting data directly, behind closed doors, from Adobe engineers (yes, originally that was their story and no, they are not unofficially sticking to it).
It makes zero sense that Apple would do this yet NOT fix their own two app's that print.
It makes zero sense that Adobe released two products with a broken print path and had to have end users bring it to their attention IF what they reported about Apple and print drivers were true.
That's OK Andrew, I guess in the final analysis we're not saying all that much different in terms of where responsibility ultimately rests. I would of course be curious to really know how this mess happened, because we are agreed that releasing apps with such defects makes zero sense, no matter how one slices or dices it.
-
I would of course be curious to really know how this mess happened, because we are agreed that releasing apps with such defects makes zero sense, no matter how one slices or dices it.
This mess happened like all bugs. Some engineer made a mistake, they are human. WHY the mistake wasn't detected in TWO major app's before a release is a more interesting question to me.
-
This mess happened like all bugs. Some engineer made a mistake, they are human. WHY the mistake wasn't detected in TWO major app's before a release is a more interesting question to me.
Yes, that is the key question indeed, and why I suggested the company needs to develop lessons of experience - in which there would probably be a key focus on QA and Product Management.
-
Yes, that is the key question indeed, and why I suggested the company needs to develop lessons of experience - in which there would probably be a key focus on QA and Product Management.
It's a lesson they were well aware of and followed for decades but have forgotten in recent years. That's not to say Adobe never released software with bugs. It was far less often and when it happened, they didn't go out of their way to blame others. But on the other side of the coin, I give Adobe kudo's for getting this bug fixed rather quickly. A silver lining.
-
I give Adobe kudo's for getting this bug fixed rather quickly. A silver lining.
Yes I agree. Once they took ownership of the problem the fix was very quick.
-
I understand based on what I read in the Adobe Forum that the problem started with Apple deleting or amending some APIs that affected LR and PS for Mac OSX. I also understand that when Apple intends to make these changes, they provide them to developers about six months before publication allowing those developers to update their applications as necessary.
From what I read, the colorsync API’s Adobe has claimed were involved were declared deprecated with Snow Leopard (10.6) which was several years ago.
However, what I don’t understand is if were Apple API’s that were involved, why it broke for everyone. I don’t think Apple removed any of those API’s in a dot release of El Capitan, as typically they are removed only on a major release and developers are notified they are End of Life. If so it would only affect those on the most recent version of the OS. I think I was still on 10.11.4 when LR 2015.6 was released, I’m sure there were others on older versions.
-
This mess happened like all bugs. Some engineer made a mistake, they are human. WHY the mistake wasn't detected in TWO major app's before a release is a more interesting question to me.
I agree who heartedly on both points. I don't expect everything that Adobe releases to be pure perfection, but I would expect them to have at least a few of their testers that print from Ps and Lr using OS X. This could have been caught very early on with just a bit of forethought.
-
From what I read, the colorsync API’s Adobe has claimed were involved were declared deprecated with Snow Leopard (10.6) which was several years ago.
However, what I don’t understand is if were Apple API’s that were involved, why it broke for everyone. I don’t think Apple removed any of those API’s in a dot release of El Capitan, as typically they are removed only on a major release and developers are notified they are End of Life. If so it would only affect those on the most recent version of the OS. I think I was still on 10.11.4 when LR 2015.6 was released, I’m sure there were others on older versions.
Well, now Andrew is advising that the real story is more about an engineering error than an API story, so........................ :-)
-
...........but I would expect them to have at least a few of their testers that print from Ps and Lr using OS X.
I hope you mean internal QA people, not external testers. I think first reliance should be on internal QA. External testers come after.
-
I hope you mean internal QA people, not external testers. I think first reliance should be on internal QA. External testers come after.
Yes, we can parse the verbal minutiae however you wish ... but the results of ANY prerelease testing anywhere by anyone with even remotely reasonable digital imaging skills would be a stark improvement over what is happening lately ... that and someone with better sense than to release an update on the day they are leaving for summer holiday break ... what were they thinking? Turn it lose then there is no one to deal with the problems when the update blows up?
-
Yes, we can parse the verbal minutiae however you wish ... but the results of ANY prerelease testing anywhere by anyone with even remotely reasonable digital imaging skills would be a stark improvement over what is happening lately ... that and someone with better sense than to release an update on the day they are leaving for summer holiday break ... what were they thinking? Turn it lose then there is no one to deal with the problems when the update blows up?
+1. And don't forget blaming two other companies for the issue! This nonsense from Adobe is still up!
https://helpx.adobe.com/x-productkb/multi/unexpected-colors-when-printing-mac.html (https://helpx.adobe.com/x-productkb/multi/unexpected-colors-when-printing-mac.html)
Edited recently, a bit, but still not an accurate account of the issue.
-
Notwithstanding all the issues that still remain for users to successfully download, install, and use Adobe's Compulsory Complexity suite of products, thank you Mark and Rodney for your huge contributions toward getting this one straightened out.
-
I agree who heartedly on both points. I don't expect everything that Adobe releases to be pure perfection, but I would expect them to have at least a few of their testers that print from Ps and Lr using OS X. This could have been caught very early on with just a bit of forethought.
We really don't know where the issue ultimately arose. Maybe the wrong version of software was released...one which still contained the bugs. I've seen software build issues which misplace the correct software and the final release is built with old code. The QA testers might have done their job, found the bug, developers fixed the code, but during the final build, the updated code was not used.
Bottom line we cannot jump to conclusions how this issue ultimately made it's way into the final release.
-
We really don't know where the issue ultimately arose. Maybe the wrong version of software was released...one which still contained the bugs.
Both LR and Photoshop? And AFAIK, both were released on different dates. Not impossible but not very likely.
IF the wrong version of both products was released, who's fault is that?
-
The QA testers might have done their job, found the bug, developers fixed the code, but during the final build, the updated code was not used.
Seems pretty unlikely to be the case when, as Andrew documents, they blame other parties, and provide unconvincing and disingenuous responses. Im not on the cc plan but I sympathise for those that are, and most of all champions ( certainly not "fanboys") of the Adobe products, who are fastidious in their own approaches and standards (eg Andrew and Mark)
Regards
Brandon
-
Bottom line we cannot jump to conclusions how this issue ultimately made it's way into the final release.
Bottom line is, if we are to use your explanation to defend the results of this latest release ... Adobe are either incompetent, inept or both. Either way, not a promising perspective that builds customer confidence.
There is no need to 'jump to conclusions' as there is ample evidence that once again, someone at Adobe we are paying to serve our needs, failed to live up to their end of the bargain. The fourth such occurrence since Lr CC 2015/v6 was introduced. Not to mention their first response was to place blame elsewhere instead of reviewing their own work first.
This problem seems to be systemic of late and not a result of isolated or unintended 'whoopsie daisy' mistakes that occurred by chance. It was a result that was due their failure to adhere to a more stringent level of quality checks and balance that could avoid the situation. It would be much more reassuring to we end users that they would hold themselves to a high standard. To them, we should be worth the effort.
-
Another issue that was resolved (in this or the previous release) is the one related to panoramas from HDR-DNGs. Now the resulting panorama does not show the warning "The image appears to be damaged"
-
Yes, we can parse the verbal minutiae however you wish ...
I'm not into "parsing verbal minutiae". In the interest of clarity I believe in the precise use of language.
-
I'm not into "parsing verbal minutiae". In the interest of clarity I believe in the precise use of language.
I really don't care who catches and reports the issue ... it should have been dealt with long before it was released to end users. It doesn't have to be any more precise than that.
-
Shoulda, coulda, woulda.... it's not a perfect world and Adobe didn't act perfectly. Congratulations for noticing that.
They've fixed the issue.
It would be lovely if the issue never happened. Seriously though what other aspect of your life is perfect and without error.
What we hope for is that they improve how they produce and release software and that we have fewer errors like this one in the future.
-
Anyone seeing marked improvement in performance?
https://www.slrlounge.com/speed-lightroom-important-lr-performance-news-flew-radar-amidst-lightroom-apple-tv-fuss/
-
What we hope for is that they improve how they produce and release software and that we have fewer errors like this one in the future.
Exactly! And hopefully this recent escapade and the resulting attention will do so.
-
Exactly! And hopefully this recent escapade and the resulting attention will do so.
Do you have any reason other than optimism to believe this Andrew? The only times I have seen Adobe respond to user issues by expending serious resources is when there is a competitive product, such as Aperture or Pixmantex Rawshooter in the case of Lightroom. The preferred approach seems to be to buy out competition as was done with Pixmantex.
-
Do you have any reason other than optimism to believe this Andrew?
Yeah. Being a beta for them, working with a lot of good folks there since 1992.
-
Bottom line is, if we are to use your explanation to defend the results of this latest release ... Adobe are either incompetent, inept or both. Either way, not a promising perspective that builds customer confidence.
There is no need to 'jump to conclusions' as there is ample evidence that once again, someone at Adobe we are paying to serve our needs, failed to live up to their end of the bargain. The fourth such occurrence since Lr CC 2015/v6 was introduced. Not to mention their first response was to place blame elsewhere instead of reviewing their own work first.
This problem seems to be systemic of late and not a result of isolated or unintended 'whoopsie daisy' mistakes that occurred by chance. It was a result that was due their failure to adhere to a more stringent level of quality checks and balance that could avoid the situation. It would be much more reassuring to we end users that they would hold themselves to a high standard. To them, we should be worth the effort.
Butch...you know all about quality control of huge software projects...right? You sound like someone talking from years of experience managing this software and under your management...perfection every time.
Oh yeh...you've never managed software...developed software...however you talk like an expert couch potato quarterback.
With huge software projects there are many modules that are in common between products. Maybe one of these common modules was the culprit that affected both builds.
-
Folks,
Try to keep this discussion civil and avoid personal attack. Continue and you will be banned from posting.
-
Butch...you know all about quality control of huge software projects...right? You sound like someone talking from years of experience managing this software and under your management...perfection every time.
Oh yeh...you've never managed software...developed software...however you talk like an expert couch potato quarterback.
With huge software projects there are many modules that are in common between products. Maybe one of these common modules was the culprit that affected both builds.
With all due respect, my lack of experience as a software project manager is not the issue. Name any business that requires the customer or end user must have first-hand knowledge of how a product is produced in order to render an opinion about the finished product they received? I don't remember Adobe imposing any such requirement when I hand over my license fees.
A customer in a restaurant is not required to be a master chef in order to render an opinion if their meal was prepared improperly or with questionable ingredients.
A new car buyer is not required to be master mechanic to offer a view about how they encountered a few loose nuts and bolts or other flaws that may have missed the eyes of the final inspectors.
A new home owner is not required to be a master carpenter to complain to the builder about a floor that is not level or windows and doors that won't open or close properly.
I fail to see your reasoning that I must be required to be a project manager for my concerns to be considered valid.
If you were to observe what I have shared in this thread you would note that I don't expect 'perfection every time' ... In fact I clearly stated:
I agree whole heartedly on both points. I don't expect everything that Adobe releases to be pure perfection, but ... I would expect them to have at least a few of their testers that print from Ps and Lr using OS X. This could have been caught very early on with just a bit of forethought.
That is not an unreasonable appraisal or assertion.
I could care less as to the details of what caused the problem. It is not my responsibility to discover or remedy the cause. That is up to whomever is assigned the responsibility at Adobe to ensure QA/QC. I pay those people to perform that task for me. My point is, the person(s) responsible for those tasks have dropped the ball in a consistent fashion of late. I have been forced to roll back to a properly functioning version of Lightroom on four separate occasions since CC 2015/v6.0 was introduced ... that's about half of the updates in that period ... that should be of concern to ALL Adobe software users. Regardless if some folks would prefer to impose qualifications on end users to discuss such matters.
-
The preferred approach seems to be to buy out competition as was done with Pixmantex.
So, Adobe does that once and suddenly that's Adobe's "preferred approach"? If you actually knew what went on with Pixmantic and why Adobe bought them it was not to kill a competitive product it was to steal the founding engineer, Micheal Jonsson, and bring him the USA to work for Adobe. Sadly, that didn't work out so well.
So, you're opinion about Adobe is your's and you are welcome to it, but it would be useful if was formed based on actual facts.
-
So, Adobe does that once and suddenly that's Adobe's "preferred approach"? If you actually knew what went on with Pixmantic and why Adobe bought them it was not to kill a competitive product it was to steal the founding engineer, Micheal Jonsson, and bring him the USA to work for Adobe. Sadly, that didn't work out so well.
So, you're opinion about Adobe is your's and you are welcome to it, but it would be useful if was formed based on actual facts.
Good to see you posting again Jeff. I agree Adobe seemed to want Micheal Johsson, but they also killed a product that was making serious inroads into market share. As I recall, when Jonsson started to work with Adobe his priorities were performance and reliability. Pity he did not stick around. As to your assertion that "Adobe does this once" have you so soon forgotten about Aldus Corp and Macromedia.
I respect your opinions Jeff and I believe you to be an honest broker. I'm not optimistic about the way Adobe is progressing, with poor judgement (import module) and numerous performance and reliability issues. The latest issue regarding mac printing had Adobe initially pointing the finger at others when the problem was theirs. Are you optimistic or are we watching the gradual demise of a company known for great, reliable, ergonomic products?
-
Rory, are you basing your Adobe pessimism on PS and Lr or on their entire product line (30+ products).
-
Rory, are you basing your Adobe pessimism on PS and Lr or on their entire product line (30+ products).
Lr, Ps and Bridge mainly.
-
As to your assertion that "Adobe does this once" have you so soon forgotten about Aldus Corp and Macromedia.
Well, is a merger a buyout? Yes, some of Aldus's portfolio of apps were discontinued but the flagship apps of PageMaker & After Effects are still developed and sold by Adobe. Freehand was sold to Macromedia as part of an anti-competition settlement. Ironic that Freehand ended up at Adobe after the Macromedia merger and has not been developed further.
But Adobe didn't do those mergers to kill competing products otherwise they would have killed PageMaker & After Effects. They merged with those companies for sound business reasons and these mergers were not hostile takeovers. Many of the officers and employees of Aldus and Macromedia ended up at Adobe and formed the core of much of the app development going on now.
The latest issue regarding mac printing had Adobe initially pointing the finger at others when the problem was theirs. Are you optimistic or are we watching the gradual demise of a company known for great, reliable, ergonomic products?
Well, the coding errors that were caused by Apple's yanking API's were Adobe's fault...but even Andrew and Mark would have to admit the bug was subtle and difficult to detect. Yes, somebody screwed up...they got called out, outside users proved the problem, they then admitted the problem and fixed it for Lightroom really, really fast (a lot faster than I was expecting) and will fix Photoshop in the next update.
Would I have preferred the engineer/s didn't screw up the print pipeline on Mac? Yes...am I surprised that it was a move by Apple to force all developers to change the API's they were successfully using until Apple made them change? Nope, not at all. This is far from the first time something Apple didn't screwed over Adobe and it's user base. As Andrew will tell you, Apple has continuously screwed over developers many, many times and over and over.
Was it Apple's fault that an Adobe engineer screwed up the code? Nope, but it was a code change that was forced by Apple. So far, I have't seen Apple implicated in this problem much, only Adobe. Note, Windows users have been blissfully printing away without this issue.
You all can keep harping on the mistake and ignore that facts and fail to enjoy the bug fix Adobe rushed out the door...in the meantime, I'm pleased I can now print out of Lightroom again :~)
-
Thanks for the info Jeff.
-
Hi Jeff,
I am pretty well aware of Apple making havoc of API's now and then and the colour management pipeline is often affected. So change is often forced by Apple.
But, Adobe's testing should have discovered the issue.
BTW, the minor new minor bugfix release of PhotoShop CS made a new install on my computer, so I need to move all my plugins to that new installation.
Best regards
Erik
Well, is a merger a buyout? Yes, some of Aldus's portfolio of apps were discontinued but the flagship apps of PageMaker & After Effects are still developed and sold by Adobe. Freehand was sold to Macromedia as part of an anti-competition settlement. Ironic that Freehand ended up at Adobe after the Macromedia merger and has not been developed further.
But Adobe didn't do those mergers to kill competing products otherwise they would have killed PageMaker & After Effects. They merged with those companies for sound business reasons and these mergers were not hostile takeovers. Many of the officers and employees of Aldus and Macromedia ended up at Adobe and formed the core of much of the app development going on now.
Well, the coding errors that were caused by Apple's yanking API's were Adobe's fault...but even Andrew and Mark would have to admit the bug was subtle and difficult to detect. Yes, somebody screwed up...they got called out, outside users proved the problem, they then admitted the problem and fixed it for Lightroom really, really fast (a lot faster than I was expecting) and will fix Photoshop in the next update.
Would I have preferred the engineer/s didn't screw up the print pipeline on Mac? Yes...am I surprised that it was a move by Apple to force all developers to change the API's they were successfully using until Apple made them change? Nope, not at all. This is far from the first time something Apple didn't screwed over Adobe and it's user base. As Andrew will tell you, Apple has continuously screwed over developers many, many times and over and over.
Was it Apple's fault that an Adobe engineer screwed up the code? Nope, but it was a code change that was forced by Apple. So far, I have't seen Apple implicated in this problem much, only Adobe. Note, Windows users have been blissfully printing away without this issue.
You all can keep harping on the mistake and ignore that facts and fail to enjoy the bug fix Adobe rushed out the door...in the meantime, I'm pleased I can now print out of Lightroom again :~)
-
Was it Apple's fault that an Adobe engineer screwed up the code? Nope, but it was a code change that was forced by Apple. So far, I have't seen Apple implicated in this problem much, only Adobe. Note, Windows users have been blissfully printing away without this issue.
You all can keep harping on the mistake and ignore that facts and fail to enjoy the bug fix Adobe rushed out the door...in the meantime, I'm pleased I can now print out of Lightroom again :~)
I've seen plugin developers use the same exact excuses explanations when Adobe makes changes in their API's. Sometimes, those changes seem to arrive for no good reason when the current method appears to be rock solid. Yet we all know, in order to advance, new foundations need to be built. The bottom line is, if any developer is going to support any partnering configuration ... they need to be prepared for updating and upgrading their code as technology advances. It's no secret that Apple has a history of making changes like this. It shouldn't come as a shock to anyone involved that they updated their printing API's.
Did Apple start the scenario that resulted in this issue occurring? Absolutely. However, it was Adobe that failed to fully test and recognize the issue before it reached we end users. And ... as I stated previously, for Lightroom, it has been the fourth such failure I have experienced in very recent history. It is fast becoming a pattern. A pattern that does not instill confidence.
Do I appreciate the quick response and correction of the issue? You betcha. Though, I would prefer that the good folks at Adobe would place that type of emphasis and productivity before they send me their updates. Then we end users, nor the engineers would have to be bothered with repairing such issues. Then I also wouldn't have to come here and share my dismay when my workflow is hampered or, at times completely broken resulting in rolling back to an earlier version.
If there are folks on this and other discussion forums who would prefer there to be less 'harping' and less failure to 'enjoy' the software Adobe produces ... all Adobe need do is scrutinize their work a bit more carefully before they send it our way. It's a rather simple solution.
-
... all Adobe need do is scrutinize their work a bit more carefully before they send it our way. It's a rather simple solution.
Methinks that is quite an oversimplification. There is no such thing as bug free software. ALL software is shipped with known bugs. You may not encounter them but they are real and every company is aware of them. The bugs are prioritized and many fixed over time. Consider how many lines of code are written over the years by a LOT of programmers in the software you use. How many people programming your favorite software do you think understand how every line of code works? Dang few if any.
Lest you think that software is imperfect but hardware is not just find the errata sheet or documents for your Intel or AMD CPUs. The latest CPUs have billions of transistors. There are bugs in the designs and there are manufacturing errors that escape test but you rarely notice it. They are there nonetheless.
Think about NASA and the systems they've sent into space. They have to correct the software errors mid mission, if they can. Sometimes they've been known to miss a planet or target simply because one programmer thought they were using kilometers and another miles. The Mars landers have been rebooted periodically because of unknown bugs and any other remedy. Sounds kind of like our computer operating systems doesn't it.
Perfection in these systems is not attainable. Squashing the most egregious bugs is the name of the game.
As you've seen in NASA and Adobe bugs appear that went undetected. Both organizations are staffed by very talented and well meaning humans and errors will happen.
Now sit back and enjoy your autonomous driving car while an aircraft on autopilot flies overhead.
-
Well, the coding errors that were caused by Apple's yanking API's were Adobe's fault...but even Andrew and Mark would have to admit the bug was subtle and difficult to detect.
For us, it was subtle but it depends on the color space of the image, the color content and a bigger issue, the printer. Some reported big visual differences on Canon. All my testing was done assigning sRGB to the target. The effect of the bug could be larger depending on what's assigned. And I don't buy this Apple yanking API's causing this bug for s second! It makes no sense and it doesn't explain why Apple's own products that print were not affected. No, I really believe that this is all Adobe's bug. And someone you and I both know there admitted to it. Lastly, no visible difference from the print path should change (which it did) and Adobe clearly didn't test this before release. We beta's are at fault to some degree; we all missed it. But if Adobe's going to release products solely based on outside beta's, they need to rethink how they run their internal quality control dept.
-
Methinks that is quite an oversimplification. There is no such thing as bug free software. ALL software is shipped with known bugs. You may not encounter them but they are real and every company is aware of them. The bugs are prioritized and many fixed over time. Consider how many lines of code are written over the years by a LOT of programmers in the software you use. How many people programming your favorite software do you think understand how every line of code works? Dang few if any.
Lest you think that software is imperfect but hardware is not just find the errata sheet or documents for your Intel or AMD CPUs. The latest CPUs have billions of transistors. There are bugs in the designs and there are manufacturing errors that escape test but you rarely notice it. They are there nonetheless.
Think about NASA and the systems they've sent into space. They have to correct the software errors mid mission, if they can. Sometimes they've been known to miss a planet or target simply because one programmer thought they were using kilometers and another miles. The Mars landers have been rebooted periodically because of unknown bugs and any other remedy. Sounds kind of like our computer operating systems doesn't it.
Perfection in these systems is not attainable. Squashing the most egregious bugs is the name of the game.
As you've seen in NASA and Adobe bugs appear that went undetected. Both organizations are staffed by very talented and well meaning humans and errors will happen.
Now sit back and enjoy your autonomous driving car while an aircraft on autopilot flies overhead.
You are exactly right. One of the big decisions with product management is when to release a product. There is always a huge list of known bugs that are prioritized and products are released with these known bugs. It would be impossible to continually release bug free code...show me a single example of bug free code.
It would be a great world if all bugs are detected and fixed prior to shipping, but how much is someone willing to pay for this?
-
We beta's are at fault to some degree; we all missed it. But if Adobe's going to release products solely based on outside beta's, they need to rethink how they run their internal quality control dept.
I don't accept that you beta's are at fault to any degree. It shouldn't be the role of beta testers to need to conduct elementary functionality reviews for software of this maturity. Your role should be to catch outlier situations and environments the developer cannot be expected to have dealt with, necessarily.
As I mentioned in reply #12, at this point, the most important and constructive aspect of all this for future releases would be for Adobe to carefully draw the "Lessons of Experience" and move forward with its internal procedures on this basis.
-
It would be a great world if all bugs are detected and fixed prior to shipping, but how much is someone willing to pay for this?
or wait for it
-
Hi,
I used to do a simple sanity test from time to time. Print a synthetic ColorChecker and measure the fields with my ColouMunki and calculate DeltaE vs. reference for all fields. That should indicate the problem. I would think that Adobe could apply a similar procedure?
Best regards
Erik
I don't accept that you beta's are at fault to any degree. It shouldn't be the role of beta testers to need to conduct elementary functionality reviews for software of this maturity. Your role should be to catch outlier situations and environments the developer cannot be expected to have dealt with, necessarily.
As I mentioned in reply #12, at this point, the most important and constructive aspect of all this for future releases would be for Adobe to carefully draw the "Lessons of Experience" and move forward with its internal procedures on this basis.
-
I used to do a simple sanity test from time to time. Print a synthetic ColorChecker and measure the fields with my ColouMunki and calculate DeltaE vs. reference for all fields. That should indicate the problem. I would think that Adobe could apply a similar procedure?
Yeah although 24 samples really isn't ideal. They should have an Auto Spectrophotometer and the ability to measure a couple hundred color patches and then something to report the dE between the two.
-
Methinks that is quite an oversimplification. There is no such thing as bug free software. ALL software is shipped with known bugs. You may not encounter them but they are real and every company is aware of them. The bugs are prioritized and many fixed over time. Consider how many lines of code are written over the years by a LOT of programmers in the software you use. How many people programming your favorite software do you think understand how every line of code works? Dang few if any.
Please spare me the lecture on nothing is perfect and how difficult Adobe's job is ... if you have been following the thread, you would have observed that I do not now, nor have I ever, expected perfection from Adobe or any other entity.
Yes, all software has bugs. But this latest bug wasn't a peculiar outlier that only affected a few end users with oddball configurations ... this bug was problem for EACH AND EVERY USER OF OS X who wished to print with the application controlling the color management.
I know a coders job is difficult. That is why I buy software licenses instead of developing my own apps. It also doesn't explain how other developers with far fewer resources updated the Apple API's and resulted in no issues for their end users to print properly.
I go to great efforts to produce photos, graphic designs and other services that my clients don't aspire to provide for themselves.
While I know I don't achieve pure perfection either ... I do have a QA/QC system in place so that the products I produce meet a minimum requirement ... before those products and/or services are delivered.
More importantly, when a problem arises ... my fist effort is not to point my finger at someone else. I take responsibility and remedy the situation to the best of my ability and don't try to rationalize that my customers should accept a certain level of poor quality work because my job is difficult to perform.
-
I've been following the thread from the beginning as I'm an OS X user who prints from Lightroom as well and was impacted by this bug.
I'll spare you the lecture if you'll spare us from stuff like
"all Adobe need do is scrutinize their work a bit more carefully before they send it our way. It's a rather simple solution."
It's not at all simple. It isn't just about coders. It's about everyone who is involved in delivering a software product to market.
-
It's not at all simple. It isn't just about coders. It's about everyone who is involved in delivering a software product to market.
While it may not be simple ... it surely isn't impossible either as other developers (once again ... with far less resources) didn't seem to encounter the same difficulty in updating the APIs.
I could have much more sympathy for Adobe's plight, if there were not examples to the contrary.
-
Yeah although 24 samples really isn't ideal. They should have an Auto Spectrophotometer and the ability to measure a couple hundred color patches and then something to report the dE between the two.
"Ideal" I won't query because I don't know what standard you have in mind for that, but the 24 patch GMCC is satisfactory for determining basic outlier performance issues.
-
While it may not be simple ... it surely isn't impossible either as other developers (once again ... with far less resources) didn't seem to encounter the same difficulty in updating the APIs.
I could have much more sympathy for Adobe's plight, if there were not examples to the contrary.
So you've never screwed up a photo shoot...never delivered something that you could have done better...something another photog would have done better.
Adobe rectified the issue in good time which is all we could really ask once the product was released with this issue.
-
So you've never screwed up a photo shoot...never delivered something that you could have done better...something another photog would have done better.
Adobe rectified the issue in good time which is all we could really ask once the product was released with this issue.
I'll refer you to my earlier comment:
Please spare me the lecture on nothing is perfect and how difficult Adobe's job is ... if you have been following the thread, you would have observed that I do not now, nor have I ever, expected perfection from Adobe or any other entity.
Yes, all software has bugs. But this latest bug wasn't a peculiar outlier that only affected a few end users with oddball configurations ... this bug was problem for EACH AND EVERY USER OF OS X who wished to print with the application controlling the color management.
I know a coders job is difficult. That is why I buy software licenses instead of developing my own apps. It also doesn't explain how other developers with far fewer resources updated the Apple API's and resulted in no issues for their end users to print properly.
I go to great efforts to produce photos, graphic designs and other services that my clients don't aspire to provide for themselves.
While I know I don't achieve pure perfection either ... I do have a QA/QC system in place so that the products I produce meet a minimum requirement ... before those products and/or services are delivered.
More importantly, when a problem arises ... my fist effort is not to point my finger at someone else. I take responsibility and remedy the situation to the best of my ability and don't try to rationalize that my customers should accept a certain level of poor quality work because my job is difficult to perform.
As I have said before, Adobe would very likely have not had to go through the steps to rectify the situation (Something I clearly said I appreciated) if they had applied just a bit more thorough inspection before they released v2015.6 ... there was no set in stone deadline to update the printing APIs for OS X. There was no rush to offer this update due to outside forces ... if it took another update cycle or two to ensure it was more stable and less problematic, wouldn't that have been better for everyone?
-
I know a coders job is difficult. That is why I buy software licenses instead of developing my own apps. It also doesn't explain how other developers with far fewer resources updated the Apple API's and resulted in no issues for their end users to print properly.
Adobe was quick to blame everyone including Apple.
But blaming API's from Apple when in fact the bug affected all users (it wasn't exclusive to El Capitan, or more logically the last update to El Capitan), and given the fact that Apple API's are normally removed only upon major OS releases, not dot releases, so nothing really changed on the OS side ... doesn't make sense,
but I do believe Adobe's intentions were good and they just didn't quite get it right. my guess is they were trying to remove reliance on the API's from Apple that were deprecated with the release of OS X 10.6 in 2009 (at least Adobe said these are the API's involved) , and it's very likely these API's have been marked end of life and will be removed in the upcoming release of Mac OS Sierra. This would have broken things for all users. (I usually download the beta's from Apple but have been too busy to play with Sierra). So Apple API's were sort of the issue, but not really Apple's fault.
I am puzzled about all the denial as well as some of the phantom "fixes" that popped up. It did seem to take them some time and some obvious proof from tests performed by others to admit the problem (tests which they should have immediately done themselves as soon as the issue surfaced). Bottom line they messed up ... better to just admit it.
And I was happy to see they agreed this was a serious enough problem it couldn't wait until their next normal release, something they did when they broke the Photoshop panomerge functionality (twice), and when they broke the ability to use droplets, both bugs which took them a long time to fix because they simply rolled the fix out in their next scheduled update. Kudos for jumping on this one quickly.
-
"Ideal" I won't query because I don't know what standard you have in mind for that, but the 24 patch GMCC is satisfactory for determining basic outlier performance issues.
Yes but not for providing a good average dE of the differences and where in color space which was necessary for Adobe (and useful for your article). IOW, I'd expect Adobe's Q&E to output hundreds of different color patches in different areas of color space and measure them with an auto Spectrophotometer, then use something like ColorThink Pro to report the differences in a more precise manner than you can with 24 patches,only one being outside sRGB Gamut.
-
Yeah although 24 samples really isn't ideal. They should have an Auto Spectrophotometer and the ability to measure a couple hundred color patches and then something to report the dE between the two.
A couple of years ago, Museo changed the paper stock for Portfolio Rag (my favorite paper to print on). I volunteered to do a color check for them and post the results publicly on LuLa as I had some of the 'older' stock still here. The sent me a 17x50 foot roll of the new stock (all I needed was about four letter sheets!) to do the test. I generated a 460 patch set which seemed to be a reasonable number of patches. I only have a i1Pro with the plastic scanning tablet that it mounts on and not anything automated. It maybe takes me 10 minutes maximum to scan the two sheets of targets and import the results into Excel for reading. This is really not rocket science and one hopes Adobe learns from this experience to minimally do some patch testing. It's not difficult.
-
Yes but not for providing a good average dE of the differences and where in color space which was necessary for Adobe (and useful for your article). IOW, I'd expect Adobe's Q&E to output hundreds of different color patches in different areas of color space and measure them with an auto Spectrophotometer, then use something like ColorThink Pro to report the differences in a more precise manner than you can with 24 patches,only one being outside sRGB Gamut.
An average is just an average, not good, not bad, but only as useful as the data underlying it and the dispersion around it. I agree with you that Adobe should/would be testing in more depth than achievable with 24 patches, but my point simply is that if a measurement of 24 patches already indicates relatively inaccurate reproduction of file values, we know (and indeed knew clearly from this) there's a problem. I also think there is something to be said for using a set of patches that are safely within the gamut the profilepaper/printer can reproduce, because once you exceed that gamut, it introduces gamut compression which itself drives inaccuracy between reference and printed values.
-
(...) It maybe takes me 10 minutes maximum to scan the two sheets of targets and import the results into Excel for reading. This is really not rocket science and one hopes Adobe learns from this experience to minimally do some patch testing. It's not difficult.
Alan,
You are obviously right and I suspect Adobe would not even need to go through the analogue loop to see that the values were off. They could simply print to an emulated printer (possibly even print to a PDF Writer) to see if the print module still outputs the same values compared to the previous build of the application (assuming the problem is not in the printer driver ;)).
This could be implemented in so called Unit Tests (programmer slang...) which are designed to run automatically every time that the application is recompiled. The lack of such automated tests is puzzling for a large software provider which apparently adheres to an agile programming method...
Cheers,
Fabien
-
An average is just an average, not good, not bad, but only as useful as the data underlying it and the dispersion around it.
I disagree. The larger the number of samples, then of course, the difference reported for average dE tells us more about the errors and how bad it is. It's one thing to see ONE patch with a high dE. It's another to see a large number of patches with a high average dE. You're working with a mere 24 patches and only one that's outside sRGB Gamut. It's quite possible using that small sample that you'll get a good looking dE report but have a nasty bug affecting colors you'd see in some situations. My reports, with lots more colors and patches told us where in color space, assigning sRGB to 700 patches, the problems showed up (lots of blue patches). In this kind of testing, more samples, to a point of course, just gives us more information.
I also think there is something to be said for using a set of patches that are safely within the gamut the profilepaper/printer can reproduce, because once you exceed that gamut, it introduces gamut compression which itself drives inaccuracy between reference and printed values.
Again I disagree. Anything outside the printer gamut gets clipped equally in both sets of prints you're measuring. This is an apples to apples test. We're simply looking to see differences in two print processes (CS6 versus CC) When one appears to have a bite taken out of the apple due to high average dE, that's telling.
-
I disagree. The larger the number of samples, then of course, the difference reported for average dE tells us more about the errors and how bad it is. It's one thing to see ONE patch with a high dE. It's another to see a large number of patches with a high average dE. You're working with a mere 24 patches and only one that's outside sRGB Gamut. It's quite possible using that small sample that you'll get a good looking dE report but have a nasty bug affecting colors you'd see in some situations. My reports, with lots more colors and patches told us where in color space, assigning sRGB to 700 patches, the problems showed up (lots of blue patches). In this kind of testing, more samples, to a point of course, just gives us more information.
Again I disagree. Anything outside the printer gamut gets clipped equally in both sets of prints you're measuring. This is an apples to apples test. We're simply looking to see differences in two print processes (CS6 versus CC) When one appears to have a bite taken out of the apple due to high average dE, that's telling.
Yes, one will see more with more patches. Interesting though how we both found where the error was most severe independently, you with more patches, me with fewer. It depends not only on the number of patches, but also on the properties and quality of the sample apart from its size, and in these respects the old GMCC seems not so slouchy. On the point abut clipping, depends on what one is comparing. If it's one version of an application with another, then as long as one assumes that they will clip in the same way, the comparison including OOG colours could be fine. However, if one is comparing between file values and printed values, I want to know my results are unaffected by the inevitable inaccuracy caused by colours that can't be printed regardless of how good the print pipeline is.
-
On the point abut clipping, depends on what one is comparing.
Of course. But not in this test where the idea is to illustrate that an application released years ago, and the update years later produce the same results.
-
Of course. But not in this test where the idea is to illustrate that an application released years ago, and the update years later produce the same results.
That's in your test. In my test I was comparing file reference values with the printed output from each application version and seeing which reproduced the file values the worst. Somewhat different approach but both aimed at detecting application flaws.
-
That's in your test. In my test I was comparing file reference values with the printed output from each application version and seeing which reproduced the file values the worst. Somewhat different approach but both aimed at detecting application flaws.
Mark, the idea for me, was to determine if there was a bug in the Adobe print path. The way I did this was by comparing a new build to an existing control I know works correctly (CS6/LR5). In that respect, the only data that's necessary is the differences in each color sample from each app. That's what my report shows. And exactly where in color space. And by how large a difference for every one of the 700 patches, it's average and more. And this is exactly what Adobe should have done and should do in the future. What I print today in CC should be identical (within reason, without an AVERAGE dE of ideally 1 or less) with what the next version produces. 24 patches isn't ideal in such testing, especially when only one of the mere 24 is out of sRGB gamut. It's entirely possible a print bug could show zero difference in such a small gamut working space.
-
It's entirely possible a print bug could show zero difference in such a small gamut working space.
But in this case it just so happened to have shown huge differences.
I understand exactly what you did and it's fine. What I did also worked very well and achieved the same objective. Is it possible that in extreme cases the smaller sample would fail to reveal a problem - I could imagine that being the case, but I also believe that a generic defect of the scope and extent we had would not (and did not) escape the 24 patch test either. More generally, I've been doing a lot of profile testing lately and that 24-patch set-up has been remarkably useful for distinguishing between more and less accurate renditions. I'm not saying more patches wouldn't be even better, just not to underestimate the usefulness of the GMCC sample.
-
I understand exactly what you did and it's fine.
It is, IMHO, how Adobe should be testing their output.
-
It is, IMHO, how Adobe should be testing their output.
I don't think lack of know-how is the issue in Adobe, even admitting that the best of us can and do screw-up periodically. I believe that if drilled down to basic causes, one would find we've been dealing with a set of management issues over the past several weeks (and some would argue many months given previous snafus). As I said before, those "lessons of experience" are really important to help steer a smoother path into the future. The question for them, as I perceive it, is whether they are prepared to delve into this in a manner that only they can do, or just continue to muddle through these episodes dismissing them as "one-offs" when they occur. Time will tell.