F_Kal

It's been bugging me for a long time now; but I can't seem to grasp how to properly "dynamically" blend with clipping. Let me show you an example - Assume the following bedroom. I have a bed and the room with the rest of the items. And I have an overlay (a layer that I call filter) but It could had been a bitmap or another group for all I care - it's something that enhances the appearance of the underlying layers. What I'd like to do now, is export the bed only with transparency and I'd like the "filter" layer's influence on the bed to be exported too. But I need it to be limited to the area of the bed, so that I can have the transparency around it. In photoshop (when working with vectors) I'd go and assign this overlay/filter as a clipping mask. In affinity this wouldn't work since when assigning a layer as a mask, only the path is retained. Blending modes and colors are being stripped. Here is what I'm trying to do as done in PS As seen on the next image, in AD I could duplicate the bed's outline in a new curve layer and use it as a mask on the filter layer, but what if I had dozens of objects that I wanted to export? What if I was adjusting the bed shape and had to rember to update all instances of this outline? There has to be some quick way of doing this blending without all this manual and tedious work. What I'm asking is "take this layer, and limit it's effect, on this group of layers". How would you do this? Thanks! -Fotis

+1 for being able to alt+click on the checkbox and toggle displaying (this/all other layers) being able to easily view layers in solo is very useful in animating!

I couldn't find a way to rasterize the effects(Fx) of a layer without mergin the effects to the parent layer; the rasterize... command gives the option to either merge the effects into the pixel data or retain it. But is there no way of creating a new layer that contains only the effect? (for instance when you wish to have multiple shadows or multiple strokes)

By no means am I an expert, but I'll try and summarize everything being said here and give some further suggestions regarding color sliders! What is expected? Let us agree that 1) if you work on a CMYK document, and choose via the CMYK sliders a CMYK value (eg. 0,0,0,100) and then save that document as a CMYK file, the file should contain the precise CMYK values you handpicked. 2) if you print a CMYK file with pure colors (eg cyan:100,0,0,0 or text-black: 0,0,0,100) and the printer treats it at face value, the pure colors should appear... pure with no halftoning. 3) The printer will decide on its own how it will print the CMYK values it gets though (some home printers will convert it to RGB first and the back to some different CMYK value if you are unlucky). 4) if unintentionally someplace in the creation process you switch to RGB, then some conversion will happen. RGB 0,0,0 is translated into CMYK 78,68,58,94 on Photoshop. It is translates to CMYK 72,68,67,88 on Affinity Designer. But this is because there is conversion from RGB to CMYK and conversion is something subjective so both pieces of software make a guess about what color this would be (in particular when there isn't an absolute RGB colorspace defined such as in the case when you are working on a CMYK document). What works - can you reproduce this? I've created a CMYK document in AD, created a rectangle, entered on the CMYK (color) slider 100,100,100,100, exported it as a PDF and imported it in InDesign. InDesign correctly reports a 400% ink coverage with 100% on each channel. I don't see a problem here. If you have a problem thus far, you've stumbled upon some bug that is not affecting everybody. Keep reading to determine if there is no omission on your part or an actual bug. What could be wrong if the color values inside the PDF file differ? If you use some RGB colorspace anywhere this imposes conversions and probably is the cause of your problems. Any of the following could be the culprit: 1) upon creation you chose a document type other than CMYK 2) you exported the file in some RGB colorspace 3) (this is a funny one, very annoying) you used the RGB (color) Hex sliders and/or the RGB (color) sliders(!) to adjust your color. You manually set a 100,100,100,100 CMYK value and then switched to the RGB or HEX sliders where it appears as 0,0,0/#000000. You think that you didn't change anything but when you go back to the CMYK sliders you realized that now the colors are 72,68,67,88! By using the hex/RGB sliders you were playing in the RGB field and there you are bound to have some conversions happen. Annoying, but easy to avoid if you keep it in mind (Photoshop suffers from that too) What could be wrong if the color values inside the PDF are correct, but the printed colors are obviously different "than expected"? Apparently one can not really expect the same colors on his RGB monitor and his CMYK print (unless monitor & printer are profiled, and you have a Soft Proofing layer for your paper type in affinity). Having said that pure colors should be pure and rich black should be deep (deeper than pure black) if this doesn't happen it apparently is the printer or the printer-driver's decision to render the color differently than our expectations. There may (or may not) be some way to force the printer to print it differently, but I wouldn't think it has to do anything with Affinity (maybe a different filetype or some PDF flags could force the driver to treat the file differently, but I have no idea) hope it helps!

Cmd+] allows you to move a layer/group up/forward one position. Cmd+Shift+] allows you to move it to the top of the stack (becomes foremost). But if this layer is inside a group (or underneath some other layer) Cmd+] and Cmd+Shift+] will not allow you to move outside the parent. On PS you can press it once more and it will escape the hierarchy. Is there perhaps some way of doing it in AP (other than using your mouse)? Thanks!

That's a good idea @R C-R, thank you! And you reminded me that at some point I need to backup my shortcuts too!

