AP-

That's what I initially thought, but upon consideration, the luminosity mask is just another way to manipulate the same data, hence the question. It's a bit like which part of the curve one would be editing, so should in theory be possible to map. Also, the fact that the .look extension specifies LUT only implies the other two formats are able to export other things. I was sort of thinking, what, though?

Yieesss. I do have a question though. Does the Export LUT only export the bare adjustment translations or does it include say, a live mask applied to the adjustment layer? I'm thinking a use case here of targeting specific luminosity ranges with the luminosity mask.

This bug is still present in 2.5.5 on Sequoia 15.0.1. How to reproduce: 1. Open 8-bit JPEG (or develop a 16-bit image from RAW). 2. HSL adjustment layer, curve adjustment layer and selective colour adjustment layer. 3. Export LUT. 4. Import the saved LUT and click the panel button or create a LUT layer and load the file. It does not apply. An interesting behaviour noted: It works fine if you add a white balance adjustment. The fix for me is to add a 1% white balance adjustment with 1% change in both sliders. Another interesting fact: Delete all the adjustment layers. Repeat steps 1-4 above. The exported LUT is the last one saved with a white balance adjustment layer rather than the current one you try to save.

Commiserations. So at one point I had both Affinity Publisher 2.5.5 running and exporting a 100-page 300dpi chunk and Affinity Publisher Beta 2.6.0 trying to complete the whole 409-page document at 300dpi. Started both at the same time. 2.5.5 finished the 100 pages and as expected 2.6.0 froze and crashed. IF physical memory had been an issue (rather than say, a memory leak), neither would have completed, because by the end of it, they were both taking up the same amount of memory in Activity Monitor, ie about 21GB each, except one was dead. Note I only have 16GB physical memory, and about 28GB was being swapped. I now have about 4 PDFs 2.5GB each I need to merge. I remember when you couldn't physically get a file bigger than 4GB on a filesystem. :') Or a filesystem that was bigger than 360KB...

I got round it by time-consuming trial and error. It does not make sense that exporting takes 20-45GB. It's rendering spread by spread, rather than the whole document in one go, as there is no one object or layer that spans the whole document. I essentially only do 100 pages at a time. I have to restart Publisher in between or it crashes on the second or third run of 100 pages having run out of memory again, having peaked at either 22 or 46GB depending on where you look. This implies it is not releasing the memory that is no longer being used. Therefore a bug or a memory leak, otherwise, it would still crash after restart. Exporting 100 pages to PDF at 300dpi took 4 hours.

On second thoughts, this may be a second bug, because there is no pressure curve. Mine seems to imply a memory leak. Similarities, freezes at 50% and has to be killed. Let me know if you would like me to add a new bug report.

Hello. I am afraid I have the same issue with Macos 14.5 and Affinity Publisher 2.5.5 (really love using it by the way). I am on a Mac Mini 2 Pro with 16GB RAM. I am essentially trying to export a 409-page document of A4 pages containing linked around 600 linked PNGs about 120-140MB each. Initially I tried to export the whole lot at 300dpi, and it crashed (froze) at around halfway, with Macos's popup requesting to kill unused apps coming up. It reported Publisher was using 45GB RAM (whilst Activity monitor reports about 21-22GB, and btop 1.8-2GB). It's basically unresponsive at that point and has to be killed. I tried to export at 72dpi, and the same thing happened. I then tried to export the same file in chunks of 100 pages, this initially seemed to work, then today, froze again with the same symptoms. When I checked Activity Monitor, it appears Publisher is still using the 21-22GB even after an export, then runs out of memory on the subsequent run. I'm not sure how it manages memory/caches, but I'm wondering if there is a memory leak somewhere. Steps to reproduce: Create a 600dpi A4 portrait file of ~400 pages. Link ~600 PNGs of about 140MB each. Occasionally apply a curve ± mask (including live mask). Occasionally apply a white balance. Occasionally apply a vector mask to the image (rectangular). Very occasionally have a bitmap mask. Export, use preset for print or screen. Do a second run if it does not freeze, it will freeze on subsequent run.

Hello. The file is the PNG already included in the original post.

Thank you. Yes I used imagemagick test2.png test2.heic Original PNG is 16-bit. This produces a 16-bit heic by default with -quality of 50%. This displays correctly on Apple Quicklook. I use feh (command line image viewer using libheic) and that displays correctly. Loads correctly in GIMP. Thumbnail has some green banding. Photoshop also does not recognise the file. I am raising it here rather than an encoding issue because Affinity is clearly doing something with the file but consistently loads it overexposed. If I use imagemagick with -depth 10 it Affinity displays it correctly. However top bar and document ICC dialog still list the file as 32-bit.

