lacerto
-
Posts
5,768 -
Joined
Posts posted by lacerto
-
-
It seems that blend mode fill opacity does not actually work at all for certain blend modes (e.g. Vivid) and color values, e.g. in the clip below where a blue ellipse on top is blended with an underlying rectangle with linear gradient from R255 G0 B255 to white (so the objects are sharing the blue channel all the way). There is no gradual change at all, but decreasing the fill opacity from 100 towards zero has the same "blend effect" right from 99% to 0%. In different conditions blend mode fill behaves less radically different compared with identical objects with reduced color and layer opacity but as for the assumed gradualness of fill opacity, the functionality simply just seems to be lost (= opacity is just 100% on or 100% off).
-
As mentioned, you need to have a raw image to get a Kelvin-based scale. And it is a scale that is based on color compensation. I am not sure if it is documented within Affinity Photo, but the feature seems to behave similarly as in Adobe Camera Raw:
https://helpx.adobe.com/camera-raw/using/make-color-tonal-adjustments-camera.html
-
2 hours ago, MikeTO said:
I don't have a Magic Mouse to test this on, but you could try turning off horizontal mouse scrolling in macOS.
I tied to find the damn device but could not find it, but the way I disabled horizonal scrolling was probably the "native" one.
-
2 hours ago, DJP said:
When I change to one of the built-in styles, such as 'Body' or 'Bullet 1' (which are based on 'Base'), the text still shows as 100% black. But if I open the style to edit it, I see CMYK sliders set to rich black (I guess . . . ), but these values are not applied when I check the box next to Text Fill.
This might imply that the document was initially created in RGB color mode, where text styles are based on RGB, and black text would be RGB 0, 0, 0. The CMYK conversion value of pure RGB black would be something like you mention, depending on the underlying CMYK color profile.
Note that if you switch the document color mode from RGB to CMYK, the style definitions stay RGB based. This can be confusing but it is a kind of a forte of Affinity apps that they allow this. It is similar as in InDesign, where support for multiple color modes is more controlled and enhanced, and also well documented.
-
10 hours ago, Old Bruce said:
As Walt said "It may be a Magic Mouse thing" My experience with Macs (about 30 years worth) is that Apple has worked very hard to make bad mice. Their trackpad is really quite good. I would never buy a mouse made by Apple.
I pretty much agree. Perhaps they had to try so hard to be a bit "innovative" to live up with the joke of suing Mickey Mouse (now partially PD) for a mouse (after losing the case against MS for windows)... As I myself have that mouse (but do not use it anymore), I remember to have found a utility that allows disabling the feature. Horizontal scrolling can be useful, though, and I have it in MX Anywhere 3 via Shift + mouse wheel, which works really well.
-
To me it seems that both are present (perhaps notation reading error? (120DPI = 120 DPI)
-
It is quite confusing. Check the video clip below to better understand how color controls in Affinity apps operate and how you can determine the actual color that an object has been assigned with:
In a nutshell: the two ways to find out the actual color a text or native object (shape) has, is to use the Color panel and turn the lock off (on macOS, you might need to de and reselect an object to have the color values of a model made active updated), or using the color creation button when creating a swatch in a document palette within the Swatches panel (and having the list view turned on so that you can directly see to color component values). Note: Remember to switch back the lock in the Color panel to avoid inadvertent color mode conversions since if the lock is turned off, just switching the color model in the Color panel will result in conversion of color mode of a selected object. [EDIT: Note especially that using color pickers will NOT show the true underlying color model of an object that you use the color picker for, but the color value of that object when converted to the active color mode that the document is currently using (and that can be switched, without causing conversion of existing color values of text and shapes; values of pixel objects, however, would be auto-converted when switching the document color mode).]
As for other controls, e.g. the Font Color rectangle on the context toolbar, or the Text Fill rectangle in the Edit Text Style dialog box, simply just switching the color model does NOT automatically convert the color model of underlying style, or selected object. But Publisher will "remember" the last model that was selected in these contexts so if you change to "CMYK" model, the next time you access the same controls, they would show CMYK models. Note that actually typing in color values or selecting a color when using a specific color model, would result in redefining a color value for a selected object, so always be careful when using color controls in Affinity apps. [EDIT: As for styles, you can also find the actual color definition in plain text, if you drill down deep enough and read the style definitions of the base style.]
Note too, that the active document color mode in Publisher (or other Affinity apps) does not mean that colors that you define for objects (texts and shapes) would be automatically converted to the document color mode (which many other apps do); instead, they will be saved in meta data of each and every object you create or edit, so different objects within a document can well have definitions based on different color models, like RGB, HSL, Grayscale, CMYK, and Lab.
So, to recap: In most contexts, just switching the color model within a color selector, will NOT result in conversion of the underlying color definition for a selected object, but only actual color selection, or typing in a color value (even if the same as the object currently has), will. But in the Color panel, just switching the color model WILL, unless the small lock icon is turned on (and by default, when you create a new document, it will be turned on).
-
On 3/21/2024 at 1:35 AM, CT15 said:
Thanks for this. I normally do so when using two vector objects. Just found it weird that it wouldn't export as is, but when only adding a black background, no white boxes appear on PDF export. Even with the layer using erase blend mode.
Erase blend mode easily back fires when combined with adjustments (like inverting curves), and it basically always needs something against which to erase so if your purpose is to create cuts (see throughs) and place them on top of arbitrary backgrounds in other documents, this does not work. As mentioned, you need to create such shapes by using vectors. But if your design is self-contained and rasterization is not a problem, then Erase mode can be a great way to create the kinds of distressed textures your are having here.
-
On 3/20/2024 at 10:21 PM, Return said:
Perhaps the xnconvert or the batch convert in xnviewmp is an option here.
Quite possibly for OP, but for the kinds of tasks I need it (using a specific palette/colormap for quantization, combined with (percentual) dithering), it seems that not.
-
It seems the cause is the Erase blend mode applied on curves creating the text in left and right ribbon, and rough in the Underdog and Barbershop treatments. The former are easy to fix by merging the curves forming the text and subtracting them from the surrounding curve object, but the rough needs to be created in a different way (the underdog and barbershop "texts" and roughening objects should both be either curves or raster elements).
-
6 hours ago, David in Яuislip said:
magick identify -verbose test.bmp
Thanks, that is useful!
I have a yearly need for updating 4-bit dithered RLE compressed bitmaps using a custom palette, and Photoshop CS6 has a bug when saving back to 4-bit. Current version of PS has this bug fixed but I will stop subscribing sooner or later, and Magick could be a good replacement.
Btw: I could not make +dither work for turning off dithering but 'magick clipboard: -define dither:diffusion-amount=0% -colors 16 bmp3:im_nodithering.bmp' can be used as a workaround.
UPDATE: Having played with ImageMagick for a few hours, my conclusion is to recommend GIMP as an alternative, if Photoshop is not available. It handles e.g. Floyd-Steinberg dithering especially with colormaps way better (much in Photoshop style) than ImageMagick, and if retaining of existing palette is important, GIMP is probably the best free tool available for the job. [But because command line tools typically have a pretty steep learning curve, it may well be that I have just failed to learn use the tool optimally.]
-
3 hours ago, walt.farrell said:
Save is enabled for raster formats that you've Opened, and for PSD if you've Opened one and you have the "Save over PSD" option enabled in Settings. And for the Affinity file types, of course
Yes, I know. Therefore (IMO) it should not be enabled for formats that cannot be directly saved. It is not directly obvious which formats can, so hitting Ctrl/Cmd+S and trusting that Save As will be opened, might result in inadvertent overwrite in those occasions a TIFF, PNG or JPG (or PSD, if enabled) has been opened (and can be saved back).
[In other words: IMO "Save" should be available only for formats that CAN be saved back. So just for the native ones and those mentioned above, never for TGA, GIF, BMP, WEBP, or PSD (unless allowed) -- or any vector formats, either. IMO the extension of these formats should be removed right when a file of this format is opened, to make it clear that the file will be saved using a different extension/format, but this, of course, is not necessarily obvious on macOS or if "known" file extensions (made by default unknown by the OS) have been hidden.
-
50 minutes ago, David in Яuislip said:
magick clipboard: -colors 4 bmp3:test2.bmp
ImageMagick is an excellent free utility but why force colors to four instead of allowing the maximum of 16 (in a 4-bit image)? Whether the image is allowed to dither or not might also be worth a consideration (for some reason I could not turn off dithering with +dither command switch). Compression is yet another parameter that might need to be attended if retaining existing properties is important (especially after transferring image content via Clipboard).
-
-
At least on Windows, if a publication that is defined as part of a book and has already a section definition created using Section Manager, it will have the Section Manager specified starting page number listed in the Book panel, and updating the page numbers from within the Book panel, or trying to redefine the starting page number from within a chapter (using Section Manager) does not have any effect (the starting page number box is not grayed out but the control is read-only and any changes made do not take effect.
The only way I could fix this was removing the chapter from the Book panel. Thereafter the Start page control of a chapter publication becomes available in Section Manager and can be set either to the desired page number (if for some reason an exception / non-continuing page number is wanted to be used), or just setting it to 1, in which case the starting page number will be continuing and set up automatically.
I have not yet grasped the functionality of "Update numbers" button of the Book panel. At least it will not override chapter specified starting page numbers (and as said, Section Manager cannot be used to correct page numbering as long as a publication is part of a book, either). On the other hand, any changes made to page numbering style by using Section Manager, are immediately reflected on the Book panel, so there is no need to use the "Update numbers". button. I have not tested this on macOS but there the feature might work differently.
-
Hello @CT15, and welcome to the forums.
Can you post a Designer file for inspection? It is not clear whether the document was in RGB or CMYK and colors defined in RGB or CMYK but note that using the Invert adjustment will rasterize the design when you export so it may play part in the problem.
-
I am not sure if the macOS versions can even open BMP format [checked it, and they can], but on Windows at least most formats (1-bit, 4-bit, 16-bit but not 32-bit Windows formats, at least non-RLE versions) can be opened (even if immediately converted to RGBA).
A bit oddly "Save" command is left non-grayed for opened files which is very misleading since for certain formats saving vs. exporting is actually available and the command should clearly indicate ability or inability to save to the opened native format by using enabled / grayed out menu command, instead of just automatically showing the Save As .aphoto dialog box when saving back cannot be done (the price is that if "Save As" fallback is always assumed, then the user might actually save back and inadvertently overwrite the original file in cases where saving back is actually supported). But Affinity apps do this for other file formats, too, e.g. SVG, so I guess this is "by design".
As for BMP, Affinity apps would nevertheless mess most BMP formats even if they could save them back, or export to BMP, since indexed files are practically not supported, at all, nor are 1, 4 or 16 bit files in any format. It is pretty complex format and it is best to continue saving them using apps like Photoshop.
-
It seems this is pretty complex. First of all, when exporting from an RGB document to an RGB PDF, the only gradient that made it through to Adobe Illustrator as a gradient, was one on the bottom left which has three stop points defined. The one on the top left (with only two stop points) made it through non-rasterized as "non-native art". Both rectangles on the right were rasterized, no matter what. They were possibly defined a bit oddly (with transparent tool instead of defining opacity directly for stop points?), and mixed with HSL and RGB definitions, but changing this (removing transparency tool settings and defining all stops in RGB with opacity values) did not seem to have any change in behavior when opening exported RGB PDFs in Illustrator (CS6 was tested).
But I had earlier tested this only with CMYK exports, and it seems that is crucial; note that you need to export using settings that retain live transparency (any non-PDF/X-based preset, or PDF/X-4).
When you do, the gradient itself is retained, and transparency is achieved by using an opacity mask with gray levels indicating the level of transparency:
Attached is a Designer document where I have taken the bottom left rectangle with three stop points and added reduced opacity levels for two stops and then exported using PDF v1.7 to CMYK. As can be seen, when opened in Illustrator, the gradient is retained (showing as "Path"), and above the opacity is being edited by activating the opacity mask and setting the gray value of the middle stop (I made it 42, the same as location value, which is same as 58% gray). A green rectangle has been placed below to demonstrate the gradually increasing transparency.
This seems to be a PDF limitation within Affinity apps, since when exported to SVG (always RGB), there are no problems retaining the gradient when opened in Illustrator, and opacity values are directly defined for stops:
The Designer document used for exporting the gradient is attached, as are the exported PDF and SVG.
-
Interestingly, forcing conversion of image color spaces in context of PDF/X-based export methods also seems to restitute the "K-Only" effect for "K-Only" images that have adjustments applied (and which otherwise result in conversion to four-color state when exported). When examined in Adobe Acrobat, such objects seem to have both grayscale and K-ink version of a CMYK image included in PDF/X-4 and all non-PDF/X based export methods, but the values show as K-values only in PDF/X based versions. PDF/X-1 and X-3 only have the CMYK K-ink included. This is quite confusing (and also feeble, knowing the restrictions involved in PDF/X-based export methods).
-
2 minutes ago, mykee said:
Thanks for the video, I absolutely understand what to look out for then
You're welcome. You could also colorize K-only images, e.g., making them K100 using the Color panel (instead of being void of fill), and then applying swatch opacity, would equally retain the K-Only images as K-Only.
-
1 hour ago, mykee said:
For example, in the case of opacity, why can't a K-only image be made to take x% of 100 as the export value, since black is greyed to white during opacity. So 100 opacity is 100 K, 25% opacity is 25 K, or no?
But doesn't it behave that way? Layer opacity does not cause a K-only image to become converted to CMYK. Layer adjustments (and most of the F/X blend modes) do:
-
31 minutes ago, mykee said:
The only thing I don't understand is that if I told the program to use only K-only for the images, it shouldn't include CMY when exporting, since the K-only option is inherently higher level, prohibiting the use of CMY
That is not how it works, though. If you want to apply K-Only on an image and have it exported on K plate, it must be the sole operation on that image layer. You could apply K-Only, then apply adjustments (which cause the image to be handled as an RGB resource), and once finished, rasterize and convert the resulting pixel layer back to image resource, and then apply K-Only again, to force pixels on K plate. Or, you could export a K-Only image with adjustments explicitly to grayscale. That is admittedly quite convoluted.
-
Just now, Ken Hjulstrom said:
The document I'm working on isn't musical notation; it's a 40-page magazine containing about 60 images, about 80% of which are full color, and text, mostly black, and mostly sized between 9 point and 12 point.
My apologizes for all wrong assumptions!
-
2 hours ago, Ken Hjulstrom said:
The new shop recommended the 60.40.40.100 "rich black", and I'm assuming that this is one of the adjustments that they did in preparation for the second test print.
If it has been tested there is no doubt that this will work perfectly!
The method I was referring is based on color profiles and basically guarantees that too much ink is not applied, taking into consideration the actual media that will be used, while the visual appearance should be retained and be kept neutral, but that method would never result in K100 + a specific mixture of CMY inks applied, so the result could be less "rich", less intensely "black" than when using a predefined mixture where K100 + CMY mixture is applied (especially when tested).
If I am assuming correctly, your are applying this to musical notation, and in this case the rich black would also be applied to thin lines like staff and stems (as all elements of the score would be created using fonts and fills), so therefore I was wondering the purpose of this procedure. But as you're printing digitally, misregistration issues are different from offset printing, and if they happen (showing as misaligned colors), would show anywhere and not just in thin and small objects, and the remedy is also different (done on the device and not in the design).
Layer Fill Opacity in Blend Options
in Affinity on Desktop Questions (macOS and Windows)
Posted
I noticed that the blending effect can vary a lot when exporting to CMYK and that graduality of the fill opacity set in Blend Options can come back:
The document used above is RGB/8 and all color definitions are RGB based. The effect shown in the clip when exporting to CMYK would happen only when exporting to PDF, but not when exporting to CMYK JPG or TIFF. It is pretty much impossible to predict in what way the blend option fill opacity will differ from fill opacity set in the two alternative ways, so this is really just something experimental. But as the difference of effect is stated in documentation, the feature probably works "as designed".