lepr

Same here, but being an option for three is much better than no option at all.

When a mask-nested Mask/Adjustment thumbnail is visible in an unexpanded row of the Layers panel, simply shift-click the thumbnail to toggle visibility of the Mask/Adjustment without needing to expand the row first. However, that functionality is broken for mask-nested Filters and the built-in mask of a Fill/Adjustment/Filter.

You have the Extended Dynamic Range option enabled in the 32-bit Preview panel when the brightest part of the sky looks orange rather than yellow. That option is enabling the display of R, G or B values that are greater than the range that can be encoded in a JPEG export or a screenshot, which are standard dynamic range formats. In the case of your HDR sky, all G and B values are not greater than 1.0 (equivalent to 255 in an integer 8 bits per channel image), and so they get exported intact to a standard dynamic range image. Some R values also are not greater than 1.0, and these get exported intact to a SDR image. However many R values are greater than 1.0 and get clipped when exported to a SDR image, hence the diminished redness (a shift from orange to yellow) of the brightest part of the sky in the JPEG export and screenshot Disable the Extended Dynamic Range option in the 32-bit Preview panel to display only the standard dynamic range that is exportable in a JPEG (or a screenshot).

In case a reader is unaware: clip-nesting occurs when an object is dropped on the name area of an object in Layers panel mask-nesting occurs when an object is dropped on the thumbnail of an object in Layers panel, and a mask-nested row in the panel has a darker than normal background (or at least it does in the dark UI) Edit: also, mask-nesting is the type of nesting that the Assistant can be set to perform automatically, based on selection, when a mask/filter/adjustment is added to the document.

No, both are involving Pixel objects. First is merging because the adjustment or filter is mask-nested in the Pixel object. Second is not merging because the filter or adjustment is clip-nested nested in the Pixel object. I already explained this how many times in this thread?

As far as I know, there are only two necessary conditions for the merge to work: the parent is a Pixel object the adjustment/filter is mask-nested (not clip-nested) in the parent

That performs the same action as pressing Shift+Cmd+I, and the same action as is in the Channels panel. Anyway, although the missing ants is an annoying display problem, it doesn't affect the actual selection.

No, Pixel Selection also can be inverted in Channels panel. There is a little button to do that at right hand side of the Pixel Selection row in Channels panel. No, the shortcut is Shift+cmd+I.

It's a display problem that has always been in the app. When a pixel selection is at edges of the canvas, you'll see the ants appear/disappear from different edges as the zoom level is adjusted.

Do the exported JPEGs have the same quantity of pixels?

Don't do a Boolean operation unless you actually want to destructively modify the selected object(s). Instead, simply press the period key to toggle between 'base box' and 'regular bounds'.

Like you, I use a Mac, and version 1 and 2 are both as I described.

Your adjustments are clip-nested. A clip-nested adjustment/filter cannot be merged into the parent Pixel object. A mask-nested adjustment/filter can be merged into the parent Pixel object.

The preview shows what you'll get if you choose New Layer With Mask for the output, instead of just Mask.

Yes, I understood that the way the software works is creating a problem for you. I was only explaining what was happening under the covers, and was not trying to say that the knowledge would solve the problem.

The context toolbar for Move Tool displays the PPI of Pixel objects (and Image objects and placed documents).

The key to understanding the results: When an object is rasterised, the created Pixel object covers the entire canvas (or greater when any of the object lies outside the canvas), but its pixels have alpha of zero where the source object did not exist or was fully transparent. The bounding rectangle of a selected Pixel object is only as large as required to contain all of the pixels with alpha greater than zero, and so the real extent of a Pixel object can be greater than the user interface leads us to believe. Using your example: Step 3. rasterising the 1 px vector rectangle actually created a Pixel object as big as the canvas, 512 x 512 px, but with only one 1 pixel having alpha greater than zero. Step 4. scaling the Pixel object by 100 so that its 1 visible pixel covered 100 x 100 document pixels actually scaled the entire Pixel object to cover 51,200 x 51,200 document pixels. Step 6. filling the alpha of the Pixel object, made all of its pixels have alpha greater than zero, and so its bounding rectangle became the full extent of the Pixel object.

C, M, Y & K to CMYK.afmacro

Yes. One way is to use the Channels panel to transfer the lightness of each monochrome image to the respective L, A and B channels of a new Pixel object. Place the three monochrome images into a LAB document and use Rasterise command to convert them to Pixel objects. Name the Pixel objects "L", "A" and "B" (without the double quotes). Run the attached macro which will generate a composite Pixel object named "LAB". L, A & B to LAB.afmacro

I know what it says and does and doesn't do. I was responding to a specific comment by @prophet, and even quoted the comment to make that clear.

Yes, it is a new feature in the v2 apps. Note that it should be named "Allow Selection to Consider Nested Items" since it makes clip-nested objects be directly selectable, in addition to group-nested objects. The button only appears in the context toolbar of the Move Tool, and only when something is already selected. In my opinion, the button should be in the main toolbar since we might want to toggle that selectability when using any tool that can select objects, and we shouldn't need to already have a selection in order to access the button.

Good point, although it's likely to be something that hasn't been implemented yet, rather than a bug. Exactly the same problematic lack of control over the candidates for 'select same' has been pointed out by other users. Hopefully, there will be improvement sooner rather than later.

You certainly could be right about results differing because of the difference between font versions on Windows versus macOS, rather than differences in the Affinity code on each platform. There is no "Divide (Compound)" command. I guess you are talking about alt/opt-clicking the Divide button in the toolbar, similar to alt/opt-clicking the Add/Subtract/Intersect/Xor buttons to create a Compound. Alt/opt-clicking Divide does not produce a Compound. The alt/opt key is a modifier for Divide when one or more unfilled curves are in the collection of operands. The key is used when you want the fragments of unfilled curves to be kept, otherwise they are discarded. When filled text is an operand in a Boolean operation, the text is first wrongly converted to unfilled curves instead of filled curves (a persistent bug for several years now), and then the Boolean operation proceeds. Hence, the difference you were getting by doing a simple Divide with filled text versus an alt/opt-Divide with filled text. You were effectively dividing with unfilled curves when dividing with filled text.

Thanks! I'll take a look later today and come back to the thread.