Steps to reproduce: convert a 16-bit png into a 16-bit heic file. Load. in Affinity Photo. Displays as 32bit HDR and it looks like exposure is way off. See screenshot. Sample files are attached. Heic file displays correctly in other software. Running identify -verbose from imagemagick on the heic gives: Image: Filename: test2.heic Permissions: rw-r--r-- Format: HEIC (High Efficiency Image Format) Mime type: image/heic Class: DirectClass Geometry: 1562x1043+0+0 Units: Undefined Colorspace: sRGB Type: TrueColor Base type: Undefined Endianness: Undefined Depth: 12/16-bit Channels: 3.0 Channel depth: Red: 16-bit Green: 16-bit Blue: 16-bit Channel statistics: Pixels: 1629166 Red: min: 32.9924 (0.00805676) max: 4051.07 (0.989273) mean: 2050.5 (0.500733) median: 2217.49 (0.541512) standard deviation: 645.409 (0.157609) kurtosis: -0.38828 skewness: -0.46645 entropy: 0.946007 Green: min: 0 (0) max: 3660.16 (0.893812) mean: 1179.04 (0.287921) median: 967.778 (0.236332) standard deviation: 659.781 (0.161119) kurtosis: 1.18976 skewness: 1.33596 entropy: 0.925736 Blue: min: 0 (0) max: 3585.18 (0.875502) mean: 1104.29 (0.269669) median: 876.799 (0.214115) standard deviation: 640.701 (0.156459) kurtosis: 1.62078 skewness: 1.48041 entropy: 0.919812 Image statistics: Overall: min: 0 (0) max: 4051.07 (0.989273) mean: 1444.61 (0.352774) median: 1354.02 (0.330653) standard deviation: 648.63 (0.158396) kurtosis: 0.807421 skewness: 0.783307 entropy: 0.930519 Rendering intent: Perceptual Gamma: 0.454545 Chromaticity: red primary: (0.64,0.33,0.03) green primary: (0.3,0.6,0.1) blue primary: (0.15,0.06,0.79) white point: (0.3127,0.329,0.3583) Matte color: grey74 Background color: white Border color: srgb(223,223,223) Transparent color: black Interlace: None Intensity: Undefined Compose: Over Page geometry: 1562x1043+0+0 Dispose: Undefined Iterations: 0 Compression: Undefined Orientation: TopLeft Profiles: Profile-icc: 596 bytes Profile-xmp: 4514 bytes Properties: date:create: 2024-09-26T20:32:48+00:00 date:modify: 2024-09-26T20:31:22+00:00 date:timestamp: 2024-09-26T20:35:46+00:00 icc:copyright: No copyright, use freely icc:description: sRGB IEC61966-2.1 signature: bc4dcc6ea9ea52559fe41c5b8bcf5b384513e4efb1b28a7dee443744bce82a87 Artifacts: verbose: true Tainted: False Filesize: 135275B Number pixels: 1.62917M Pixel cache type: Memory Pixels per second: 18.5182MP User time: 0.090u Elapsed time: 0:01.087 Version: ImageMagick 7.1.1-36 Q16-HDRI aarch64 22352 https://imagemagick.org test2.heic

Still there in 2.4.0 beta 2294.

@Serif Info Bot Can confirm. Regression is only in the Luminosity live mask, and only in blur radius. The original bug also affected opacity and the other masks. Have just tried with the three different live masks of 2.4.0.2279.

Thank you! Since you're going to be looking at the Levels code... could I suggest a feature request? Say, something like pressing ALT+2/3/4 to automatically select the channel rather than going into the dropdown?

I remember seeing reported somewhere with a partial fix, but cannot find it now, so not sure if it was reported as a bug or discussed as an issue on the forum, but reporting (again?), as still present in production and beta: Expected behaviour: When adjusting levels sliders in individual RGB or CMYK channels, holding ALT while dragging should show clipping. What actually happens: No clipping is displayed. This works fine in Master. Partial fix: In Master, set black level to non-zero value, 0.001 works. Set white level to 99.999%. Go into any channel now: slide white level or black level sliders while holding ALT. Clipping is now displayed as expected.

Thank you. I wonder if the same mechanism affects the other live masks!