Re: Colorsync-users Digest, Vol 13, Issue 81
I still think you owe it to yourself to examine why you're so upset at the thought that Adobe products, which are excellent for their designed purpose, aren't useful for a purpose they were never designed for.
Except that Adobe¹s products are designed for colorimetric accuracy, and used for colorimetry rather often. Again, you are making a blanket statement based on one aspect of the products, and even that aspect is only based on your preferences, not the actual capabilities of the products. Your repeated incorrect statements are harming your reputation, and not helping anyone else on the mailing list (and may be doing damage to the understanding of others). Also, have you considered asking for better controls in ACR rather than just throwing around accusations?
In Photoshop, if you blend in a gamma 1.0 document,
First, that the default is anything other than gamma 1.0 blending demonstrates that whoever wrote the code doesn't understand what gamma is or what it's for. It's nothing more nor less than a form of data compression, a more efficient use of the bits on the disk.
No, it simply confirms that you confuse theory with practice and have little or no experience with actual practice of image processing or digital painting.
And then we've got the problem that gamma _is_ vital for the internal storage, and forcing people to use gamma 1.0 for internal storage just to do correct manipulation of it then opens them up to all the problems that gamma fixes in the first place.
That¹s why there has been an option to do blending in gamma 1.0 in Photoshop for many, many years (without changing the document colorspace). But, again, it really isn¹t a great idea if you are using 8 bits/channel because it will quickly lead to quantization artifacts. In 16 bit/channel gamma 1.0 blending may not be too bad, and in 32 bit/channel (floating point) it is the only option. We know how to work with gamma encodings quite well, but you are still trying to blindly apply theory to real world practice without understanding any of the issues involved. Instead of accusing people with more knowledge and experience than yourself of getting things wrong, you might want to ask WHY things are done the way they are done, so you can learn from the knowledge and experience of others.
And you are still making broad claims based on very narrow issues (many of your own making or misunderstanding).
Sorry, but you yourself are repeatedly pointing out the critical flaws in Photoshop and bragging about them as if they were features, not bugs.
You have not yet pointed out a flaw in Photoshop, only your own mistakes and misunderstandings (or confusing personal preference with capability). The comments about not enough precision on controls in ACR could be a feature request, but certainly not a flaw. The limited output spaces in ACR - ok, that can also be considered a feature request (although you already have minimally disturbed data in PhotoPhotoRGB). But you still seem to be going about all this in the worst possible manner. Simply asking for the features or asking for more information would help you far more than making obviously inaccurate statements on a public mailing list. Chris
Hmmm... perhaps "Adobe Products" (all of them) are designed for colorimetric accuracy, but please give examples of how they are used for colorimetry "rather often." The most common use (for digital photography) can't be an example, because the camera sensitivities are not linear transforms of the standard observer. So, are there Adobe Products (and which ones?) that are in use and special cameras that are standard-observer equivalent for these uses? Some examples, please. Also, it is obvious in using Photoshop or Lightroom for photography that an S curve is applied - just increase the exposure slider and watch the histogram bunch up on the right. So, what is the procedure for making these products act in a linear way so that actual colorimetry is possible (given camera sensitivities are appropriate)? Wayne Bretl -----Original Message----- From: colorsync-users-bounces+waynebretl=cox.net@lists.apple.com [mailto:colorsync-users-bounces+waynebretl=cox.net@lists.apple.com] On Behalf Of Chris Cox Sent: Thursday, March 17, 2016 7:41 PM To: colorsync-users@lists.apple.com Subject: Re: Colorsync-users Digest, Vol 13, Issue 81
I still think you owe it to yourself to examine why you're so upset at the thought that Adobe products, which are excellent for their designed purpose, aren't useful for a purpose they were never designed for.
Except that Adobe¹s products are designed for colorimetric accuracy, and used for colorimetry rather often. Again, you are making a blanket statement based on one aspect of the products, and even that aspect is only based on your preferences, not the actual capabilities of the products. Your repeated incorrect statements are harming your reputation, and not helping anyone else on the mailing list (and may be doing damage to the understanding of others). Also, have you considered asking for better controls in ACR rather than just throwing around accusations?
In Photoshop, if you blend in a gamma 1.0 document,
First, that the default is anything other than gamma 1.0 blending demonstrates that whoever wrote the code doesn't understand what gamma is or what it's for. It's nothing more nor less than a form of data compression, a more efficient use of the bits on the disk.
No, it simply confirms that you confuse theory with practice and have little or no experience with actual practice of image processing or digital painting.
And then we've got the problem that gamma _is_ vital for the internal storage, and forcing people to use gamma 1.0 for internal storage just to do correct manipulation of it then opens them up to all the problems that gamma fixes in the first place.
That¹s why there has been an option to do blending in gamma 1.0 in Photoshop for many, many years (without changing the document colorspace). But, again, it really isn¹t a great idea if you are using 8 bits/channel because it will quickly lead to quantization artifacts. In 16 bit/channel gamma 1.0 blending may not be too bad, and in 32 bit/channel (floating point) it is the only option. We know how to work with gamma encodings quite well, but you are still trying to blindly apply theory to real world practice without understanding any of the issues involved. Instead of accusing people with more knowledge and experience than yourself of getting things wrong, you might want to ask WHY things are done the way they are done, so you can learn from the knowledge and experience of others.
And you are still making broad claims based on very narrow issues (many of your own making or misunderstanding).
Sorry, but you yourself are repeatedly pointing out the critical flaws in Photoshop and bragging about them as if they were features, not bugs.
You have not yet pointed out a flaw in Photoshop, only your own mistakes and misunderstandings (or confusing personal preference with capability). The comments about not enough precision on controls in ACR could be a feature request, but certainly not a flaw. The limited output spaces in ACR - ok, that can also be considered a feature request (although you already have minimally disturbed data in PhotoPhotoRGB). But you still seem to be going about all this in the worst possible manner. Simply asking for the features or asking for more information would help you far more than making obviously inaccurate statements on a public mailing list. Chris _______________________________________________ Do not post admin requests to the list. They will be ignored. Colorsync-users mailing list (Colorsync-users@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/colorsync-users/waynebretl%40cox.net This email sent to waynebretl@cox.net
On Mar 17, 2016, at 7:41 PM, Chris Cox <ccox@adobe.com> wrote:
Again, you are making a blanket statement based on one aspect of the products,
Chris, if you think I've only a single complaint with the color handling of Adobe products, you haven't read a single post I've made to this thread. Either that, or you don't even begin to understand the scope of the task and associated challenges. So...enough with the name-calling. What follows is a skeletal outline of what I do. If you can provide a comparable outline of how to do the same thing with Adobe products, I'll happily eat my words. First, I've measured the per-channel spectral response of my cameras by photographing the image projected by a large homebrew spectroscope. I use Iliah's Raw Photo Processor for all image development; for spectral profiling, I dumped the raw (unbalanced!) image data from RPP to a TIFF and then used Graeme's scanin from ArgyllCMS to extract the RGB values. I've also measured the spectral transmission efficiency of my lenses. That data combined with the SPD of the scene illuminant (either measured or, for D- and A-series illuminants, estimated from chart measurements) gets fed into a spreadsheet. (I hate spreadsheets, but they're good for rapid prototyping.) The spreadsheet then serves two main purposes. First, it can generate simulated measurement chart readings for that particular combination of camera, lens, and illuminant. I simulate tens of thousands of samples, including several hundred real-world samples (from charts, etc.); the rest are synthetic reflective spectra. Second, I can feed to the spreadsheet actual measurements extracted from a raw (again, unbalanced) image of a chart (or anything with a known reflective spectrum) and get the actual per-channel offsets for exposure. The spreadsheet will predict expected offset values, but by plugging in actual measured values it compensates for any discrepancies introduced into the workflow before that point. In practice, I'm getting small or fractional DE discrepancies, save for however many stops of underexposure I dial in to provide headroom for highlights. I typically use a ColorChecker for the known samples because it's easy and averaging all those patches makes for fantastic results, but I can get by just fine with a single known sample. (It's like the eyedropper for white balance, but you're not restricted to just a single hopefully-but-never-actually spectrally-flat sample.) To get to this data, I use Iliah's RawDigger. Those offsets go into RPP to normalize exposure and channel balance; the result at this point is a perfectly (to the fractional hundredth of a stop) balanced and normalized development in the camera's native color space. I then use Argyll's profiling tools to create a profile (again, specific to that camera, lens, and illuminant) from the spreadsheet-simulated data, and then use Argyll to convert the output from RPP from that space to my preferred working space (which is task-dependent). For straight-ahead copy work, there'll typically be an interlude here that includes flat-fielding. RawDigger supports flat-fielding for chart capture, which is wonderful. I've used Robin Myers's Equalight for the images themselves in the past, but I'm tending to use ImagaMagick for that more these days. You _can_ use Photoshop for this, but it's a royal pain because you have to combine the color dodge blend mode with an inversion of the image and so on (not to mention the whole gamma blend mess), whereas it's a single (and trivially automated) operation with either the purpose-built Equalight or with ImageMagick. Where it goes from there tends to be more conventional. Photoshop is almost adequate to the task save for the gamma blending mess you keep vigorously agreeing is very real but that you also bizarrely insist doesn't matter. Affinity Photo doesn't suffer from those problems, and is so much faster than Photoshop it's not even funny...so that's what I've been using lately. Some input sharpening, cropping, maybe a bit of editing to (for example) remove shadows from a seamless white backdrop or that sort of thing. (One area where Photoshop still shines is with responsiveness with the brush tool and a Wacom Cintiq...Affinity Photo still has some catching up to do there.) Last, back to Argyll for conversion to the destination space -- typically either my printer or sRGB. (And, if I know the image is only ever going to sRGB or has a small enough gamut, I use it from the beginning for the working space.) The final result is well within the limits of human perception, with (of course) the usual caveats about the output space's gamut. I've made large prints (especially watercolor) that I've laid side-by-side with the original, lit by SoLux lamps, and the artist herself couldn't tell which is which until she stuck her nose into the print to see the slightly reduced spatial resolution of the copy. And, note again: this is all done objectively, with absolutely no manual tweaking of color at any step. No eyeballing this, no sliding that, no visually matching this other; it's all by the numbers, start to finish. *That's* what's involved in colorimetric reprography. So...what workflow do you suggest can achieve similar results using either exclusively or primarily (or even substantially) Adobe products? Cheers, b&
On 18 Mar 2016, at 16:14, Ben Goren <ben@trumpetpower.com> wrote:
So...what workflow do you suggest can achieve similar results using either exclusively or primarily (or even substantially) Adobe products?
"Sometimes you eat the b'ar and sometimes, well, he eats you." <https://www.youtube.com/watch?v=JQc5gDXQGIs> PS. Great post Ben. -- Martin Orpen Idea Digital Imaging Ltd
On Mar 22, 2016, at 7:12 PM, Martin Orpen <martin@idea-digital.com> wrote:
On 18 Mar 2016, at 16:14, Ben Goren <ben@trumpetpower.com> wrote:
So...what workflow do you suggest can achieve similar results using either exclusively or primarily (or even substantially) Adobe products?
"Sometimes you eat the b'ar and sometimes, well, he eats you."
don’t get it: https://www.youtube.com/watch?v=1xhet5HXUKo
PS. Great post Ben.
-- Martin Orpen Idea Digital Imaging Ltd _______________________________________________ Do not post admin requests to the list. They will be ignored. Colorsync-users mailing list (Colorsync-users@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/colorsync-users/etaffel%40me.com
This email sent to etaffel@me.com
participants (5)
-
Ben Goren
-
Chris Cox
-
edward taffel
-
Martin Orpen
-
Wayne Bretl