KLE-France

Today I learned TWO things! Thanks @Alfred and @Old Bruce for the example.

This is why I greatly appreciate this forum: that is exactly it, walt.farrell; there was a teeny-tiny selection still active from a corner repair I had done when originally working on the file some months back. So mark this one as resolved! Thanks again to all, and I hope this thread will be useful for the next person who runs into the "(not so) mystery mask" problem.

Whooo! Now we're getting somewhere! So, after NotMyFault's suggestion, I opened the document, immediately pressed Ctrl+D, and the problem went away. Then I came back here to respond. I just went back to my AP, realized that I hadn't saved anything, so I reclosed the file without saving the change, and reopened it. Problem reappeared (but see further on)! Ctrl+D: problem went away! Thank you all so much! However, that does leave the question of why the mask is non-responsive (painting white on it did nothing (or black after inverting it)) in this case... Again, thanks to all; Today I learned.

Hi NathanC and thanks for this offer. Do see my response NotMyFault. The problem is gone now, but I don't know if it's because there was a selection active (which means an active selection can be saved and not have a marquee around it when it's reopened) or because AP was just doing something weird with that particular file that particular day.

Thank you NotMyFault for this suggestion. A question: Can a document be closed and maintain a selection? So that when the document is re-opened, the selection would still be active? Yesterday, the file went through several rounds of opening and closing, and the problem did not disappear, and especially it was present right after opening the file, with no other actions taken. There was never a marquee visible, and it's important to keep in mind that the mask was non-responsive (painting white on it did nothing). ...But... I just reopened the file to test your hypothesis, I did hit Ctrl+D, and the problem is gone. So, were you right--and if so thanks!--or was it Affinity Photo itself that was bonking just on that particular file on that particular day? 🤔

I am more so curious if I infinite-monkeyed some obscure setting, but that doesn't really make any sense. So, yes, I assume that the file is just boinked somehow. If there is a company programmer/developer who would like to examine the file, let me know, but a can't see how the closed-sourced-software file will be of any use for us mere mortals.

HI, all, Got a weird issue. I have an .afphoto file from a few months back that I reopened today. When I add a new adjustment layer (any type), it opens with a black mask on it (the adjustment layer appears with the black mask icon already there). Thus, any adjustment done does not show, and moreover, the mask is unresponsive, that is, painting white on it does nothing; the mask remains black. A click right > Clear mask or Fill mask does nothing. A click right > Invert mask does invert it, but it remains unresponsive to the paint brush... Sometimes (seemingly randomly), inverting the mask will also make it go away after some amount of time, but that's the exception, not the rule. I have tried closing and re-opening the file, closing and re-starting AP, and restarting the computer (Windows 10 if that might matter) all to no avail. This issue, as far as I've tested, is unique to this one .afphoto file, which is nothing in particular: developed from a .NEF file, no exotic things going on with it, etc. Of note perhaps: if I reopen the .NEF file and develop it to the Photo Persona, I can add layers perfectly normally. Any ideas?

Thanks Not My Fault, but I'm aware that there are workarounds. From my original post: From the lack of other responses, I assume that I am correct that one cannot trim without rasterizing. That makes sense, I admit, with raws, where the idea of trimming raw data is a paradox. I do find it odd though that there is no choice of just "trim" alone for jpegs and tifs and the such, as they are already rasterized, but that's maybe just a case of why program twice when once will suffice. Anyhoo, thanks again.

Hi all ; hope everyone's well. Just a quick question: in Affinity Photo, is there no way to trim an image without rasterizing it? The use case here is developing an image from a raw that has been cropped, then once in the Photo Persona, adding a border to the image by expanding the canvas. This is something I do when printing: the image is sized to what it's going to be in the frame, and a border is added to bring the photo paper size up to that of the frame (hidden by the mat). The problem I describe below remains when working on a cropped jpeg as well. When you try to expand the canvas on a cropped image, the canvas expands from the original image and thus doesn't fit to the cropped image. I've tried merging everything to a new layer and cropping that, but that doesn't work; resizing the canvas remains based on the original image's dimensions. As far as I can tell, the original image has to be trimmed—and thus rasterized—to make the canvas expand from the cropped image. The idea behind not rasterizing the image while trimming it is to be able to go back to the (remaining) raw data to refine aspects for the print. I know there are workarounds with shapes and the such, but I'm really curious if trimming is possible without rasterization. Thanks in advance to all!

Woah! Weird! Confirmed in Windows 10! I thought for a moment that maybe AP is writing the white balance into the raw file, but when I re-open this latter directly, it does still have the camera's white balance. So it's not that... I think. Very strange indeed!

Affinity Photo / version 2.6.0 / Reproducible / Windows 10 Home / hardware acceleration: Off / No unusual hardware / recently discovered; do not know if it happened in the past. Summary: Any white balance adjustment done in the Develop Persona is lost when reconnecting a moved raw image file to its .afphoto file. Recipe: Adjust a raw image in the Develop Persona, including a change to the white balance Develop the image to the Photo Persona, using "Output: Raw Layer (Linked)" Save the .afphoto file then close it. In Window Explorer (or other program), navigate to where the raw file is located and move it elsewhere. Re-open the .afphoto file: this evokes the "Missing Resource(s)" dialog Click "Yes" (or "Resource Manager", but the following uses 'Yes') Navigate to where the raw file was moved to, select it and click "Open"; AP reconnects the .afphoto and raw files ⇒ The image will show all of the adjustments done in the Develop Persona, except for white balance Return to the Develop Persona to verify: On the Basic tab, "White Balance" will be unchecked, and when reopened it will have the original, camera's white balance, not the white balance done at Step 1 Thanks and happy bug hunting!

A "+1" on my part and Pšenda's link is so telling for this request; so many times. So many times. A read recently elsewhere a commenter (I've forgotten who and where; sorry) who hypothesized that Affinity seems to favor adding new features, that can be promoted and thus serve to sell the software, rather than fix major bugs (I'm looking at you Photo Persona > White Balance Adjustment > Picker -- that STILL DOESN'T CORRECT TINT) and annoyances. But this one especially could be promoted as a new feature: "With a click of a button, Affinity programs now let you tile or cascade all, or just a selection, of open documents; or repeat one document in several views!" Yeah, me too. It just seems so odd that I can do this in every program on my computer. Except Affinity. Don't get me wrong; I love Affinity Photo, but, yeah, this too is on my "little things" list; not deal breakers, but very annoying just the same.

