James Ritson

It could be the live High Pass filter: spatial filters may appear to render differently when merging/flattening if you are previewing at a zoom level below 100%. Ignoring the histogram changing, if you zoom to 100% (CMD+1 / Ctrl+1) before merging, is there any visible difference? What's going on in those groups with masks, do you have more live filters in them? As for Merge Down, you can only use it if the layer below your current layer is a mutable Pixel layer. Image layers (placed images) and RAW layers are considered immutable, and you have to explicitly rasterise them if you wish to merge layer content into them. You'll find the same with vector content such as Curve layers and shapes: the user is prevented from merging content down into them as this would have to rasterise the vector data. Hope that helps!

Hi @ProHolmes, yes, RGB/16 in the Affinity apps uses an actual 16-bit register, so 65,536 unique values for each colour channel. RGB/32 is also supported if you need linear floating point compositing as well. Hope that helps!

The above video seems to be taking the high pass result from Frequency Separation and compositing it, discarding the low pass. You can achieve the same result more effectively by using a live High Pass filter and experimenting with a Soft Light blend mode to eliminate the halos (rather than painstakingly masking them out). Furthermore, you can stack multiple High Pass filters and vary the Radius value each time for multi-bandpass sharpening. Best of all, it's non-destructive. The High Pass tutorial goes over this technique:

@lord darkul just to check, by 5830 are you referring to a CSL Sprint 5830 which comes with a Ryzen 7 CPU and integrated graphics? If so, do you know the model of the integrated graphics? Do you have a discrete GPU in addition?

Hi @Grimmjow80, the calibration frames you've supplied are 2x2 pixel binned. Granted, the astrophotography stacking process could stand to provide a bit more feedback here, but that's why the frames are failing to render when you add light frames: the light frames are full resolution (3056x3056), the dark frames are pixel binned (1528x1528). You would need calibration frames matching the resolution of the light frames. That said, you shouldn't be using any calibration frames with that data anyway. Although you can explicitly download the raw data if you really want to, the files you're using are appended with "_cal", which means they have been pre-calibrated during the capturing process. Just add the light frames and click Stack: any outlier pixels not accounted for by the calibration should be rejected as a result of the sigma clipping process. Hope that helps!

You're using an Unmanaged (linear light) view, ICC Display Transform is what you want to be using in order for the export to a gamma-encoded format to match the document view. This does complicate the process of trying to work with OCIO, however. When OpenColorIO was implemented, its intended use was only for non-destructive colour management where Photo would be utilised for retouching of linear EXR/HDR files, before then being exported back to that same format for compositing in other software. The OCIO adjustment was introduced so you could composite multiple sources with varied colour spaces into one document. It seems there's a bigger demand for working with an OCIO view and then exporting the OCIO-encoded results to a gamma-encoded format for final output. One thing that was suggested a while back was having the option of writing an unmanaged bitmap if the OCIO view transform is in use—so similar to blender (and I expect other software) where the OCIO transforms are written into the colour values and the resulting image is untagged (assumed sRGB in most cases). I'll bring it up again with the Photo team.

@cgidesign Since the integration of OCIO v2, Photo has made use of the File Rules section to determine input colour spaces: https://opencolorio.readthedocs.io/en/main/guides/authoring/rules.html The ACES configuration files only appear to have one file rule: file_rules: - !<Rule> {name: Default, colorspace: ACES2065-1} So upon import of the EXR document, Photo will be converting from ACES2065-1 to scene linear—which for your files would be incorrect if the primaries are in linear Rec.709. There are two ways to solve this problem: Modify the existing file rule or add a new one: file_rules: - !<Rule> {name: Rec709, extension: "exr", pattern: "*rec709*", colorspace: Linear Rec.709 (sRGB)} - !<Rule> {name: Default, colorspace: ACES2065-1} If using an additional file rule like above, make sure your EXRs contain "rec709" somewhere in the filename. You should then see a toast at the top right when importing an EXR to say Photo has "converted from Linear Rec.709 (sRGB) to scene linear". If not, go to Edit>Settings>Colour and ensure "Perform OCIO conversions based on file name" is enabled (disable and re-enable just to be sure). Without modifying the OCIO configuration file, use an OCIO adjustment layer to go from Linear Rec.709 (sRGB) to ACES2065-1: One final thing: I notice you're using Elle Stone's sRGB profile, which you've presumably set in Settings>Colour>32bit RGB Colour Profile? This is fine, since this simply assigns that colour profile when using the ICC display transform view mode and bounds the on-screen colour values, but do be careful of using Document>Convert Format / ICC Profile since this will physically change the colour values in the document. You'll want to avoid this when working in scene linear and using OCIO: use OCIO adjustment layers for explicit transforms between colour spaces instead. Hope the above is helpful!

