Lightroom 6.6.1/CC2015.6.1 Released

[rdonson]

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.

[ButchM]

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.

[Mark D Segal]

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.

[chez]

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.

[ButchM]

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?

[Wayne Fox]

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.

[digitaldog]

"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.

[Alan Goldhammer]

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.

[Mark D Segal]

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. 

[FabienP]

(...) 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

[digitaldog]

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.

[Mark D Segal]

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.

[digitaldog]

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.

[Mark D Segal]

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.

[digitaldog]

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.

[Mark D Segal]

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.

[digitaldog]

I understand exactly what you did and it's fine.

It is, IMHO, how Adobe should be testing their output.

[Mark D Segal]

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.