James Ritson

Update 23/01/23: Exporting (iPad)

Hi Kulh, as DM1 mentioned above this is not a loss of resolution—you will find that most RAW files contain a handful of pixels around the edges, but these are cropped away as per the mandated resolution in the metadata. Photo ignores this, however, and always processes the full width and height of the image, which is why you end up with a marginally higher resolution than you would expect. The aspect ratio is still 3:2. A good example of this is the Olympus cameras: e.g. the E-M1 mk3's actual RAW resolution is 5240x3912, but the metadata instructs software to crop it to 5184x3888. It doesn't sound like much, but the extra resolution is actually quite welcome when dealing with wider angle lenses. If Photo applies automatic lens corrections, you can actually go into the Lens tab and bring Scale down—you'll often find there is pixel data being pushed outside of the crop bounds that you can bring back, and this is made partially possible by Photo not cropping those edge pixels. Hope that helps!

Update 16/01/23: Command Controller (iPad)

Update 16/01/23: Linked Text Frames (iPad)

And one more, again for architects: Archviz Composition Workflow.

I've added Elevation Rendering Workflow to the list—this one focuses on a particular architecture workflow but may be useful for anyone wanting to see more examples of the flood select tool, masking and cloning layers...

Another one for iPad (from Katy, our iPad product expert): Pencil Tool

Happy New Year all! I've just made a quick update to the Command Controller iPad video—it now reflects the change made in 2.0.3 where the toggle has been moved to the Document menu.

Hope everyone had a lovely Christmas! I wanted to sneak in another video before the new year, so here you go: High Dynamic Range Workflows HDR/EDR technology has actually been present in Affinity Photo for a few years now (since around 1.7 I believe), but with V2 introducing JPEG-XL export I thought it was about time to do a proper video on high dynamic range editing. This video was shot in HDR and mastered to 1600 nits of peak brightness, so if you have a display capable of that brightness (for example, the M1 Pro/Max MacBook displays), you're in for a visual treat! For those viewing on SDR displays, the content will be tone mapped and will of course lose a bit of its impact...

The picture going black will be because: Your original EXR document contains pixel values greater than 1 Unless you merge down the Exposure adjustment before converting to RGB/16 or RGB/8, you will then lose (clip) those >1 values This is because the Exposure adjustment is then being applied to the bounded range of pixel values, so it is taking the maximum value (255 in 8-bit, 65535 in 16-bit) and reducing it down to 0. The solution is either to merge the Exposure adjustment before converting, or to simply stay in RGB/32 and use a tone mapping method after the Exposure adjustment (e.g. procedural texture, or Levels adjustment followed by other adjustments). Hope that helps!

19/12/22: Added Vibrance Adjustment

Hi @Gary.JONES, the procedure for selecting the best light frames is based on the quality of the 40 best stars found in each sub, where a good star is bright relative to the noise level, round, sufficient size (but not too big) with peaks in the middle. The help documentation may need updating as I don't believe that information is completely accurate...

Hey Claude, This could actually be by design—I haven't used DAZ, but could relate using blender. There's more of a focus on physically correct lighting nowadays, and many of blender's environment/sky lighting plugins (such as True Sky, Physical Starlight and Atmosphere etc) will use incredibly bright values that then require the Exposure to be reduced significantly, usually by 3 to 6 stops. This is fine when you are writing out gamma-corrected bitmap files such as TIFF and JPEG, but when saving to EXR this tone mapping isn't applied to the pixel values—instead, you're getting the unmodified pixel values in linear gamma. This is by design, as software shouldn't really be writing any kind of gamma encoded values to EXR. If you colour pick one of the white values when you first import your EXR, I imagine the value would be greater than 1. What are your tone mapping/view settings in DAZ? It may be you're using some kind of lighting that requires the Exposure value to be reduced, and you would then have to match that in Affinity Photo with an Exposure adjustment layer. Your solution is sound in practice, but I would be wary of clipped or 'harsh' highlight details because you may also need to apply some kind of tone mapping to give highlights a roll-off effect. This should be done in 32-bit before merging/flattening and converting to 16-bit or 8-bit, which are bounded gamma corrected formats. This video might be of help: Hope the above helps!

Update 15/12/22: Packaging (iPad)

15/12/22: Added Batch Processing