Histograms + Colour Format line missing from Document drop-down in 101

[LenC]

I was interested in the claim in the 101 release note that the Curves histograms had been fixed in a version prior to 101. Something changed, but there are a number of old histogram issues, including the "master" that is not a sum of RGB or CMYK channels but apparently the common area; the "master" in LAB that is nonsense; the fact that the histograms did not change when the colour format changed using the drop-down in the Curves window; the poor legibility of the multiple-channel display, and perhaps some more (I have some notes but I didn't think they were neat enough to publish yet). So what is fixed, and is it fixed if we are able to change the colour format?

[LenC]

Other histogram issues: in both the Histogram panel and the Curves histogram, some histograms are clipped; and in the Curves histogram such clipped curves appear above the box framing the curve (3 pixels above on one monitor).

[lepr]

.

[LenC]

@>|<

I am delighted that developers are working on these vital elements of image processing. However, in my version 101 the RGB master and the three others are still the useless intersection. Compare in the first image below "master" in the Curves window with the white intersection in the Histogram panel; also note that the peak max height is less than one quarter of the enclosing box height.

In the next version, please have a correct "master" display for RGB (not sure whether this should be a simple sum or luminosity, but I find the existing one very useful) and delete it for Grey and LAB. But label it "all" or "all channels" as in the Histogram panel. I don't know enough about CMYK to say whether this display is useful or not.

In the individual channels of the three color spaces (not gray) there are some minor graph issues, and the CMYK channels puzzle me. First the graph issues: some histograms are clipped and some are not (examples below from CMYK but appear in all color spaces). Unclipped: cyan and black; clipped: magenta and yellow (extreme left of graph). The clipped ones seem to extend above the bounding box by about three pixels. And the box for all the alpha displays has a double line on the right.

CMYK issues: Although I have no experience with this color space, and I hope my concerns are not consequential, the histograms do not match my general experience with data distributions, nor do these histograms seem to correspond well with the RGB histograms of the same picture. The cyan histogram has a leftmost bin (column of pixels) that is much higher and thus out of sync with the adjacent bins.The magenta and yellow channels are similar, and they have a good deal of empty space on the right. This may reflect the need to move the intersection of CMY to black (but the intersection = master is on the left). Am I correct that the plots are for increasing ink to the right and hence dark on the right, the opposite of the other color spaces? Need some help here from an expert.

Also note (probably you already are aware of this) that the LAB A and B channels' numerical values go from -128 to +127 or -1 to 1 or something similar, so are inconsistent with the min and max limits of 0 and 1 in the Curves window. This has been pointed out by others some time ago. The individual channels do not appear to have any issues other than the ones described above.

Incidentally, by deleting the Document Format command, you lost one useful ability: to scan the image with the Colour Picker Tool and get direct readouts in alternative color spaces.

 

[lepr]

.

[Chris_K]

In 103 The new master now basically shows all the channels in a single view instead of a common area for all channels. 

[fde101]

On 11/24/2018 at 5:08 AM, >|< said:

all of the Master curve histograms are a useless intersection of channel histograms.

Shouldn't it be a union rather than an intersection?

I see two ways for it to combine these: it could either give a histogram of a grayscale conversion, which would provide a measure of apparent brightness but lose accuracy in determining when data was being clipped off due to lack of dynamic range in the underlying storage format, or it could display the union of the color channels, which would be more accurate in determining when data was being thrown out or lost, but less useful in determining apparent brightness.  Both are useful for different purposes, and both are completely inferior to a waveform diagram or RGB parade that can be found in the scopes panel.

[lepr]

.

[fde101]

3 minutes ago, >|< said:

Chris_K's post immediately before yours shows the master curve histogram in 1.7.0.103 is something that could be called a union of the channel histograms.

Agreed.  That corresponds to detection of data loss, which is probably the more commonly useful of the two combination types I had suggested.

Also rethinking my comment on the scopes in light of where the histograms are being used in this case, as they map more closely to the control being manipulated, so probably do make more sense here.

[LenC]

On the last three comments: my use for the all-curves histogram is to help me place points to modify the RGB curve, but I look at the image itself to check the result. In the future I may learn to use the individual channels. Other usage mentioned above is beyond my experience. My focus in recent posts has been to get the LAB color space functioning well so I can try applying some of Dan Margulis's ideas in Affinity. There are remaining LAB issues but this is a good starting point.

In response to Chris_K, the new combined histograms in 103 look very good. The black channel in CMYK requires some squinting but is manageable. Will you be applying similar logic to the histogram panel, and recoloring the common area or intersection from white?

I can’t grasp the scaling of the channel histograms: some are maximum to top of box, some below, some clipped. I thought once that I saw the CMYK channels were being displayed at actual ink percentages, but have not been able to reproduce this.

I would like to see the “Master” or “All channels” display for LAB removed, as the channels are orthogonal, and I cannot see anything gained from looking at them simultaneously. For Gray too, where master = Intensity.  I think that the A and B channel histograms, wherever they appear, might benefit from a gray line in the center to indicate the zero point. The scaling of A and B (not 0-1!) will require attention.

On opening a threshold adjustment layer in RGB and LAB while the histogram panel was open, the latter display stopped displaying the whole-image histogram and went blank with a colored line at two edges or showed a peak in the middle for the A and B channels (2d figure below). After a long think, I got it that these represent histograms of the thresholded BW image, but is this useful?

With the combination of the Document menu items Colour Format and ICC Profile into one line we no longer have a simple way of checking the current format of an image that has undergone conversion. Maybe not much of an issue.

The right hand side of the border box in the alpha channel display in Curves for all color spaces is still drawn incorrectly (following figure, from 1.6.7 but is same in 103).

 

[LenC]

Something I forgot to insert, if Serif people somehow are watching this, as you consider deleting the "all channels" view for LAB curves. One basic, easy use of LAB is to increase or decrease saturation by steepening or making shallower the A and B curves. For colors to look real, both curves should pass through the zero point, and this can be a little tricky as you move the ends of the curve in the rather small window. To make this easier, there could be a check box for the A and B channels requiring the curve to pass through the zero point. (Separate for each curve since slopes could differ.) So you would check and then move just one end. This handy feature is not, I think, in Photoshop!

[Polygonius]

I really like the "band/color" selector in the new HSL: Much more faster and smarter than this longwindowed hamburger dropdown. Why is this not in Curves too? Thats really a time saver, especially for more creative/unique style using. 

[fde101]

4 hours ago, Polygonius said:

Why is this not in Curves too?

I had to think a few minutes to try to figure out how that would work.  This would be interesting, but it would need to be limited to a "universal" luma adjustment of an image region that was targeted in much the same manner has what the HSL adjustment currently does.  After effectively building a mask for the intended part of the image, while HSL allows saturation/lightness adjustments, this variation of the curves filter would then adjust lightness based on a curve for the masked-off section.

This would be a rather different sort of behavior than the way the curves adjustment currently works, so this would either be a different version of the curves adjustment or a separate mode for it to operate in, but it could actually be simulated by creating a mask to match the selectiveness of the color band selection being done in the HSL adjustment then applying that mask to the existing curves filter.

 

Based on that, I think a much more useful feature out of this would be a generic "mask builder" that would function like the qualifiers do in Resolve - select a range of hues, a range of saturation values, and a range of lightness values, possibly with feathering applied to them, and an option to "invert" by only selecting things outside of the indicated ranges instead of inside them (this would be like building the inside mask then inverting the mask).  Allow the selection to be previewed while building it and after happy with it then produce a mask layer (for Affinity Photo - Resolve works differently and doesn't need one) that would include the selected regions.  That mask could then be applied to ANY of the adjustment layers (or any other type of layer for that matter), not just to curves or HSL adjustments.

 

EDIT: for those not familiar with how qualifiers work in Resolve, here is a video I found that shows a number of ways they can be used: 

 

[lepr]

.

[Polygonius]

Hi fde and </>,

 

Well this looks interesting too, but i didint mean any new feature so far, just a workflow--speedup.

Now you have to use this slow/longwindowed Hamburger Menu to reach the RGB/Alpha... 

In the new HSL you can direct click the "channel" you want. Thats what i mean: a more direct access to the channels like in new HSL.

Whenever possible use direct-click buttons instead  hamburburger-droopdown where you neeed 

1. click this dropdown field

2. scroll to 4,5 items

3. click this

INSTEAD Simple ONE click.

A hamburger-menue makes sense for lot of entries with long names like the dozens of blend-modes, but not for choosing just between 5 items which can be easy displayed as simple-symbols like in the HSL / curve as rot, greeen, blue dots (or in other cases / functions with other simple symbols like single letters....(as direct radio-buttons). (eg: H, M, L as "symbols" for High, Mid, Low... and so on). 

As long as the content inside a hamburger needs not more GUI-space than the radio-buttons direct, there is no reason to choose this longwindowed way instead the more direct radio-buttons.

[lepr]

.

[fde101]

I don't see any hamburger menus in the Curves window, just drop-down lists.

The current organization seems to make sense: the first one is selecting a color format and the second is selecting one channel within that format.

You might be able to make the channel selection into a radio button format, and that wouldn't be a bad thing as long as it is laid out sensibly, but you wouldn't want to mix different color formats in that same adjustment, so keeping that separate makes a lot of sense here.

I would expect changing the color format to be destructive and wipe out any changes I had made, while I should be able to adjust multiple channels of the same format within the same adjustment window by switching back and forth.

[Polygonius]

Call it drop-down-list  - its the same long way to switch from red-channel to the green channel.  A RGBAM CMYKAM symbols-radio-button would speed up this enorm. 

The rgb/CMYK... selector DROP_DOWN could be as it as, the mode i never change as high frequntently as the channels it self and i do not know self-explaining-symbols for this drop-downs in the same sitze as radio-buttons.

 

Why not so? (The white circle should be rainbow for master the brighht-blue indicatr - is showing that currently red channel is selceted)

[fde101]

@Polygonius, Your screenshot looks reasonable in general...  The catch is that this makes it look like the HSL adjustment and they do completely different things.

In the HSL adjustment those circles are preset to useful values but the colors can be modified by moving the center point on the wheel or using the color picker.  For the HSL adjustment you are effectively creating a mask much like the qualifiers do in Resolve.

In the Curves window these colors are fixed color channels selected from the color format that is being used for the adjustment and which cannot be arbitrarily altered based on the content of the image.

While you could still have an interface much like the one presented, it should be distinguished in some way to differentiate it from what the HSL picker does in order to avoid confusion.  These are NOT equivalent and should ideally not look equivalent.

 

EDIT: for example, one of them could use a circle within a circle or maybe be a different shape...  or connect the circles together using lines or something... just enough to help make it clear when they are viewed side by side that they do different things

[Polygonius]

do not nail me on this example - I GENERALLY want: if possible use a radio-button instead a dropdownhamburgerlistmenueuewhatever...

As soon there is enough space, to make the access more direct, than 2,3..7 EXTRA clicks... use this possibility. 

Thats all i saying! USABILITY is in (my opinion) one of the most importing things for get warm with an app or not! 

Eg: I really like the presets for shapes now, or the possibility to "direction" a brush via left/right keys... thats a good way, especially for brushes hopefully not the end...! 

(maybe im special - i develope "frontends" by my self... so i´m very sensitive of wasting time, comfort, space... each step to more direct-way, i noticed and are happy with. I´m a very lazy boy, i really hate UNNESSCARY steps).

[LenC]

Buttons instead of drop-down menus has been requested before; I have encountered it browsing forum searches. Makes sense in curves and other places, and now we have the HSL example. Perhaps the development group thinks the austere drop-down is plainer and thus more elegant, but ease of use wins! I am also regularly posting suggestions for easy UI improvements and encourage people to do the same, and create images with visual suggestions if you are able.

[R C-R]

7 hours ago, LenC said:

Perhaps the development group thinks the austere drop-down is plainer and thus more elegant ...

There might be another reason: consider how the Blend Mode drop-down works, allowing a live preview of a different mode without changing the current one. While they have not implemented anything like that in the color space or channel drop-downs of the Curves adjustment window, they might be planning on doing that in the future, or just want to keep that option open.

So for example, the channel could be set to blue for an uncluttered display of its curve, but it would still be possible to temporarily display the other channels or master for quick comparisons. I have no idea if anyone would find that useful, but they might think some would.

[lepr]

.

[R C-R]

33 minutes ago, >|< said:

The adjustment could feature the same preview thing in response to the pointer being over a channel button. Again, that removes the inconvenience of having to click to reveal a list first.

It could work like that, but maybe they are thinking the localizable text-based approach of using drop-down lists is better than buttons for some reason. Since we don't know what they might be planning for the future, it is all guesswork. 

[Polygonius]

18 hours ago, fde101 said:

@Polygonius, Your screenshot looks reasonable in general...  The catch is that this makes it look like the HSL adjustment and they do completely different things.

Was just an example, it could also look like, or CMYK instead RGB....