DanH

Thank you, Walt! That did it. Side note: If “known issues” have notes that Staff refers to when answering questions, this would be a great addtion to those notes.

Thanks! The problem with placing again is it increases file size. Whereas duplicating a placed image, even multiple times, does not increase file size.

Photo 2, iPad — Have not tested on other apps. Replication: 1. Place image, duplicate it. 2. Set the topmost copy to “K Only” 3. Exit to “Home screen” 4. Re-open the file, and see that the topmost copy of the image has reset to “K Only” being off. What appears to be happening is the lowest of the two image copies determines what the “K Only” will reset to. So an alternate replication process would be: 1. Place and duplicate an image 2. Set the lowest copy to have “K Only” on, and leave the top copy with “K Only” set off. 3. Exit to home screen 4. Re-open file, and now the top image has “K Only” set to on.

Just learned: the Quick Menu, which is in your second image, does nearly what you ask. But maybe you’re asking for more than the nine user selectable commands, and an expansion to the list of command options which currently is limited? On first impression, I think the grid design of the Quick Menu might make it hard to quickly find what I want except for any commands that I use a lot. Ideas to consider that may improve the Quick Menu: Color coded buttons, color being selectable by the user Option to add more columns and rows of buttons. One benefit would be more chances for empty spaces to better “design” the button spacing to allow a faster read and/or to arrange into categories. Command options expanded to all possible commands. Option for smaller buttons as currently found in the Edit menu. Option to layout the Quick Menu in the same layout style as currently found in the Document, Edit, and Selection menus (at the top left of the UI). So, option to be a list, or arrangeable into categories (i.e. Clipboard, Operations, etc.) with “buttons” in a column underneath each category just like Edit menu. Not sure if this next one, in practice, would actually be better, but worth an explore: Option to have the quick menu be identical to the Document, Edit, and Selection menus (in the upper left of the UI)—identical in layout and options, so, exactly identical. Basically just providing a slightly faster way to access these menus while also having them appear in the middle of the screen where it is a bit quicker to reach. Option to have one two, or all three of these menus to appear simultaneously. Afterthought: I wonder how much physiological benefit, if any, there is to “reaching” around the screen to access menus and tools, as compared to limiting “reaching” by having menus pop up at center screen which, perhaps, might be a bit ergonomically detrimental by keeping range of motion narrower. Sometimes a little change in how we move makes big a impact with actions done over and over.

True, and so what I mean to suggest is, when selecting a vector layer, make the color panel “smart enough” to know that I want to change the vector color, even if the brush is selected. Maybe make the brush’s connection to the color panel be “dormant” when a vector is selected, if that’s necessary. However, currently, when a vector’s color is changed, then when the paint brush is selected again the paint color has now changed to what the vector color was changed to. So, the color panel may as well let me change the vector color while the paint brush is selected because it changes the color of both anyway. (Sometimes I prefer to have the paint color switch along with the vector color. Other times I would not.) Maybe there is a better design, in line with your overhaul suggestions, but as it is currently designed, a small tweak is all I am requesting. Anything that will make it better and smoother. They need to ask us what we want before they do it. We have good ideas.

Photo 2, Designer 2, iPad or Mac. If using the Paint Brush on a pixel layer, then in the Layers panel a vector layer is selected in order to change its color, a different tool must be selected before the vector’s color can be changed. Some tools, when selected, allow the vector color to be changed, and some don’t. Clearly this is intended behavior, but I can’t reason out why. The app “knows” the vector can’t be painted on, so this may be why it stops the slider from changing—because there is a conflict of “which thing do you want to change color, the brush or the vector?”—but it could just as easily “realize” that I changed to a vector layer, so I must want to change its color, not the brush color. Then there’s the fact that having the Eraser or Clone Brush selected, which do not have a color panel connection, also prevents the vector color from changing. So, my workflow often looks like this: Change tool, select vector, change vector color, select pixel layer, select Paint Brush, paint It could look like this: Select vector, change vector color, select pixel layer, paint Is there sense to how it currently works that I don’t see?

