![](https://forum.affinity.serif.com/uploads/set_resources_8/84c1e40ea0e759e3f1505eb1788ddf3c_pattern.png)
kirkt
-
Posts
440 -
Joined
-
Last visited
Reputation Activity
-
kirkt got a reaction from aslusers in Masking does not work
On the brush toolbar across the top of the application window, make sure "Protect Alpha" is not checked when painting on the mask. Also, you can Option-click (ALT-click) on the mask layer so that it becomes visible when you paint - this is an easier way to see the precise effect of the brush on the mask compared to the composite result painting on the mask should produce.
kirk
-
kirkt got a reaction from AlexRonda in Editing a mask?
If you want to use a grayscale representation of an image as a mask (for example, using the luminosity of the image to modulate an effect), you need to create that grayscale image and then apply it as a mask to the layer you want to modulate. For example, open an image as the Background layer. Make a Recolor adjustment layer above the Background - it will recolor the Background image as it should. Let's say you want the recoloring to take place only in the shadows (the darker portions of the Background image). In the Channels palette, right click on the Red, Green, or Blue channel of the Background layer (whichever gives you the proper contrast and luminosity you want) and select "Create mask layer." A new layer appears in the layer stack that is a mask. Drag it onto the Recolor adjustment layer and it will modulate the recolor adjustment - in this case, because you wanted to recolor the dark portions of the image, you would need to INVERT the mask layer - select it and use the keyboard shortcut CMD-I (capital letter i). Done.
If you do not want to use a channel as above as the mask, you can make a grayscale copy of the image with normal tools and then right-click the resulting grayscale image layer and choose "Rasterize to mask" and drop that on the Recolor adjustment layer.
If you then ALT-click on the mask layer, it will be displayed as a grayscale image, just like in PS. In this view, you can paint on it, etc. You can also modify it will an appropriate adjustment layer, like a curves adjustment layer - add a Curves adjustment layer to the layer stack and drag it onto the Mask that is already nested in the Recolor adjustment. It should appear below the Mask. Then, and here is the KEY to making this work, in the Curves adjustment dialog, you need to select the RGB ALPHA curve to modulate the mask. Manipulating the Master curve, or the R, G, or B curves will do nothing to a mask. Now you can change the contrast of the mask with a non-destructive adjustment layer, which you cannot do in PS (that is, when you adjust a mask in PS with a Curve, it is a destructive change to the mask).
Kirk
-
kirkt got a reaction from DeJeanB in Window Pulls in real estate photography
You cannot set a mask to Darken or any of the other layer blend modes, in PS or in AP. (Note: in AP, you literally can set a mask to Darken mode, but what is it darkening or blending with?). A mask is just a grayscale image that controls layer opacity. To composite the Window Pull, you are simply setting the Window Pull layer's blend mode to Darken and then painting in white on the inverted (black) mask to reveal the Darken effect in the area of the Ambient, blown out window. The bright, flash-illuminated edges around the window in the Window Pull are lighter than their Ambient counterpart, so the Darken layer does not appear in these areas, as intended, making painting the mask a pretty straightforward, loose process. If shot correctly, you almost do not even need to mask the Window Pull in Darken mode, but most images have a large FoV, so there will be areas in the Window Pull outside of the window area that will comp into the Ambient without a mask, requiring you to paint a loose mask for the window.
It works just like PS.
Kirk
-
kirkt got a reaction from SuffolkCindy2 in New camera canon EOS R not downloading to Affinity in good quality.
@SuffolkCindy2
You may want to elaborate - rubbish as in, what? Is your version of Affinity (Photo, I am assuming) up to date - meaning, does it support the relatively new .CR3 raw file format correctly? I downloaded an EOS R raw file (.CR3 file) from imaging-resource.com here:
https://www.imaging-resource.com/PRODS/canon-eos-r/Y-JG-458A0719.CR3.HTM
and opened it in AP v1.10.1 on Mac OS 11.6 (Big Sur) with no problems. There is nothing particularly glaring about the image that would cause me to think there is something wrong with the conversion.
Upload the raw file to a post in this thread and readers can take a look at it and see if they can reproduce your problem, once you describe the problem. Also, Canon DPP software uses screen drawing that always looks a lot sharper than other applications - at least it traditionally has, I have not used it for a while now. All raw converters will render the raw data somewhat differently. Take a screenshot of an offending raw file opened in the Develop persona and post the screenshot here so we can see what you are talking about. If the conversion looks like it has been tinted pink or purplish across the entire image, then you need to update your version of AP - that is a telltale sign of a raw converter working with a file that it does not support.
kirk
-
kirkt got a reaction from ThatMikeGuy in Node-based UI for AP. Please?
While I do not profess to know how AP is structured under-the-hood (bonnet!), it seems like a lot of the tools are implemented in a real-time, live way that seems as if they would work in a node-based workflow. For example, the node editor in Blender or Davinci Resolve. If this is the case, it would be an incredibly terrific feature if the user could select between the current "traditional" interface and workflow for AP, or a node-based interface. I would love to be able to create an image-processing pipeline with a network for nodes with preview renders along the way to see each stage of the workflow and variations of the node chain. It would be terrific if node groups could be saved as "presets" that became single nodes themselves, which could be expanded and the contents exposed for tweaking and customization.
Please consider this approach, if it is possible. Rendering low-res preview proxies during node assembly would hopefully be a lot less taxing on the interface than the current full-res rendering of Live Filters that tends to get laggy when there are even a modest amount of layers in the stack. You could save full, non-destructive workflows as a pre-built node chain, you could have a single node chain branch into multiple variants, and have a batch node that feeds an entire directory of images into the node chain for processing. Maybe even macro nodes, etc. It would be so much more flexible and serve to further differentiate AP from PS.
The output of the node-based workflow could be fed into the "traditional" photo persona (a Photo persona node) for local, destructive edits, painting on masks, etc.
One can dream.... LOL
Thanks for pushing the boundaries with your applications.
Kirk
-
kirkt got a reaction from ambersand in Pasting Images Into Alpha Channel
@Tatom
You might consider using "Apply Image" which is macro-able and will pack channels with equations, bringing in each external texture file and placing it in the channel of your choosing in your working document - you do not even need to open the texture files to copy and paste them (you don't need to do this in PS either, because you can also use Apply Image in PS). If you have a disciplined workflow, where each texture is named according to a consistent naming convention and you place them in a directory where the macro is made to look, then the whole process is a matter of clicking the "Play" button on the macro.
One problem with packing the alpha channel is that it is premultiplied into the composite, which burns it into the R, G and B channels. Not good for channel packing.
Kirk
-
kirkt reacted to kirk23 in Pasting Images Into Alpha Channel
Yeah, I forgot to mention it but there is a simple workaround. You can add a super transparent "fill" layer in the Alpha group of the example I posted . Only perfectly zero alpha pixels are multiplying over other channels . If you make it like 0.0001 alpha value in procedural filter APhoto will not multiply it over and it will still be zero alpha in exported 8 bit tga since 0.0001 is beyond 255 shades of gray in 8 bit image.
channel packing.afphoto
-
-
kirkt reacted to Nita Reed in Affinity Photo - Resolution
Wow...that was AWESOME! What a great solution...
THANK YOU!
-
kirkt got a reaction from user_0815 in Soft Proofing does not work in the manner it would be helpful (Affinity Photo)
RGB and CMYK are "color models" - how color is represented. sRGB, AdobeRGB, ISO, SWOP etc. are color spaces within their respective color models - think gamut volume as the space in which a color in a particular model (RGB) can live for that particular space (sRGB). A color profile is a file on a computer that defines the color space (its "tristimulus values" for R, G and B) and its white/black point, among other characteristics.
On a Mac, you can use the ColorSync utility to view the contents of your color profiles (screenshot).
kirk
-
kirkt reacted to Granddaddy in How do I extend a background in Affinity Photo?
Two days ago, BRG Photography posted a new tutorial on extending even complex backgrounds at
https://www.youtube.com/watch?v=CtLpGfX_Iss
-
kirkt got a reaction from NotMyFault in Soft Proofing does not work in the manner it would be helpful (Affinity Photo)
Color Think will provide an accurate color preview on the display for the various rendering intents and will provide the corresponding change in the ∆E false color map (see screenshots for differences based on specified rendering intent), as well as permitting the user to sample from the image to see the specific ∆E value for that pixel.
As far as quick or easy, one still has to verify that the soft-proof is useful by comparing it to a print under specified lighting. Trying to control gamut between the source and destination color spaces does not require a print, by verifying that any adjustment one makes to the file to produce the desired printed appearance will require an accurate soft proof, otherwise one would inspect the print and make changes based on it. I do not come from a CMYK workflow, so please take my comments with whatever grain of salt might apply specifically to a CMYK production workflow.
I suppose that differences between a conversion into the CMYK profile and a soft-proof of that profile may be related to some soft-proof simulation parameter (like simulating paper white, or whatever) that is not exposed to the user.
kirk
-
kirkt reacted to NotMyFault in Soft Proofing does not work in the manner it would be helpful (Affinity Photo)
It would be totally easy to provide this false color overlay if Affinity would provide an RGB2LAB conversion function for procedural texture filter.
Or even better, a deltaE function
Or even better, a delta E false color overlay for soft proof. The math is totally simple, could be done in PT filter.
http://colormine.org/delta-e-calculator
A non-live workflow:
Add soft-proof (check gamut off) merge visible delete soft proof convert to lab color mode move original layer on top set blend mode of upper layer to Substrat (difference not working in LAB) add black & white adjustment add gradient map to create false color
delta E mockup.afphoto
-
-
kirkt got a reaction from NotMyFault in Soft Proofing does not work in the manner it would be helpful (Affinity Photo)
Here is a visualization of your above image with sRGB as the source and SWOP2006 CMYK as the destination, with the ∆E values plotted in a false color image and some of those RGB patches sampled for their ∆E (in the list). Changing the rendering intent will change the ∆E across the image, so you need to investigate how rendering intent affects your final printed output compared to the soft-proof. As you can see, the deep purples in the image are particularly out of gamut and may present a problem with printing, especially with a relative colorimetric rendering intent (where OOG gamut colors get clipped to the destination gamut boundary) - you may need to adjust those colors locally or come up with a way to preserve them as well as possible prior to printing if they are important to the final image. You can do this local adjustment with soft-proofing turned ON so that you can see the simulated result while you make adjustments.
A tool like this is more helpful than just a gray overlay because it gives you an idea of how far OOG a color is in the destination space so that you can devise a specific strategy to target the worst offenders and leave the less intrusive problems alone, within acceptable error.
kirk
-
kirkt reacted to Domus in Olympus ORF RAW files cropped?
You mean "Default lens profile"? In any case, tried that and it works perfectly.
Thanks!
Dom
-
kirkt got a reaction from Tom Lachecki in Olympus ORF RAW files cropped?
In the Develop Assistant there is a lens correction default drop-down option - set it to none, instead of auto.
Kirk
-
kirkt got a reaction from Domus in Olympus ORF RAW files cropped?
In the Develop Assistant there is a lens correction default drop-down option - set it to none, instead of auto.
Kirk
-
kirkt got a reaction from ambersand in How to Edit the Alpha Channel
Let's say your images that you want to pack exist as separate grayscale images (in this example, let's assume you have an AO pass, a ROUGH pass and a METAL pass that exist as grayscale images - pretty typical for a CG render workflow). You can use the Apply Image operation to pack the ROUGH and METAL grayscale images into the G and B channels of an existing basis document that you make from your grayscale AO grayscale image, as you described in a previous quoted post.
1) Open the grayscale AO pass in AP and convert it to an RGB8 image, so it supports R, G and B channels. This will be the new WORKING DOCUMENT for your channel packing exercise.
2) Use Filters > Apply Image and select "Load Source From File ..." and select the ROUGH grayscale image.
3) in the Apply Image dialog, check the "Equations" box and enter the following equations:
DR = DR
DG = SG
DB = DB
DA = DA
where "D" denotes the Destination of the operation, and "S" represents the Source of the operation. In this case, this will place the GREEN channel from the ROUGH image (the "Source" or S in the Equations) in the Destination Green (the DG) and leave the rest of the channels in the Destination document as they were originally.
4) Do the same as Step 3, only use the METAL image as the Source and enter:
DR = DR
DG = DG
DB = SB
DA = DA
This places the METAL image's blue channel into the blue channel of the destination working document.
5) Save As (for an .aphoto doc) or Export (for a JPEG, TIFF, etc) the resulting file and your are done.
It does not require 30 steps and is pretty straightforward. You do not even need to open the other files (ROUGH and METAL) explicitly into AP' interface to select them and incorporate them into the G and B channels of the AO doc to pack them. QED.
You could avoid having to open the ROUGH and METAL documents explicitly in PS to to pack them into the AO-based RGB doc's G and B channels by using .... you guessed it - Apply Image! Same operation as described above for AP, same amount of steps. Sometimes you have to change your routine slightly to adapt your longstanding workflow to new tools.
Have fun!
Kirk
-
kirkt reacted to user_0815 in Adjusting the saturation of shadows and highlights independently
I wonder why nobody mentioned blend-ranges (the little gear/cog). That's what I usually use, as I find it the easiest way.
1. Add any adjustment layer
2. Limit to highlights/midtones/shadows as needed.
-
kirkt got a reaction from AQP in RAW Workflow
Unlike many raw converters, AP has no facility for recording the settings you dial in during raw conversion (like a sidecar file, database, or embedded DNG metadata). If you do a raw conversion into the Photo persona and simply close the resulting file, when you open the raw file again, you start over.
Similarly, AP has no analog to a Smart Object in PS. So, once you perform your raw conversion into an RGB file, you cannot reopen it into the Develop persona as the original raw file; you can, however, open the converted RGB file in the Develop persona and edit it there, if the tools there are better for whatever it is you are trying to accomplish. This is analogous to editing an RGB file in PS using the Camera Raw filter.
Because almost everything you might want to do to an RGB file in AP is non-destructive (adjustment layers, live filter layers) you can send a TIFF from DxO to AP and do non-destructive edits to it. If you realize that you need to make changes to the original raw file in DxO, your changes in DxO are preserved by DxO, so it is just a matter of reopening the raw file in DxO, editing there and then exporting the new TIFF to AP. Then swap that new TIFF into the file with all of your edits in layers above the original TIFF image. If they are all non-destructive edits, they will all just modify the new edit and you can adjust them for the new edit image.
kirk
-
-
kirkt got a reaction from Mike_A in Color Sampler in 32-bit image
Here are a couple of kludges that will maybe help a little.
1) The color picker goes into bounded (0.0 - 1.0) readout when picking a color in a 32bit file. This will give you a relative sense of the numerical floating point values in your image.
2) In a Curves adjustment layer, you can specify the min and max X axis values for the curve. So, you can set the min to 0 and the max to 100, for example. Then you can use the picker in the curves dialog and see where your picked point in your image falls on the X axis of the curve. The X axis value is still readout in 0 to 1, but you just need to scale it by the max value you input. Unfortunately, it appears that the maximum "max" value you can enter is 100, which might cause a lot of shadow values to accumulate way down on the left end of the curves histogram.
I agree, adding a true 32bpc color readout is a no-brainer.
kirk
-
kirkt reacted to Dan C in Tamron 17-70 f2.8 E Mount Lens Profile
The good news is that these betas have been released as retail versions today, meaning they will be able to download and install 1.10
-
kirkt got a reaction from Dan C in Tamron 17-70 f2.8 E Mount Lens Profile
@Rajagop - You can also try using the newest beta release of AP, which supports Adobe Camera Raw lens profiles. I think the beta is only available for customers who have a paid and installed version of AP on their machine, so this might be a little tricky - perhaps a moderator, like @Dan C could chime in here on how to get you a test copy, if that is possible?
Here is a link to the latest beta:
WIN:
MAC:
So you can read about the changes, features and improvements from the previous releases. I have tested the use of ACR lens profiles in the beta and I can say that, for the profiles I tested, it worked.
Both of the above-referenced lenses appear to be supported in the Sony E mount, and the .lcp files are present in the latest version of Lightroom/ACR. I have attached the .lcp files here for download.
To make these profiles available for AP, you will need to copy them to the correct directory on your machine, just like a custom LensFun XML file. To make this process easier, the Preferences > General tab in AP has a button on it that will open the lens profile directory for AP in your OS - then you simply copy the Adobe .lcp files there and restart AP. If all is working properly, when you enable lens profile corrections, AP should automatically choose the correct profile (based on the raw file's metadata).
Have fun!
Kirk
SONY (SIGMA 56mm F1.4 DC DN C018) - RAW.lcp SONY (TAMRON 17-70mm F2.8 Di III-A VC RXD B070) - RAW.lcp