doctorontop wrote:
I think Hue/sat was re-written for CS3 for Lab purposes but I have to agree with snap that selective colour handles colour shifts in a far more empathetic way than hue/sat in RGB/CYMK.

Empathetic to your preferred way of working?  (that vs. SC giving a more accurate result?)

doctorontop wrote:
I think Hue/sat was re-written for CS3 for Lab purposes

Hue/sat behaves the same way as it did in Photoshop 4 (10 years ago, and hence the issues) as far as I know. They may have updated it for LAB mode I dont know but didn't hear this.

Sean Baker wrote:
That is, I can select a luminosity range with Blend If which I could also select with a couple of layer masks, but the layer masks given me a much better & smoother result.  Similarly, I'm suggesting that the Hue Sat layer uses a very lossy manner of handling the selection range, quite possibly sharing code with the Blend-Ifs.  That the data are in a different format is in many ways irrelevant.

Oh dear Sean, you do know about controlling the blend-if transitions I hope? Like I said no-one can know everything.

Snap2 wrote:

Oh dear Sean, you do know about controlling the blend-if transitions I hope? Like I said no-one can know everything.

Holding down alt and dragging them away?  Yeah, it's how I found that the selection is less accurate / tonally-gradated than a channel-based or Calculations-based selection.  This is what I'm suggesting may be similar to the gradation issues you have with Hue / Sat.

Snap2 wrote:
Ok thats interesting. Thinking it through for the first time, I guess that blend if is working on transparency. As we have discovered in another thread the way transparency is calculated in Photoshop is not very accurate. Of course Channels work on a 0 to 255 scale, maybe blend-if can't match this for some reason? Ill do my own tests when I get a chance

Never found myself using blend-if for anything important, maybe that's why.

Can you provide a link to the other thread?  I've not worked enough with transparency since coming back to all this and probably should .

Snap2 wrote:
It was the one where we were talking about your ingenious Apply image way of calculating the 'high pass' mask. And I said that 50% High Pass did much the same job, but a contrast reduction on the HP was better - so that means that it was the opacity that seems to be creating the flattened extremes in some way.

If you meant opacity then I understand - I thought you were referring to actual transparency within the image layer proper (alpha channel). No worries.

Sean Baker wrote:

Empathetic to your preferred way of working?  (that vs. SC giving a more accurate result?)

That's a fair point preferred way of working each tool has it's plus and minus points. I use both. I will need to fire up an old machine and check out hue/sat in cs2. If memory serves I think Deke Mckelland mentioned the Hue/Sat re-write in his LAB colour DVD. He also mentioned that the RGB component had been re-worked. It is rare that I have need to be colour specific in the way a print operator would need to be.

doctorontop wrote:

That's a fair point preferred way of working each tool has it's plus and minus points. I use both. I will need to fire up an old machine and check out hue/sat in cs2. If memory serves I think Deke Mckelland mentioned the Hue/Sat re-write in his LAB colour DVD. He also mentioned that the RGB component had been re-worked. It is rare that I have need to be colour specific in the way a print operator would need to be.

I didn't know Deke did a DVD on it?  Was that through KelbyMedia, or otherwise?

Sean Baker wrote:

I didn't know Deke did a DVD on it?  Was that through KelbyMedia, or otherwise?

Lynda.com

Snap2 wrote:
Correct me if I'm wrong but I thought opacity and transparency are effectively integrated to achieve the same thing. I had assumed (maybe incorrectly) that opacity and its apparent 1 to 100 scale, is actually a summarized 256 scale, in exactly the same way as a channel mask. In CMYK the 4 channels actually have 256 levels NOT the 100 they pretend to have, this is because of basic digital numbering.

Opacity is out of a scale of 100, but any (normal) layer can also have an Alpha value associated with it with the same bit depth as the overall image - i.e. 8bit 256 levels, 16bit 65,536 levels, etc.  The easiest way to see this is by either using the eraser tool to remove portions of an image, or to add image data in with the brush tool, text tool, etc. and then access the corresponding Alpha channel in either Calculations or Apply Image to suit your purposes.

doctorontop wrote:

Lynda.com

See where assumptions get you kids?

Sean Baker wrote:



See where assumptions get you kids?

Ha I think preference might be a better word .......

Snap2 wrote:
We are only using 8 bit as an example here obviously…

Ok I did use Calculations to extract the transparency created with an Eraser into an alpha  - and its cleary 256 levels, just as I expected.

Well I would hope you've learned you can trust me .

Snap2 wrote:
The point I am making is that opacity must also internally be a value of 0 to 255. When Photoshop is calculating the overall transparency of a layer it must be taking an cumulative of the alpha channel value and the Opacity to create this. See the CMYK example in my last post, just because it says 1 to 100 doesn't mean it is. 