Love it. Edit: wait, we have an almost exactly as requested function in the Quick Menu, which is shown but not mentioned in the second image above. Would also like something to help with this, but I’d probably prefer just swiping, with no tap. This would replace the current function where “scrolling” of the color swatch/circle causes the color to turn lighter or darker. Does anyone use it that way? For me, it’s so slow as to be not useful, and swipe to switch between color 1 and color 2 would be much more useful. Also, I’d like the X keyboard shortcut added for switching between color 1 and color 2. (Unification of all desktop and iPad keyboard shortcuts would make sense, too, for users who switch between both devices).

If you’re on desktop, press X on the keyboard. Is that what you’re asking? On iPad? Yes, please add a shortcut for iPad to switch between foreground/background color (color 1 and color 2).

I’ve searched help and online, with various search terms, and can not find any information on applying a fill color to a placed image in this manner, so your confirmation of it being a documented feature is assuring. Where can we find information about it? Seems strange to me, though, since that is not how it works when using the CMYK sliders when using the paint brush.

Oh thank you. Will test these different approaches further and see which I like to use. Following is a another approach that is promising, but concerned that it doesn’t seem to be a documented feature, so wonder if it will disappear and thus ruin what I have created with it: After placing an image, with it selected, the color panel sliders, as well as swatch selections, will recolor the selected image. I love this. So much. Any knowledge of documentation about this functionality? Also, does it make sense that when doing this, if all CMYK sliders are at O%, then moving Cyan (or Y or M) to 1% makes it just as saturated as if it were at 100%? (Works this way if the document is CMYK, but not when the document is RGB.)

Regarding Brushes Panel: Love it, but do wish greatly that when relaunching Affinity that the selected brush was shown. After relaunching Affinity you have to reselect a brush before it then visually keeps track of it for you. Regarding unnacceptable comments: Not defending the comment that was removed, but I see the instigating comment just as out of line.

How’s that for a catchy title? Photo 2 — 2.1.0 , happens on iPad or Mac Transforming of linked layers is out of sync if one of the linked layers is clipped inside a layer that has moved. Attached is an .afphoto file. In case it helps, the process: 1. Paint a shape. Select and move it somewhere else onscreen. 2. On a separate layer, paint another shape. Place it behind the shape in step one, and so they partly overlap. Duplicate this second shape. 3. Clip one of the duplicates into the shape from step one. Set its blend mode to multiply, to visually distinguish it from the unclipped copy. 4. Link the shapes from step two, but only link the Transform. 5. Select and move either linked layer. They move in sync. Now rotate, and see they rotate out of sync. Linked layers out of sync if Parent of Child has ever moved.afphoto

Double tapping the opacity “window” at the top of the layers panel, to reset opacity to 100%, causes the selection bounding box to disappear temporarily. Selecting and moving is possible, only no bounding box, until you pinch and zoom, then the bounding box appears again. Using: Photo 2.1.0 iOS 15.4

On iPad, if layers are deleted and then the file is Saved, there is no reduction in file size to reflect the deleted layers. If instead we use “Save As” it does reduce in file size. One example: a 90 MB file, that with “Save As” reduces to about 11 MB, but with “Save”, it remains at 90 MB. In contrast: On Mac, if the layer deletions are done on the same file as in the above example, I find I can just Save the file—not Save As a new file—and the file size shrinks to reflect the deleted layers. Suggestion: match the iPad to the Mac in this regard

Three times now a Text Frame created in Photo 2 has had a background color. Two examples shown, along with the original files they appear in. I don’t know how to reproduce it. Using: iOS 15.4, Photo 2 version 2.1.0 This recently happened another time, but the background was green. I used Publisher to clear it, since that is where there are UI controls for altering the background color. … Now may be a good time to request further unification of the UI between apps: Background color in the Text Panel in all the apps. I’ll stop there, to keep on topic. You may argue Frame Text background color is a feature set difference between apps. Maybe (maybe) the background color of Frame Text is a legitimate separate Publisher-only feature—but not when a bug makes it appear in Photo and I have to use Publisher to clear it. Frame Text — Blue.afphoto Frame Text — Gray.afphoto