ah! Thank you all! @R C-R very good idea; I had forgotten that all menu items can have shortcuts - I assigned a shortcut to it and it works just fine now! Well, needless to say that the super combo for "previewing" (Cmd+; Cmd+Shift+; Cmd+R Cmd+Ctrl+F Tab Spacebar and then again release Spacebar, hit Tab, press Cmd+Ctrl+F Cmd+R Cmd+Shift+; Cmd+;) is a bit too much unless you are trying to kill the final boss, so maybe a proper(=one step) previewing functionality could be devised by the affinity people spacebar is a nice shortcut for hiding the bounding boxes, so maybe it could be extended to temporarily hide all else too? (just a thought) Thanks again! -Fotis PS. The default shortcut for Spelling Options... was Cmd+Shift+;

Thank you @MEB for the tip! Not the most simple way of doing it (for quick previewing), but definitely a useful option nonetheless!

Ah, yes that is good! Thank you for the feedback!

Thank you Petar_MK! But I was referring to Affinity Photo! (useful shortcuts though for next time I work with InDesign!)

aha, Spacebar hides the bounding boxes! But I haven't found a way to hide spelling errors so far

I've been wondering if it were possible to quickly hide all non artwork elements for previewing purposes? so far, I have to press Cmd+; to hide the guides Cmd+R hide the rulers Tab to hide the UI elements/panels (In PS you could press F a few time to go totally full screen) but how would one temporarily hide things such as spelling errors (the red underlines) and bounding boxes (around shapes)?

The title says it all :-) By default, Document -> Resize Canvas... (which is expanding the canvas, not scaling the existing pixel data) scales both dimensions proportionately (the lock is engaged). I believe this is unnecessary - in my experience, more often than not, you wish to expand one of the two dimensions (width or height) and not both at the same time - and even when you do, it's not because you want to retain the original aspect ratio. I can think very few cases where extending the canvas proportionately is useful. Alternatively, it should remember your last selection (locked/freeform). At the time (1.5.2 beta 4) it does not - it keeps reverting back to the locked every time you decide to extend your canvas a bit! Hope this helps PS. I'm not referring to rescaling the image (Document -> Resize Document..) - This of course should by default be proportional - no changes there!

+1! Would be a really neat feature, I was impressed when I saw PS do that (but to be honest, I lived the past 15 years just fine without it too)

@dasigna glad to hear that you made a newer thread about the CMYK issues - it seems that TonyB is on it, so I'm sure you (and along with you everybody else who has/will encounter a similar issue) will get to the bottom of this!

Thank you @R C-R! I thought it were possible, but never changed the shortcut - I still hope that one day I'll get used to the AD way of doing things ;-)

Ahhh! I can totally feel you! I keep pressing Cmd+Enter to exit the text editing mode and by the time I discover my error, I have to rewrite the whole text!

I got here because I'm keeping an eye on all color management topics in the forum. The technical issues raised by @dasigna are valid, and me among others would love some feedback by the Affinity team; the thread has trailed off however and I doubt anybody would be interested in reading through all that (my comment has sadly added to the bulk) @dasigna, I suggest that for everybody's benefit you report the CMYK rendering issues you are facing in the bugs section of the forum; same for the problem with the corel ai files - a separate thread for each problem would be the best way to address these since they are not related - I'm sure the team would be interested to know that there are things broken (plus that you get the satisfaction that you are working with the team)! Also, [here]'s a thread in the feature requests section that discusses why 16-bit CMYK was not implemented - You may wish to reopen the discussion (hmm, I'm not sure if reopening it or creating a new feature request is the better approach - somebody more experienced may wish to comment on that) and add your voice to why it's useful having it. And of course, I'd make a new thread in the Features Requests section for every feature that I wish to see implemented (eg. "soft-rip and printing without profile") ! Hope this helps!

I'm not knowledgeable on the topic of color management (I'm just starting), but if I'm not mistaken, you shouldn't embed your monitor's sRGB profile into the picture; wouldn't that profile get overloaded on top of your iphone/ipad's display profile, causing further alterations in the colors? Instead, I'd embed a generic sRGB colorspace into the picture such as the sRGB IEC61966-2.1