@cgidesign try v2.2 rather than v2.3—v2.3 requires a newer version of OCIO integration that Photo doesn't have yet, apologies. Notice that v2.1 and v2.2 reference v2.0.0 in the filename, whereas v2.3 references v2.1.0.

Hi @Albert Lazzarini, are you using calibration frames, particularly dark frames to remove hot/stuck pixels? The stacking can be confused and sometimes try to align on these instead of genuine star detail. Ideally, a master dark frame should be built (this happens automatically when you supply dark frames) and subtracted from each light frame so alignment on the star detail can be achieved. It would be worth asking if you can either supply the original files or post a quick preview image of one of the light frames so we can see what the issue might be. Thanks

Hey @Zero_0, try setting the output option to New layer or New layer with mask. These options will perform colour decontamination, which is what you will be seeing whilst in Selection Refinement. When using the Selection or Mask output options, these do not modify the pixel data directly and so cannot perform decontamination. Hope that helps!

Hi @bgreenstone, Photo isn't edge-aware when it comes to things like convolution filters I'm afraid. What are you wanting to do with the 360 images? Tone mapping, sharpening, clarity/structure enhancement? There are tone mapping methods available that won't result in visible seams. You can also use sharpening techniques such as bandpass sharpening (multiple live High Pass filters with a Soft Light blend mode) to avoid obvious seam issues as well. I do have some "seam aware" 360 macros from a while back that allow you to perform local contrast enhancement, clarity and tone mapping—I'll see if I can dig them out...

Yes, that looks about right: all cores on the CPU are maxed out. Live Clarity is being composited on CPU within Designer, along with all the other operations, so things will be slower—especially zoomed in. If you zoom out, performance may improve slightly. It's not a bug (GPU raster compositing is just significantly faster for most modern hardware setups), but it may raise the question of whether Designer would benefit from GPU acceleration for more than just brush work. Because live filters aren't exposed in Designer, it's possible most users won't be using this type of workflow—or those that do will typically be performing their vector work in Designer, then applying live filters in Photo to finish...

You're using Designer it looks like—have you tried this document in Photo to see if it's any faster? Unless something has changed, Metal Compute is only used for brush work in Designer, and live Clarity is quite expensive to render even on GPU, so it will be even slower on CPU. If it's still that slow in Photo, that may be cause for concern. I wouldn't expect it to be rapid as you're mixing raster and vector, but it should be faster than Designer...

Hi @Lamont1, Firstly, any bespoke profile created with profiling software should only be used at the OS level. Using this bespoke profile as your document profile will effectively negate any colour management, and could cause inaccuracies for non-colour-managed software. For your document profile, stay in sRGB or whichever profile you are using. Presumably you will be editing your images into a video format using editing software, in which case this should be doing the colour management between your image's colour space (e.g. sRGB, Adobe RGB) and your video colour space (Rec.709, Rec.2020 etc). Any differences converting from sRGB to Rec.709 should be negligible. In summary, if you are working in a colour space wider than sRGB, you may want to try converting to sRGB during export (or use Document>Flatten and convert manually). It will somewhat depend on the editor you're using, and how they have implemented colour management.

Hey @Morten Lerager, you can indeed import FIT files into Affinity Photo and it will open them in a linear 32-bit pixel format. The data and compositing is actually linear, but there are a couple of things to note: A gamma-corrected view transform is applied (but only to the view, not the actual document pixel values) so that the result on-screen looks consistent with a final export to a gamma-encoded format such as JPEG. Levels and Curves adjustment layers are added by default for basic tone stretching. You can hide or delete these. To go back to a linear format, Photo does offer the ability to save as a 32-bit TIFF. Alternatively, you can use JPEG-XL, OpenEXR or Radiance HDR (not sure if PixInsight supports these). I'm not sure how inserting Affinity Photo into a PixInsight workflow pre-tone-stretch would be beneficial though—wouldn't you just tone stretch in PixInsight then export to Photo for further editing? It may be worth pointing out that you can achieve all manner of tone stretching methods in Photo, they're just not readily available as easy filters that you can apply. Some of them (e.g. colour preserving tone stretch, similar to Arcsinh) are implemented via macros which you can download. Hope the above helps!