I at least partly succeeded with your suggestions, and even though I still don’t really know what is going on, I now see something is happening that may be expected—well, expected by anyone who knows what is going on. The rest of this post is just me talking out loud to try and synthesize what I just went through, and you might skip it unless you’re very curious about my failures to yet understand the “why” of what is happening. In the end, for me this has been an exercise in realizing the useful Lessons Learned given below. Thank you for your patient help. My results of your suggestions: 1. Playing with the channels panel continued to show that the rightside texture indeed does not show any color while the leftside does. If I knew more, I’d probably see how this means something. 2. After trying to “add a rectangular shape nested with blend mode luminosity” and fiddling with it’s CMYK values, I only succeeding in creating different shades of yellow-brown, the results of how the yellow square (parent) was blending with the clipped rectangle (child) that I was using to adjust its color via the CMYK sliders. So, I may be misunderstanding, but I didn’t get it to yield “colorful results”, unless this is what you mean, that I would get shades of yellow-brown instead of only shades of gray. 3. Added a Channel Mixer adjustment layer to the rightside texture, the one that would not colorize. I was then able to adjust the black values for each color channel to get varying brighnesses of yellow. Adjusting any of the CMY values, in any of the color channels, did nothing. Guessing you will say this is as expected, but it isn’t something I understand. When I put the Channel Mixer adjustment on the leftside texture, it was adjusting the CMY values that yielded changes, while the Black value did not change the color. These behaviors seem to match your statement: “The left side is CMY mixed to rich black (but K zero), the right side is K only black (and CMY zero).” There’s some bit of information that I just don’t quite grasp for any of this to really make sense to me. Lessons learned: 1. Don’t make an image black and white with a black and white adjustment layer (when in a CMYK document) if I want to colorize it using Luminosity, because the channel mixer option to make it able to be colorized is far from ideal to me. Instead, make the texture black and white, export it as a jpg, and place it again. Then it will blend in a way that I expect it should. Or don’t make it black and white at all when this is not necessary for any other reason, since it colorizes just the same (using Luminosity) whether it has hue or not. 2. The channel mixer can be handy to tweak the occasional texture which isn’t quite the color I want it to be. But not very often because it drives me crazy randomly changing percentages for all the color channels to see what they will do. Also, the channel mixer controls are designed to make users frustrated. Probably not, but kinda feels like it. 3. Always post a visual, and workable file in the first post so others will faster understand me, since writing a step by step process may not be followed and therefore what I am trying to say is not understood. We’d have gotten to the point a bit sooner if I had.

Attached is a visual. Plus the original file. If you follow the steps layed out above they should produce the results I described and are evident in the attached image, unless I made an error in writing those steps. To test your statement that luminosity in CMYK would “not produce the same result as doing everything in RGB,” I copy and pasted the textured squares into a new RGB document (this image is not shown, only the CMYK document is shown below). Perhaps you are correct for certain situations, but for what I have done, the RGB version and the CMYK version look nearly identical, maybe a slight difference, with the exception that the texture in the righthand square became colorized in the RGB document instead of black and white. Alternatively, if the CMYK document is converted to RGB, the black and white texutre is then colorized. Edit: when testing another color, a different one than the yellow in the example shown, I see more pronounced difference. With that different color I switched between RGB and CMYK, and the texture portion changed more distinctively even while the untextured portion of the color remained about the same because it was within the CMYK gamut. But I am not clear on why I would want to work in RGB when I can work in CMYK so I know I am within gamut all along, and whatever the blend mode looks like that is what I work with. If the blend mode generates a color somewhat different than I’d like, I adjust it afterward to bend it to be what I want. [Side note: You may be thinking of someone else, because I have not previously posted about working in CMYK documents while using adjustment layers.] Luminosity blend mode example.afphoto

Edit: appears to be an issue affecting CMYK documents. This isn’t happening, it seems, in RGB documents. Also, a screenshot of the issue is provided in another post below. Luminosity blend mode doesn’t work as expected in the following scenario. Perhaps I am misunderstanding something. Steps: 1. Place any image in a document. Edit: Must be Placed in a document, rather than opening an image directly. (No, my mistake, it has to do with being a CMYK document, nothing to do with placing vs opening directly.) 2. Convert it to black and white with black and white adustment layer. Rasterize. Set blend mode to Luminosity. 3. Create another layer, paint any color on it (not black and white). 4. Clip the black and white image inside the painted layer. The image remains black and white whereas I expect it to become colorized by the painted layer it is clipped inside of. What is expected to happen is this: If you follow the above steps, but begin by “Placing” an image that is already black and white and omit the black and white adjustment layer step, then clipping the black and white image (while it is set to Luminosity blend) will cause it to become colorized by the painted layer it is clipped inside of. Edit: Following is a separate issue than described above, but still related to the Luminosity (or maybe just blend modes generally) acting out of sorts. Later, while testing more, in an RGB document, placing a couple images that were already black and white (so bypassed the Black and White conversion that seems to be causing the above issue in CMYK documents), and altough Placing images had previously worked as expected with Luminosity, this time they did not work, that is, they did not colorize, not initially, but then after doing something, not sure what, I think maybe hiding and unhiding the three different images that were clipped (each set to luminosity), then suddenly the colorization was occuring as expected. Happened once.

