lacerto
-
Posts
5,807 -
Joined
Posts posted by lacerto
-
-
You can use the Style Picker Tool to pick color assignments (internal definitions that objects currently have, including their color space, swatch assignments, etc.), while the Color Picker Tool picks their color values in current document color space. Select the object to which you wish to assign a style of another object, then hold down the Alt/Opt key and click the object from which you wish to copy a style, e.g. PANTONE color assignment, from.
UPDATE: Note too the difference of Color Picker Tool from the Style Picker Tool: the former will retain e.g. the opacity attribute of the selected object, while the Style Picker Tool will not. The Color Picker Tool, on the other hand, does not copy attributes affecting the color, like opacity, while the Style Picker does.
UPDATE2: When you copy styles, the swatch assignments copied will not be immediately refreshed in the Swatches panel, but assignments and attributes do show immediately show in the Colors panel, so to see e.g. a spot color assignment effective in the Swatches panel, you would need to de- and re-select the object the swatch assignment was copied to.
EDIT: Here is a clip that demonstrates the difference in functionality of the Color Picker Tool vs. the Style Picker Tool. On the first round note that the Lock of the Color Panel is turned off so that when objects are selected, their actual internal color definitions are shown. On the second round the Color Picker Tool is used to pick the color values in current document color space which here is CMYK. Values shown depend on the currently effective document color profiles (one of which is active, in this case CMYK and ISO Coated V2) and the underlying alternative color profiles (like here sRGB for RGB color space) initially assigned at document creation time according to the settings defined in Preferences > Color but which might have been later changed if the document color modes have been changed and profile changes made under File > Document Setup > Color). On the third round the Style Picker Tool is used (holding down the Alt/Opt key) to pick actual color assignment and attributes the objects have, like swatch assignments, opacity, color space, tint and overprint attributes.
PS. Still one more thing: you can alternatively copy styles by pressing Ctrl/Cmd + C while having an object selected from which you wish to copy color properties from and then selecting the object where you wish to copy those properties and pressing Shift + Ctrl/Cmd + V (Edit > Paste Style).
-
4 hours ago, thomaso said:
I might be wrong but doesn't it rather matter that vector generally gets treated different than pixels – and thus the vector cropping mask above causes different edges if stretched?
I suppose so. I was just surprised to see that antialiased edges are applied both on canvas (when stretching a pixel selection, even when having done it non-antialiased) and additionally when resampling with methods other than "Nearest neighbor". So making the "selection" rather by using a vector shape and then using it as either a mask or clipping shape provides for many situations a good solution. Sometimes resampling with "Nearest neighbor" is a better solution, though.
-
@thomaso's suggestion has the benefit of avoiding antialiased edges that Affinity creates for any stretched pixel layer, not just when stretching a pixel selection on canvas (even when pixel alignment and non-antialiased selection is used) but also in context of document resize, unless Nearest Neighbor is used as the resampling algorithm. This method, however, suits well for stretching of columns wider than 1px only if the source is more or less uniform since otherwise miscellaneous artifacts are likely to be created.
The screenshots below show the difference of stretching a 2 px wide tiger stripe column via rectangle and document resizing (bilinear):
The rectangle method keeps sharp non-antialiased edges while its resampling method seems to be bilinear. Bilinear stretching, on the other hand, does not work well if there are internal contrasted areas that need to stay sharp.
Vector Crop tool is not available as a tool in Photo, so there one would need to use a manually drawn rectangle either as a mask or as a clipping rectangle. The former will auto-upsample at PDF export, which in context of non-uniform content is probably what is wanted since otherwise the exported result may show resizing artifacts. Therefore rasterizing on canvas to upsample to document resolution may be necessary in these kinds of stretched (distorted) constructions where blurring caused by upsampling does not matter.
-
14 hours ago, walt.farrell said:
That may be part of the reason for not seeing the option, in some cases, but we already know for our purposes in this topic that the option is totally missing on Windows, from the above.
It would of course be nice if it were implemented as a (shortcut) menu command also on Windows, similarly as on macOS, but I wonder if the command has initially been made available on macOS specifically because Paste As is not available there, and so there is no similarly an easy way to make a pixel layer a genuine image layer (with file content showing e.g. within Resource Manager). Not that Windows users are generally aware of this possibility...
For some operations (like availability of K-Only and applying tints) the feature is crucial (especially in Publisher, which is probably why it was made accessible via main menu). Not having it similarly available on Windows as on macOS has nevertheless a bit cheap feel about it, it would be very easy to implement it.
-
You might be able to work around simple compositions, but as there is nothing like this available in Photo:
...I think that you just need to cut (or copy), paste [a new document from Clipboard (File > New From Clipboard)], then do Document > Resize Document:
...and paste back:
-
Here is yet one take to the discussion of applying direct mix color mode CMYK fills on Pixel and Image Layers.
I wanted to create this to stress my initial point (which was first based on misunderstanding on how the vector-shape assisted flood fill was supposed to be working). Now that I understand the purpose of this functionality, I think, too, that the feature should be color managed similarly as when applying M100 fill in an RGB document using the Flood fill tool.
[It is another matter, but it is questionable whether this kind of a feature is reasonable at all. IMO it is not since it basically applies a tool based operation using an attribute assignment, which is counter-intuitive and also surprising, considering that applying a fill attribute directly on pixel layer does not have any effect at all. In addition, when the feature is applied, a limited size pixel layer on which the attribute is applied, will auto-resize to canvas size rectangle when applied (similarly as in e.g. Designer, where Pixel layer initially cannot be dimensioned but gets the canvas size), and when re-applied in alternate color mode (and is already converted in context of color mode switch), will apparently freeze the app when the color is applied but actually causes a hugely large rectangle saving of which results in a 33MB large file (as it is a pixel layer, even if solid color, that is saved), after which the document continues to be highly unresponsive (but not frozen), until the layer is rasterized. It does not seem that the feature was ever really planned, and it certainly has not been debugged. The test was performed on Windows version 2.04 on Windows 11 Pro.]
Aside from this, and to the point of reasonability of using mixed color modes in context of vector-fill assisted flood fills and colorizing image layer based bitmaps, I created a bunch of PDF files comparing how applying colors are managed and matched in different scenarios, when applied in RGB and CMYK document color modes and producing to different kinds of PDFs. [The color profiles used here are sRGB for RGB and US Web Coated for CMYK, so Affinity defaults.]
The conclusion is that this kind of mixing of color modes never works accurately. In an RGB document one can get very close when applying a CMYK color fill on a mid-gray RGB bitmap on an Image layer when exporting a Device-CMYK PDF, and when doing a similar CMYK based flood fill in an RGB document, but completely accurate results can only be achieved when using a CMYK mode document with RGB black (0, 0, 0) document in K-100 mode (= equivalent of using a grayscale document in Adobe print environment). That is, when applying a CMYK fill on a "grayscale black" in a CMYK document, and exporting to device-CMYK. This is an old-school approach that Affinity apps can produce using the K-Only method, but trying anything fancier is basically waste of time when aiming at color accuracy. The mere effort of trying to do so is a bit silly when accurate methods are readily available. Mixing color modes and assuming a perfect match by virtue of color management just cannot work, and additionally ruins possibilities to produce consistently behaving colors for dual color spaces. One should rather create in consistent color space and let the color management do its job when producing, instead of working confusingly in mixed color modes, applying arbitrary blends and effects, and assuming consistent matching of colors and expecting things to get automatically sorted at export time, or by using the PDF/X-4 magic wand (not resolving anything but trusting that all goes well when finally rasterizing).
This does not mean that one should not use mixed mode color definitions and assume that color management works as expected: it is just a question of assumed accuracy, and trying to match mixed mode definitions overlapping or existing side-by-side. Affinity apps handle just fine color conversions and the complexity of dual color-mode production -- despite some limitations -- so e.g. the Color panel works just as expected in context of color conversions. The "vector-fill-assisted-flood-fill-in-mixed-mode" issue aside, color-wise (not going to complexity of PDF production) the quirks and small discrepancies in behavior of color controls have mostly been covered in this thread.
mixed_colors_cmykdoc_mixed.pdf
-
3 hours ago, ,,, said:
I queried that years ago. I was astounded when a Serif representative said, yes, the filling of Pixel objects in that scenario is deliberate. It also happens when you apply colour to a Group that contains a Pixel object, even when the Group contains only the Pixel object.
Ok, if pixel layer is intended to be fillable this way, similarly as it were filled in Photo with the Flood Fill tool, then the behavior should of course be identical, and applying the color should be color managed in this context, as well. But to me it appears presently that the effect of applying CMYK color via vector object causes a blend effect (e.g. something like a Hard Light) with underlying pixels (empty layer being interpreted as white pixels), so it did not appear have anything to do with color management, failed color matching, or "naive color conversion", as you put it, so I thought that if at all intentional, it was meant to behave as if applying a colorizing effect on an image layer (but that gone wrong, as well). But I can see now that it behaves as a Flood Fill tool [EDIT: and at 100% tolerance!] with an RGB color fill. So yes, a bug [EDIT: and yes, a pretty useless feature].
-
Maybe it is a bug, who knows. But I have some thoughts...
- Are pixel layers intended to be fillable with an aid of a vector object selected with a pixel layer, in the first place?
- When coloring e.g. an RGB neutral gray 128, 128, 128 image layer, I can get kinds of tints and shades of the fill color used for coloring (and this happens both when using RGB and CMYK fills), so the pixel values are naturally supposed to mix with the fill color. They would be identical with a vector object filled with the same color only marginally. If I apply e.g. M100, the image layer would not look identical with a vector object filled with the same color, in either color mode. Personally I would not expect that since to behave this way the app should be able to automatically convert the underlying neutral gray to K100.
- To call this a bug, we should assume that there is intended behavior [that fails]. I am not sure there is. IMO these are "interesting side effects of sloppily thought out feature", but marginally nevertheless useful.
- I do not have expectations on how this feature should work since I have not seen similar feature implemented in apps that I regularly use. So when I want to have this kind of a colorizing effect I would typically cover an image with a vector object with the desired fill color and use something like Color blend mode.
Anyway, I do not expect this feature to be changed in any near future.
-
Thanks, cross posting, I already commented this above. As said, I think that the issue is trivial because there are better methods to produce the desired effect so basically coloring RGB raster images with CMYK fills or vice versa and expecting accuracy is kind of silly.
-
The .mov resource stays unavailable to me (tried multiple machines), but I could now see the issue with the Pixel layer.
Pixel layers cannot typically be filled [by using a fill attribute], but having a mixed selection seems to have an effect of making the Pixel layer behave like an Image layer, which can be filled, so in RGB mode if the underlying pixels have RGB 128,128,128 you get identical fill with the vector objects. While I think that this is not intended behavior, this could be used in certain situations meaningfully.
The behavior when applying CMYK colors is not color managed but IMO this is trivial because if properly color managed results are wanted, they can be achieved using different methods (e.g., using K-Only mode and then colorizing with CMYK values, in which case vector and image fills behave identically). Being able to colorize image objects directly with fills is a nice feature and I can see good use of it with RGB images (and RGB fills).
As for vector objects, I cannot see any general issues in color management so what is described in this thread pretty much covers "anomalies" that I have found. I do not actually consider behavior described here "buggy"; different conversions from CMYK to RGB when rasterizing or exporting to vectors are something that can be experienced in other apps, as well, e.g. Illustrator. These are just things that one should know.
-
I can reproduce this is in all 2.x Windows and macOS versions (including betas). Nothing wrong with the file itself, it is an ordinary 8-bit RGB. Opens fine in 1.x Affinity versions, and anywhere else.
-
9 hours ago, NotMyFault said:
V2.0 has a unfixed bug when using CMYK colors in RGB documents and vice versa, affecting vector objects (not pixel tools/layers).
I am not sure if it is directly related to the topic of this thread, but nevertheless I could not reproduce the behavior, and the .mov resource in the original post did not seem to be available anymore. Could you elaborate a bit and give more specific steps and description of the issue (perhaps in the connection of the original post you made)?
-
On Windows, as a menu option only in Publisher, but in all apps (and all versions) available if you copy a pixel layer and then Edit > Paste As, and choose PDF (Portable Document Format) to get a TIFF image in original color space (basically the same functionality that is available as a context menu command on macOS), or PNG to get the image in RGB format (a bonus not available on macOS where Paste As has not been implemented).
-
On 3/23/2023 at 7:18 PM, PitterPen said:
Am I misunderstanding something or doing something wrong? I'm trying to match colors, and thus far I'm confused as to what is the source of truth for a color's RGB values.
Not really, it is just genuinely pretty complex. Affinity apps seem to use a different method when converting CMYK values to RGB in context of color pickers and rendered colors, and when converting color values in the Color panel and Color Chooser window. Exporting to raster image formats like PNG and TIFF appear also to be using the former method, while exporting to PDF (in RGB mode) uses the latter. After you have actually performed the color conversion to RGB, you will get the same RGB values disregarding the export format.
There is additionally a question of accuracy in display of color values, as Affinity apps do not show decimals in color values even if they internally keep at least five decimals. So the actual CMYK values that you have in the green rectangle are C0.82750, M0.40000, Y0.65490, K0.24310. After the actual conversion, you will get R0.16850, G0.40380, B0.35120, which converted to 8-bit values would be R42.9675, G102.969, B89.556, or rounded to nearest integer, R43 G103 B90. That the Affinity apps internally keep the decimals can easily be seen if you type in the CMYK values C82.6, M39.6, Y64.6, K23.6 (ending up in identical rounded integer values as initially displayed), the RGB conversion within this document would be R43 G104 B91 (instead of R43 G103 B90).
Converting from CMYK to RGB and back to CMYK continuously (=keeping the lock in the Color panel turned off), will change the color values gradually each time, and after a twenty conversions or so you would already have quite different color from the starting point. Depending on the document color mode and underlying profiles, and color models used in Color panel, an abrupt visual change could happen within just a few conversions, so keeping the lock habitually turned on (the state it is in also by default) is a good idea.
-
You could use Regex search for manually formatted even list number entries (or odd, as well, for applying formatting for odd entries) and have separate formatting for odd and even list entries, and use paragraph decorations to apply background stripe formatting. This would not work for automatically numbered lists (Find feature cannot find numbers in these kinds of lists...) For such lists, you can use "Apply NNN Style Then Next" feature to have alternating paragraph formatting. EDIT: The latter method could naturally be used for applying alternating styling for any kinds of paragraphs so there does not need to be any specific numbering scheme.
Here is the Publisher document used on the clip for playing:
-
The method this person is using in the YouTube video you referred is pretty good. Check carefully what she does since if the adjustment group you create does not work properly, you may have some secondary issue with the mask, the layer kinds (do you have your bitmap to be colored on a Pixel layer?), etc.
Please check the attached .aphoto document to see how this kind of a color adjustment would work on a generated texture on a Pixel layer. I have made the coloring a bit darker to show clearly the texture but basically the coloring itself is accurate, different contexts just require a bit different level adjustment and (optional) adjustment of layer blend options.
-
5 hours ago, Max Kaladin said:
I'll have to look into doing it in Photo or Designer then.
I mentioned Designer much because of its capability to create a document with exact size of a design pasted from the Clipboard, but since you have both Publisher and Designer, you could save the text on path objects as a Publisher objects, instead, to have the attached curve object editable (you will lose editablity of the path control objects in Designer).
But because you have Designer, you. could create a star object as a symbol, and then place symbols on the path. This way you can later edit e.g. the fill and outline color, size, even the star shape and whatever you wish using just one symbol instance and having the changed attributes replicated on other instances.
I also realized afterwards that text on path has its own baseline shift, which affects shape objects (like stars) placed on a path, as well. So to vertically center the stars in relation to text, you could first apply negative baseline shift to the text (stars not effected but text is shifted down to have the star shapes centered), and then shift up the whole construction using the baseline control specific to text on path object.
After having created the kind of a text on path object you wish, you can copy it onto the Clipbpard, paste it into Designer to have document dimensions that match the bounding box of the text on the path object, then use File > Edit in Publisher and save the construction as a Publisher document, and then finally place this file in a Publisher document and use Transform panel to have exact size specified for the boundign box of the object.
It is certainly a bit convoluted way of scaling an object but by combining capabilities of multiple apps, you can get pretty powerful features.
-
The issues with sizing can be worked around by exporting a selection to PDF or e.g. a Designer document and then placing those in the document, in which case the whole object could be uniformly scaled using the Transform panel:
When creating this, I noticed multiple anomalities (bugs):
- The new scaling override feature in context of Transform panel does not have the stroke width within the text frame related to text on path covered, so this setting needs to be applied separately. [EDIT: This includes also stroke widths applied to text on path, and stroke widths applied to shapes and symbols on path.]
- Shapes on path do not honor baseline shift, which means that e.g. stroke width attribute related to a text on path object and its distance from the text cannot be properly adjusted. The path element should probably be created as a separate element anyway so that it can be adjusted independently (this way the shape could also be changed using Designer).
- Note in the screenshot how the star shapes DO honor baseline shift when the "text on path" object has been removed from the path and "straightened". The object (now basically a "pure" artistic text objects) still has the text frame related stroke, but oddly shortened, and the attribute cannot be accessed because the text frame button is no longer shown in context of the object, unless the panel is first made visible by other means.
Because of these restrictions, it would be a good idea to use a font that has the required shapes in-built as glyphs.
-
22 hours ago, Walter Nissen said:
Thanks so, so much for your helpful videos!
You're welcome!
22 hours ago, Walter Nissen said:I need to think for this document what we want to do. It's mainly for print but it wouldn't be the end of the world to keep it all in RGB for digital. That seems like it could be a lot of work, though. I don't know.
What you need to do much depends on if you are going to have dual use for these documents, since if you are going to produce also to digital media and use (s)RGB color space, you have no option other than either change the underlying CMYK rectangle to RGB (using the same RGB values for the blue as the included bitmap), resulting in a bit different blue on display and paper, or converting the bitmap to CMYK (in correct color profile environment), in which case you will have that a bit desaturated blue in both instances. Either way you will get rid of the fluctuation. If you are only going to produce to CMYK, then it really does not matter, but to play safe, you could export forcing "Convert image color spaces" so that apps like Adobe Reader, macOS Preview app etc. will display the image coherently.
-
There is color management going on 🙂 The export preview is not color managed so it shows the RGB based image without applying it the document CMYK target profile, while when you have your Publisher document in CMYK mode, this will be done (as if you had a permanent Soft proof turned on).Here is a demonstration on what happens if you switch the document color mode from CMYK to RGB: the RGB image will be shown in its RGB color gamut so the same difference between the blue colors that was shown in export preview is now shown also on the canvas. The blue rectangle, that was initially defined in CMYK does not change (as the sRGB color space covers this specific tone of blue). Because CMYK is generally a narrower color gamut than (s)RGB, the more saturated light blue will become duller when converted to CMYK, or when its visual appearance simulated in a specific CMYK color space.
[Btw. Note the bug in version 2 apps when switching the color mode from RGB back to CMYK. The app seems to offer the current working CMYK color profile as defined in Preferences > Color, but actually the profile is not selected (this could be seen when re-visiting the File > Document Setup > Color immediately after closing the dialog box: the previously active CMYK color profile would shown being the active CMYK color profile.]
Note how an Image layer will not be converted when switching the color mode of the document -- nor will text or shape layers; the color mode and original definitions of the latter two (i.e., the native objects) stays untouched, as long as the lock of the Color panel is turned on. You can have these objects selected and switch between different color models within the Color panel and check how the colors would be converted in the current profile environment. However, when the lock is turned off, having an object selected and simply just switching the color model from richer to narrower gamut (like from sRGB to CMYK), will make an actual conversion and will redefine the color of the objects. Similarly, a copy of a placed bitmap, which is rasterized on screen, will become a Pixel layer, and be converted to the current document color mode (and would also automatically be converted when changing the document color mode, so this should basically not be done whenever having Pixel layers, since multiple conversions typically result in constant retranslation of colors on successive times because of rounding errors). A converted image would then show consistently also in the export Preview.
Here is another clip that shows how a color managed viewer (in this case Adobe Acrobat Pro) can handle mixed color mode PDFs. A PDF can have multiple color spaces, but as long as profiles are embedded, an advanced viewer can simulate visual appearance of the final product. So it is not necessary to apply "Convert image color spaces" PDF setting to force conversion of RGB images to CMYK, as long as the PDF is correctly produced. Apps like Adobe Reader, macOS Preview app, etc. cannot apply simulation profiles, and depending on the way the PDF is produced, the user might be required to choose the correct profile themselves.
While it is not necessary to have unified color space, this would typically be wanted when there is need to keep colors consistent disregarding whether producing for digital media or paper, and especially when the "same colors" in different color spaces overlap, like here. It could be achieved either by redefining the rectangle in (s)RGB color space, or like on the video, converting the bitmap to target CMYK color space. Often the more saturated RGB colors are wanted to be retained (especially in photos), so if the colors overlap, it is a good idea to specify colors of the native objects in RGB. The fact that Affinity apps cannot show RGB objects in full color gamut in CMYK mode makes this a bit inconvenient, especially since the color pickers display the color values always in the document color mode.
-
7 minutes ago, iconoclast said:
It would be a nice additional feature, if you could even do this. I had that case several times
Certainly, it is on oddly overlooked (or cumbersomely available) feature in graphic design apps.
-
35 minutes ago, iconoclast said:
If you want to have many circles with the same distance in a row, you can also use Power Duplicate
I believe you won't get the same distance, but instead a scale factor that will increase the distance in relation to the size of the last duplicate, so for each instance the distance gets bigger.
-
8 hours ago, laurent32 said:
Would you say that if the final PDF files look good on screen, we've got more than 85% chance print will be fine ?
I would not... I am not sure what you mean exactly but basically the lower the PDF/X version, lesser there is to check when getting the proof from printer (whether print proof or digital proof of processed file, if either is available; many printers do not provide either). If you leave mixed color modes (RGB), you are dependent on something like Adobe Acrobat Pro to simulate print output with correct profiles and checking by using Object Inspector how individual complex parts are handled. As for PDF/X-4 and any non-PDF/X-based export version, they support live transparencies and everything may look fine on screen, but you may be dependent on skills of print personnel to get those files correctly flattened and processed, so ripped proof would be necessary to check against possible processing errors.
But if you have a prepress tool, you can of course analyze the production PDF and also use its preflight tools to "look closer", so in this sense PDF files that "look good on screen" naturally predict well what you will get on paper. But the point is that being able to "see" is a kind of a special skill and requires kinds of special "spectacles".
-
I am not sure if you had this fixed already but here is the solution anyway.
A sample of merged document:
In case you did not resolve this, whenever you need to place data from the same record on separate pages (specifically on front and back of the same sheet), you need to have multiple Data Merge Layouts (as you did), but additionally handle the record pointer so that on the first page the pointer is not advanced, so that data is picked from the same record. The second Data Merge Layout then advances the record pointer. I additionally made sure that controls that receive data are placed as children of the data control. You had separate Data Merge Layout controls for the two fields on the back side, which can be done, but then you should make sure that the one at the bottom of the Layers panel also has zero as record advance value, so that the record pointer is only advanced after processing the topmost control in the Layers panel.
Color Wheels Different on Same Machine/Profiles
in Affinity on Desktop Questions (macOS and Windows)
Posted
Check if your other document is in RGB mode and the other in CMYK mode:
UPDATE: Though it could also be two RGB documents but just with different color profiles or different RGB bit-depths (8-bit/32-bit). The concept of "same" color is vague.
Adobe apps give the user an option to choose when pasting an object using another color profile either to preserve visual appearance (but possibly change color values), or to keep color values (but possibly lose visual appearance). That would be useful also within Affinity apps, which currently only support the latter method. But the video clip shows a different case, rendering the same color values in different color modes. When color modes are different, it depends on whether an app supports dual (multiple) color modes (and profiles) so that original definitions are retained even in different color mode (like RGB or HSL color values in CMYK mode and vice versa), but just rendered differently, according to profile-calculated color values without actually doing a destructive conversion. This explains why the "same" color values can have have widely different visual appearance in different color modes.