-
Posts
5,510 -
Joined
Everything posted by lepr
-
Inheriting Line Styles
lepr replied to joe_l's topic in Feedback for the Affinity V2 Suite of Products
Not sure if it always works, but try ensuring the line with the wanted style is lower in the stack than the other line(s) before doing the join. Edit: now realised this is a request thread. Anyway, the workaround may help a little. -
problem with document and brush sizing in affinity photo.
lepr replied to TJack's topic in V2 Bugs found on macOS
That's not a bug. The pasted object's scale depends on the destination document's unit of measure (UOM): destination UOM is pixel - pasted object has its size in pixels preserved destination UOM is physical - pasted object has its physical size preserved Be careful to not resample the destination document when changing its unit of measure for pasting purposes. The intersection of the view's rulers has a convenient right-click menu for switching the UOM with no resampling. That behaviour normally matches across the Affinity apps. There has been an occasional regression in one app and not another, if I remember correctly, but the current macOS apps match. (I don't use the apps on other OS.) (Be aware that there is a many years old bug affecting the pasted object's offset from the document origin when the destination UOM is physical - the offset should be the same physical size as it was in the source document, but it incorrectly is the same size in pixels as it was in the source document.) Unfortunately, there is no way to specify that the brush's physical size, instead of size in pixels, is to be preserved when switching between documents with differing pixel density. The document UOM has no influence there in the current apps and that's probably more of an unimplemented functionality than a bug, in my opinion. You should post a feature request in https://forum.affinity.serif.com/index.php?/forum/122-feedback-for-the-affinity-v2-suite-of-products -
Delete node added to right click menu
lepr replied to Ash's topic in [ARCHIVE] 2.3, 2.2 & 2.1 Features and Improvements
The choice of ctrl modifier there was a mistake for the macOS software. It breaks decades of UI standardisation on Mac. Mac users always expect ctrl+click to be equivalent to secondary click (typically right-click on a two button mouse). A better modifier for 'convert to smooth' would have been cmd. Similarly, deleting a segment of a Curve should have been cmd+click instead of ctrl+click. In other words: ctrl+click should display the context menu appropriate for whatever is clicked cmd+click on a node should convert it to smooth cmd+click on a segment should delete it -
Exactly! Someone with clout at Serif thinks the users are stupid. Years ago (before Publisher existed), I suggested the filradiant/gradill tool should be named Fill Tool in all the Affinity apps since it was already named Fill Tool in Designer and did various types of fill, not just gradients, in all apps. The response from a forum moderator (no need to name them here) was that the name Gradient Tool was chosen for Photo to prevent users becoming confused when there is also a Fill command. Maybe that would be the same multitude of users as those who are confused by the existence of both vector Curve objects and the Curves Adjustment - in other words, nobody, in my experience.
-
@Chris26 You can cmd+opt+click on a thumbnail to get a luminosity-based pixel selection. Alternatively, duplicate an object/layer then do Rasterise To Mask to convert it to a luminosity-based Mask. However, you don't actually need a luminosity mask for your high pass filter. Every layer/object, including live filters, has built-in blend options with graphs for controlling opacity according to the luminosity of the layer/object itself or the luminosity of the underlying scene. The cog wheel at top right of the Layers panel opens the Blend Options for a layer/object. My screenshot shows an example of a live filter being made less opaque for brighter pixels of the background image.
-
Your frustration with that is completely understandable. Consider two categories of objects/layers: A - Live Filters and Adjustments B - all other objects/layers except Masks (a Group can contain stand-alone Masks in Affinity, but I want to leave that out of this message since that is an unusual, although useful at times, feature.) When a Passthrough Group contains only A, it's the same as Pass Through in Photoshop and other apps - the content can "interact" with the scene below the Group. When a Passthrough Group contains only B, it's the same as Pass Through in Photoshop and other apps - the content can "interact" with the scene below the Group. Now here's the problem you came across. When a Passthrough Group contains both A and B, it's inconsistently unlike Pass Through in Photoshop and other apps. In Photoshop and other apps, all content of a Pass Through Group can "interact" with the scene below the Group. However, in Affinity, the B content can "interact" with the scene below the Group, but the A content cannot. Affinity considers the Group to have Normal blend mode for the A content while having Passthrough mode for the B content. I realised and posted a workaround for the problem scenario a few years ago, but it isn't often repeated. Because the B content can "interact" with the scene below the Passthrough Group, put a white object/layer with Multiply blend mode and covering the entire canvas/page as the bottom member inside the Group. That provides a representation of the background scene with which all other content of the Group can "interact". The white object/layer can be a vector Rectangle or Fill Layer or Pixel object, whichever you prefer, but I generally use a vector Rectangle because there can be problems with the display of a Fill Layer in apps other than Photo. Serif representatives have repeatedly insisted the dual personality of Affinity's Pass Through blend mode is "by design" and not a bug. Still leaving aside stand-alone Masks contained in a Group, you'll be familiar with masked Groups. Well, you will soon come across indisputable, and never denied, many years old bugs in the rendering of masked Groups, but that's a story for another day.
-
I understand and sympathise with your point of view. However, Serif will consider the differing display to not be a bug and will describe it as "by design" because it is the expected behaviour of the software design, regardless of what a user might expect. Set the view zoom so each pixel of the document is displayed by one corresponding pixel of the display device. That one-to one pixel mapping happens when the document unit of measure is pixel and zoom is 100%. That view will be equivalent to the Pixel object that can be produced by Merge Visible* command, but it is not guaranteed to match a 100% scale raster export of the non-merged document. As a non-destructive editor, Affinity enables raster objects to be unaligned with the document raster grid, and resampling to the view raster grid utilises different code than the resample methods provided for exports. Of course, you can do a 100% scale export of the result of Merge Visible to ensure the export matches the 100% zoom view. * Merge Visible is not available in all Affinity apps, but the same result can be produced by selecting everything in the document, duplicating, grouping the set of duplicates and then rasterising the group. It's not in public documentation, as far as I'm aware. It can be worked out by contrived experiments, of course.
-
Not a bug, and can be explained as follows. A (Initial state): the Pixel object is blended with black fill of the Artboard, and then the Curves Adjustment is applied to that result. B (Merge Visible): the Pixel object is blended with black fill of the Artboard, and then the Curves Adjustment is applied to that result. C (Group the Curves Adjustment with Pixel object or nest the Curves Adjustment in Pixel object): the Curves Adjustment is applied to the Pixel object, and then that result is blended with black fill of the Artboard. A and B will appear to differ because A involves resampling to the view pixel density before applying the adjustment, whereas B involves applying the adjustment before resampling to the view pixel density. A and C really will differ because of the different sequence of adjustment and blending.
-
Connecting Nodes / Point of a Spline
lepr replied to Buntstift's topic in Affinity on Desktop Questions (macOS and Windows)
Use node snapping and Join Curves (not Close Curve) as shown in video below. join curves.mp4 -
Lose adjustment layer effect when I merge the layers
lepr replied to DaleL's topic in V2 Bugs found on Windows
The view zoom is 19.6%, so you are viewing a resampled layer being blended with a resampled layer, versus a resampling of the result of merging the full scale layers. -
Another solution: Select the filter in Layers panel. Right-click the filter's alpha channel (not the Composite Alpha channel) in Channels panel and pick 'Fill'.
- 4 replies
-
- affinity photo
- mask
-
(and 1 more)
Tagged with:
-
The apps are not differing in behaviour. You edited a colour swatch in Publisher to become defined by a Pantone spot colour, but edited a swatch in Designer to become defined by a Pantone process colour. When you change the definition of a spot colour swatch to a predefined non-spot colour (as found in a Pantone process colours palette), the swatch ceases to be a spot colour. Similarly, if you now change that swatch's definition to a predefined spot colour (as found in a Pantone spot colours palette), the swatch will return to being a spot colour.
-
Colors reversed when placing screenshots
lepr replied to Benfischer's topic in V2 Bugs found on macOS
Oh no! Preview can assign a different profile. That is not what to do. You need to convert your problematic LS27A600U screenshots to another profile such as sRGB. In ColorSync Utility, conversion is done by Match To Profile.