Enough of this nerdish discussion, Im going to bed soon

If anything, I would guess that 'opacity' is at that a vague term as it's probably only a parameter into the calculation of the overall layer's application (which will be along the lines of Image Alpha * (Mask/Fill) * Opacity).  It's probably stored as an 8bit integer or a single float as it doesn't even need that much resolution, but there wouldn't be any reason which I can conceive of for taking it to and from a value of 255 for storage.  That is, it'd be more logical to use it as a scalar value to avoid fragmenting the code too much for the different image modes, applying a conversion factor for each channel at the time of calculation as appropriate to the image mode (255 for RGB, 100 for CMYK, etc.).

doctorontop wrote:
Ha I think preference might be a better word .......

Sorry, I meant my assumption that Kelby produced the video with Deke.

See where assumptions get you kids?

Yes that could be referring to the whole of this thread in a nutshell ;-)

Snap2 wrote:
Yes that could be referring to the whole of this thread in a nutshell ;-)

Indeed.

And for the OP, if you've been reading this little side discourse on selections, gradation, accuracy, et. al. you'll see why Bob does things his way - by using the channel data already there to work on, he gets the best possible (and most natural) gradation of tone in the image.  The tools we've been discussing get the same or similar results most of the time; his works every time.

Sean Baker wrote:

Sorry, I meant my assumption that Kelby produced the video with Deke.

As for Deke he seems to have open access to Adobe. I agree with you btw about transparency being calculated by a separate algorithm this makes sense because otherwise there would be a lag which clearly does not happen when reducing opacity in 16/32 bit. I think PS is full of one off workarounds optimized for a specific function and version the tools co-exist through compromise I suspect. DP maps are a good example of code that has not changed since the day it was introduced.

doctorontop wrote:
DP maps are a good example of code that has not changed since the day it was introduced.

One which gets a sad face as it could be turned into something much more than it is currently.  Not that it's bad, it's just not what it could be.

Sean Baker wrote:

One which gets a sad face as it could be turned into something much more than it is currently.  Not that it's bad, it's just not what it could be.

Indeed work with layers,16bit a large view screen are all on my wish list for DP

Sean Baker wrote:
Also fwiw (not much IMO - I think it's a great idea with terribly implementation), Blend-If can base off of any channel, so R, G, B, and gray (close, but not quite Lum) are options while working in RGB.

I kind of agree and kind of disagree.

The Blend-if appears to be implemented well enough, but the RGB model, which subsumes luminosity, color, and hue into all the channels, simply isn't as well suited for it's use in photographic terms as it is in LAB. (Even CMYK is better than RGB for this, and it's not all that good there either.)

It would be nice to be able to both split the transitions (as can be done now) and weight them (which can't), though, so as to specify both the stop and starting points of the 'if', AND where the midpoint of that transition is, instead of it always being centered. But for most purposes, that's a fairly minor enhancement, and the UI would most likely get messy.

If you want to see blend-if being much more useful, use it in LAB mode. I sometimes switch a copy into LAB just to get Photoshop to build a mask that way. (Well, build a pre-masked flattened layer via Merge Visible.)

Sean Baker wrote:
and for the OP, if you've been reading this little side discourse on selections, gradation, accuracy, et. al. you'll see why Bob does things his way - by using the channel data already there to work on, he gets the best possible (and most natural) gradation of tone in the image.  The tools we've been discussing get the same or similar results most of the time; his works every time.

I think the takeaway soundbite from all this is the one about things working "better" according to one's preferences. I'm from the same Deke find-the-mask(or fix)-in-the-channel-info school as everyone else here, but in this case, I had a simple problem that I found a very simple and quick fix for, employing a tool I don't often use. I'll use it again if I find myself in the same position (having nearly a hundred images, many already CMYK, and with out of gamut areas that threaten to destroy fabric texture, but on a project that neither demands nor pays for perfection).

(Try it sometime, it really goes to the crux of the deep mysteries of how PS seems to randomly change behavior based on color space, blend mode and tool used, belying all the different generations of math that coexist in the PS universe. Selective Color in CMYK to correct for out-of-gamut wasn't the big discovery, it was how much more efficiently it worked once the blend mode was changed to Hue or Color - requiring much less numerical adjustment, and with much less visual impact. I can't find a logical explanation based on my understanding of how the adjustments and modes are meant to work - in RGB anyway, but I don't care. I just happily moved onto the next dreary image.)

Besides that, I've learned some interesting tidbits, run some mildly amusing experiments, sat on the sidelines of a clash of personalities, and basically had the full MM forum experience.

I should start threads more often.