HI Ldina, HI fde101, I surely worded my first sentence badly. Yes, provoking the rasterization of the raw layer (my "v8") by definition turns that information into "real" 16-bit pixels and thus rockets the weight of the afphoto file. So, I was trying to see if there were other things able to cause the file weight to increase significantly, and indeed it seems as if something needs to be rasterized before the afphoto file starts to show signs of eating too much ice cream. Now no longer at work (we'll keep that between us), I just tested the masking thing, and indeed that too will make the afphoto file take off (852 kb for the "v1" approach vs. 6.32 mb for v1 + a masked curves layer). In the context of this thread, all of the above contributes a bit to the reality of the fact that the afphoto file is really something very different from the sidecar files you get with dedicated raw developers, which stay relatively light no matter what. And yet, in many dedicated raw developers you can at least mask, and I think in some you can clone (???), so how do they go about doing such a thing without making the sidecar file grow exponentially? And note I'm speaking of sidecar files, not XMP files, which, as fde101 has demonstrated, is a whole nother thing. So, I'll quote myself: Re-cheers to all. EDIT: Oh! And by the way, the difference in file weight between "v8" and "v9" above was my error. I hadn't noticed that ZIP compression was activated for the tif file. Uncompressed, an exported tif weighs as much as a rasterized afphoto file.

This does assume that no action is taken which causes the resulting RAW layer to be rasterized. Your comment there intrigued me, fde101, as I've never thought that through. So I decided to do a quick test: v1 = develop a raw, export to Photo Persona (Output: Raw Layer (linked)) then File > Save as... to save v1 version (so no action taken): 819 kb (.afphoto file size) v2 = add a curves layer and save v2 version: 822 kb v3 = modify curves layer and save v3 version: 825 kb v4 = add additional HSL layer and save v4 version: 825 kb v5 = modify HSL layer and save v5 version: 827 kb v6 = add pixel layer and save v6 version: 827 kb v7 = modify pixel layer (paint on it) and save v7 version: 3.75 mb So, once there's something that needs rasterizing the file size did indeed jump, but not to a level suggesting that the image itself was rasterized i.e.,: v8 = go back to the v1 step (so, the developed raw with no further actions) > right-click > Rasterize... and save v8 version: 120 mb BUT, but, but: v9 = go back to the v1, File > Export... Tiff RGB 16-bit > Export to save v9 version: 96.2 mb No, my bad; ignore all that (see my second comment below). What to make of all that? I don't know. Sound scientific process? I don't know. Interest in doing so? I don't know. But it would seem to me that up until something needs rasterization, the .afphoto file will stay relatively small. The big caveat to the above is that I never tested masking, which might be a type of rasterization itself. But, I had some free time there, but not that much. Cheers to all.

This indeed is another of my Affinity "little things." Not major, not the end of the world, but... ... Every tool should remember its last-used state, and every tool should have a "Reset to defaults" button. Or, in other words, "+1".