Love the Brush Panel improvements, but, if it would show the selected brush even after re-opening the app, then it would be loooove. As it is, when re-opening the app the brush panel does not show the selected brush until you re-select one. Using: iOS

You got me hopeful for a second. That works in Designer, for vector tools, but not pixel brushes. And the vector tools don’t have the issue of inconsistent placement of the size slider. Five gold stars for trying! Also, the fairly slow scroll of dragging on the stroke panel icon isn’t something I prefer, plus sizing up requires swiping up multiple times since it’s so close to the top of the screen. Opening the stroke panel to change the size is better than scrolling on the icon, but I’d just as soon use the consistently placed (for vector tools) size slider on the left.

—iPad—Brush and Eraser have their brush size sliders at the bottom of screen, while some of the other brush size sliders are at the top, such as the Smudge Tool and Paint Mixer. This doesn't make for smooth transition between using tools. Only logic I can think of is that in the event of not realizing a certain tool is selected, it may be a way to say to the user, "Hey, you're using a different brush than you thought." But that use is of limited value, and to me, hinders far more than it might help. Possible Solutions: 10 stars of you make the size slider placement consistent between tools. 100 stars if you make the placement of these UI features moveable, anywhere on the screen ideally, but at least an option to choose left, right, bottom, or top of the screen—most flexible would be to the point of being able to put my size slider on the bottom, and flow slider on the left—I don't want that necessarily, but some might, and I say this just to indicate in a short example just how flexible I am suggesting to make the UI. 1000 gold stars if you also allow the option to provide each characteristic (flow, opacity, hardness...) its own spot rather than piggy backing on each other. Doable even without the 100 star solution above.

Great! Came back to say, as you likely know, it isn't displaying the RGB color it used to be (before "conversion" to CMYK), but is displaying an even brighter color. Also, why does the Color Picker tool pick from where the finger or pencil is touching, but the Color panel's picker picks from the center of the magnifier? Preference is the way the Tool works, some may not prefer it, so maybe an option to set it to how the user wants. Unless that is what this is, a way to give people their preferred way of the picker working. But it is confusing.

As I see it, the article referenced—What Color Do Red and Yellow Make When Mixed? (+Chart)—supports my expectation that the RYB model would produce orange when mixing red and yellow. In addition to all their visual examples, they say: "RYB ... is a subtractive color model ... when yellow and red pigments are mixed ... this mixture will only reflect the colors that have not been absorbed, producing orange." The Help statement Walt quoted seems to indicate this result should also be expected in Affinity Photo as well: "RYB is a historical subtractive color model based on red, yellow and blue as primary colors." While it is true with the RYB model, as described in the article, "the more pigment we add, the darker the resulting color becomes," it is orange rather than brown which results from mixing red and yellow, as per the examples in the article. It also says: "In painting [i.e. RYB], mixing green and red makes brown," and Affinity Photo does do that. The article then states "In RGB, on the other hand, the same mix [green and red] makes yellow," but this is not the case in Affinity Photo's RGB model while using the Paint Mixer Brush, which makes a brown that is leaning toward yellow. So, I'm confused on what the RYB, RGB, and CMYK models (and what's Native?) in the Paint Mixer Brush are intended to do, and when they expect users would choose one over the other. Their RYB model at least seems mostly correct in emulating paint mixing except for how red and yellow mix.

Regarding: "highlighted even after changing size"— — On iPad it does stay highlighted at first, that's why I had thought it was fixed. But once you switch brush categories or tools it is no longer highlighted. —They are fixing this in 2.1 (in beta right now), at least on desktop:

Maybe not a bug, since it works the same on Mac and iPad, but RYB mix mode makes brown when mixing red and yellow. Don’t know why it would intentionally be designed that way, though, so maybe a bug.