I'd like to raise awareness to an issue that's bothering me (and apparently a few others) for over a month now. At first I hoped that my muscle-memory would get used to it; but a few hundred raw photos later, it's still as annoying as the first day. I'm referring to the way one can exit/quit/cancel development: it's very counter-intuitive. - It's totally understandable that one cannot proceed editing the image, if it hasn't been developed first. - It's also understandable that the adjustments in the develop persona, cannot be retained, unless the image gets developed. here are the quirks and some workarounds: - If develop persona were implemented as a modal, the Esc key should allow one to... escape. - If develop persona is not a modal and is a window/tab then Cmd+W and Cmd+Q should both allow you to close the document just like pressing the Cancel or X button (of the tab). The current message box when pressing Cmd+Q/W, is not meaningful: it's merely stating that you have to click elsewhere to cancel/close/quit. Why all the hoops and loops? This is particularly inconvenient when having dozens of develop personas open and you decide it's time to quit the application (or close them all). What could had been done with Cmd+Q is now mouse gymnastics! You have to close every develop persona individually, with the mouse, before you can quit the application. - The cancel button, and the X button, shouldn't act differently: As it is, the X button never asks for confirmation, whereas Cancel always does! - when you haven't made any adjustment in the develop persona, canceling should not ask for confirmation. It should be performed silently. - The confirmation should be rephrased. The yes no buttons are not very helpful. Yes, I want to cancel? Yes I understand? Yes I want the file saved? Yes I want it developed? If it were a rare occuring dialog, it would be okay to have and read all the text to know the meaning of Yes/No, but I see this dialog more often than I am asked to save a file, and I guess others too; so the buttons have to be as self-explanatory as possible; or the text as short as possible. eg. "Discard Changes?" Yes/No An example (not the most thought out apparently) follows - it shows two self-explanatory options: "Cancel & Discard" and "resume developing". It could had been "Discard Changes" and "do not discard" or it could even had been 3 buttons such as "Discard Changes", "resume"/"return" and "develop and Save as...", but you get my drift: it needs rephrasing. - Pressing the Esc key while the confirmation is displayed, should work (currently it does nothing). Hope this helps :) -Fotis Now that I got it out of the system,I have to say that I've started to really appreciating the Serif raw engine (and its speed) compared to other raw develop options!!!!

thank you @Fixx!

I've read that AP's raw converter supports reading from some uncompressed DNG files produced by some Leica cameras. But does it support Adobe's DNG beyond that subset? Or are there unimplemented features?

thank you @hlarledge!

Hi @hlarledge! Thank you for the feedback! Does the article refer to the white balance issue in particular? I'd be curious to read this review if you happen to know where to point me to! As a sidenote, I've read many reviews/complaints on other photography related sites, but most people who were having issues with the quality of Serif's RAW development engine were referring to some earlier version that would open files flat without applying the slightest adjustments (eg. chromatic noise reduction), thus creating a very coarse (ie raw) and seemingly "ugly" initial result when/if compared to other engines such as Apple Camera RAW or the Olympus Viewer. These were unfair comparisons imo though, since those engines out-of-the-box would apply preset adjustments and it was rather easy to achieve a very similar result with Serif's engine during the RAW development process - if only you would tweak the bars. Eventually Serif started applying some subtle and safe initial adjustments to match the results expected by users - for instance any image you open for development starts with preselected 40% chromatic noise reduction and automatic lens correction enabled. So far, I've only detected 3 issues with the RAW engine: - This particular problem with the white balance - Problems with automatic lens correction for specific lenses and cameras (expected to be ironed out in the upcoming beta) - issues with the demosaicing process (here and maybe here) - even though I'm not sure I prefer with demosaicing in other RAW engines: they sacrifice too much actual information for less high-frequency-noise.

Hi Michael, glad I could help. Yes, I was also using an X-rite calibrator: I used an old-school i1 Pro (i1Xtreme). X-rite products are certainly very good so I don't think you can go wrong with the i1 display pro model. Still before you invest money, you should better speak with somebody who is more knowledgeable than myself. I had never used a calibrator up to a month or so ago, and even then I just happened to borrow one that a friend had lying around. All my understanding comes from speed-reading threads and articles on the web, but when it comes to actual experience? None. Zero. Plus that I haven't printed anything (pro or at home) since 2005! Being a UX and web-designer I target uncalibrated monitors of web-users. I did my calibration merely out of curiosity, and because I found the calibrator lying around. It's not something needed in my line of work! If (as an amature non-professional) I was about to print bitmap/pixel data, I could go either with TIFF or PDF since both can can hold CMYK (I haven't delved into PDF flavors). If you send a PDF, just make sure the embedded bitmap images are compressed in a lossless way, otherwise you may end up with artifacts. For a few pages, I could go with CMYK TIFF but for a whole book I'd go with a CMYK PDF, since it's easier to distribute. However, If I was about to print vector data (everything that Affinity Designer creates), or mixed content (eg. a book with photos and vector lettering) in theory I'd go with PDF since it can hold both vector and bitmap data and thus produce smaller files and sharper prints. Since you are using Affinity Designer, I suppose you do vector-work, so there is theoretical benefit in using PDF, as long as Affinity designer doesn't rasterize any stroke by accident (read this old bug thread). How to check rasterization didn't happen? While Exporting the document in PDF, check if it says "some areas will be rasterized" like in the image below. If it does then some of the vector line art will be converted to bitmap and this may look strange. In case there are unwanted rasterized elements in the PDF, expect them to be less sharp than the sharp vector elements. At this point you have to make a decision based on the nature of these rasterized elements. If it's not a book where sharp text is of paramount important, it's often easier to opt for a TIFF file that performs rasterization all over your page (with the slight albeit uniform softness this implies), rather than be sending a PDF that mixes both soft and sharp shapes in an uncontrolled manner. Hope it helps! -Fotis