KLE-France

Well, it doesn't have to be yellow. Or an exclamation point. It just needs to be something. And there's a long history of indicating layer states in AP: the locked layer indicator, the FX indicator, the brush indicator... There's no reason why a deactivated-layer-in-a-group indicator would be any more distracting than those others. Indeed, and should Preflight ever make it to AP, that's a good idea. However, this is also a problem during processing itself (you forget you deactivated a layer, you change something elsewhere, then you remember and reactivate the layer, and that change elsewhere now has to be re-modified or deleted...). Hence the need for an indicator on the layer group itself.

Hello to all! This suggestion concerns at least Affinity Photo. Beyond the very good suggestions concerning groups of layers made here and here, I also want to suggest adding some iconography to indicate when a layer is deactivated within a collapsed group of layers. For example, here is the Layers panel with a group of layers called "graffiti": All of the layers in it are activated: But if I inactivate a layer: then re-collapse the group: there is nothing to indicate that one layer is inactivated in that collapsed group, and thus it is very easy to forget about it, continue the development of the image and then export it with that layer still deactivated. I'm not speaking from experience or anything 😐 Thus, yes, there needs to be some indication—a simple yellow exclamation point would do the trick—that a or several layer(s) are deactivated in a collapsed group. Thanks for hearing me out!

Have to sign in against this request. Having a neutral zone around the entire image is necessary for judging it correctly. Ctrl+0 should always maintain the negative space around the entire image. Enlarging the image to true window width/height could be assigned to Ctrl+Shift+0, or something along those lines, why not, but AP does default "fit to window" correctly.

The famous "+1". All the more so in that the clone tool does this already—or does it remember the last use? In any case, that would be fine too.

Thanks @walt.farrell, and good to know that one can't accidentally import an ICC. At C:\Users\[Me]\.affinity\Photo\2.0\profiles, there is only the empty "Blacklist.txt" file, which we had seen the last time. And at C:\Users\[Me]\AppData\Roaming\Affinity\Photo, there appear to be only remnant 1.0 files in both \Common and \Photo. Following through in this latter to \Profiles, there is again only an empty "Blacklist.txt" file. So, at least that's ruled out. Already a good thing. Thanks again and happy shooting to you.

Hi @Lee D Thank you so much for your interest and sorry for the slow response; I was away this week-end and only checked the forums last night. So, Here is my C:\Windows\System32\spool\drivers\color, noting that in the Folder Options, "Show hidden files, folders and drives" is activated: I don't have screen recording apps on my computer, but here is the Soft Proof's Proof Profile list, one screen after another (left column then right column): And perhaps more usefully, here's everything together: Notice that in the "C:\Windows\System32\spool\drivers\color" image, there are no "PICTO" or "WW" (Whitewall) profiles. The "ghost" profiles from those two printing companies are indicated with red arrows. ("U.S. Web Coated (SWOP) v2" is highlighted in blue only because it is the "default" profile when a Soft Proof layer is opened.) Again, I first reported this problem back in AP V1. Note particularly that the file I had used as an example in that original post, "PICTO_Lambda_Coul_RC_Brilliant_3.icc", is still present as a ghost profile even though I have now updated to AP V2. I'll add that not all icc profiles do this. Indeed, I've installed dozens and dozens of icc profiles, always from PICTO and Whitewall, and most behave as you described above: if they are deleted from C:\Windows\System32\spool\drivers\color, they disappear from the Proof Profile list. Moreover, some previous V1 ghost files did disappear with the update to V2, but not all of them, like the PICTO icc in the preceding paragraph. And finally I'll re-mention that I never knowingly imported the ICCs via File > Import ICC Profile... But is there maybe some keyboard shortcut that I infinite monkey-ed? And if so, where do I need to look in V2's folder structure? Again thanks a million, and happy shooting to you.

This is one last Hail Mary before reporting the following as a bug. I'm rolling this over to this forum because the problem is still present in Affinity Photo 2. But do please see this post in the Pre-V2 Archive of Affinity on Desktop Questions. A brief summary: I'm on a Windows 10, 64-bit machine, now running Version 2.2.1 of AP. When I first reported this problem on February 4, 2020, it was in Version 1.7.3.481 of AP. The "Proof Profile" list in the Soft Proof adjustment layer continues to list icc files that were deleted from C:\Windows\System32\spool\drivers\color years ago thus. This continues to be the case even after a restart of Affinity, and for that matter after a restart of the computer, and for that matter after having updated from AP1 to AP2. To my knowledge, I never imported these ICC files into AP using the "Import ICC Profile..." function on the File menu. I think I've been through all of the various AP files installed on my computer, but have not been able to find these "ghost" ICC profiles. These "ghost" profiles actually work, i.e., selecting them changes the look of the image. So it's not just that they're still listed, it is that they are still active somehow... I'm hoping the fact that this problem continues to exist even after having updated from AP1 to AP2 might set off some bells for someone... Thanks in advance and happy shooting to all.

Hi to all, One last "Hail Mary" before I report this as a bug. Please read the above posts, especially the first one dated February 4, 2020 and the one dated January 28, 2022. The ones in between are other members trying to help (thanks again!), but to no avail. Most notably, I can find no AP folder (and I think I've been through them all) in which these "ghost" ICC profiles can be found. I still have this problem, even though I am now in Affinity Photo 2 (version 2.2.1 as of this writing). Perhaps the fact that this problem continues to exist even after having updated from AP1 to AP2 might set off some bells for someone? Note that I have bumped this over to the Version 2 Affinity on Desktop Questions forum. Thanks in advance!

To v_kyr: In theory my AP sends crash reports automatically (a choice at Edit > Settings > General > Other) To Dan C: Thank you, and send my pre-thanks to the development team; I know they'll have this fixed in a jiffy.

Affinity Photo 2.2.0 Windows 10 Home version 22H2 Reproducible: Yes Hardware acceleration: No (graphics card incompatible with AF hardware acceleration) Occurring using .nef raw files, .dng raw files, and .jpg files (all I'm able to test) EDIT: and with a new file (File > New... > (...) add pixel layer > Change to Develop Persona) No unusual hardware attached to computer (no tablets, duel monitors, etc.), no unusual programs This is a new problem that has appeared with the 2.2.0 version upgrade. No other recent changes have been done for my computer. Trying to delete a preset from the Tones tab in the Develop Persona causes Affinity Photo version 2.2.0 to crash. Recipe: Open any of the above file types, go to the Develop Persona if not already there. Go to the tones tab. Choose a preset from the Preset dropdown menu. From the hamburger menu, choose "Delete preset." On the confirmation dialog, click "Yes." Expected behavior: AP 2.2.0 deletes preset and resets tab to "Default" preset. Observed behavior: AP 2.2.0 crashes.

As the kids say these days, this, this and more this: Then Ctrl+Shift to move by 0.001

@Old Bruce "Why is 4 assumed to be 100%?" Because 4 is the maximum factor applicable on the USM filter (thus "100%", like I did for Amount in Detail Refinement). 'Not me naming these things! "And why "a bit" for the Threshold?" Because a applied "a bit" of noise reduction to the same ends (avoid oversharpening small details) in the Develop Persona. 'Not performing a carefully-designed scientific experiment here! And see below. @Lisbon "In the image that I tested I got very similar results with [these] settings: Detail Refinement (Develop Persona) Radius: 100% / Amount: 100%; USM (Photo Persona) Radius: 4px / Factor: 2 / Threshold: 0" Yes, I'm not contending that you can't get similar results with the USM filter. But now, crank up that USM filter's radius to 100 px (100% like in Detail Refinement) and its Factor to 4 (100% like in Detail Refinement) and see what you get. What's interesting to me, is that in Detail Refinement, Which, according to James and others, "is indeed an unsharp mask filter," you can do exactly what you did and have perfectly acceptable, que dis-je, very good sharpening. I have never seen a USM filter that can be pushed to its maximums and give good results; doing so in any USM filter in any photo retouching program (well, those I've known) will give garish, clownish results. But doing so in Detail Refinement doesn't. Which suggest that its underlying calculations are different from those of a "conventional" USM filter, or in any case that something is different with it (continue reading). "In your first screenshot you have "Detail Refinement" and "Noise Reduction" active. They have almost like an opposite effect. One tends to soften. The other sharpens." Yes, I know. The noise reduction tactic for Detail Refinement is nothing more than that: just a tactic. It happens to limit fine detail sharpening when using Detail Refinement, in a "visually similar" way to Threshold in the USM filter (yes I know they're different). "Different units of measurement. Notice that one comes in percentage and USM in pixels. A radius of 30% is different from 30px." Not according to James Ritson, who, in his response here (same link as above) says: "(...) detail refinement is indeed an unsharp mask filter. The use of percentage rather than pixels for the radius is basically an oversight: at one point, there may have been further designs (e.g. adaptive sharpening), but as it stands, the percentage is simply 1:1 with the pixel radius (so 100% = 100px)." If 100% equals 100 pixels in Detail Refinement then 30% equals 30 pixels. James's comment is by far the most qualified explanation that I've been able to find. If someone has a better one, or a newer one, from a qualified person, please post a link! That's exactly what I'm looking for. But that "percentages equals pixels" doesn't seem to make sense, which is my point: Detail Refinement does not behave like the USM filter does. Or, if it does, its indications are extremely misleading when placed in comparison to AP's own USM filter. You finished with this: "After a bit of trial and error, Radius: 30% / Amount: 100% should correspond more like Radius: 3px / Factor: 2 / Threshold: 0." Quite possibly! And if so, Detail Refinement's indications should be: Radius 0 to 10 pixels (or to 4 pixels? See your first equivalency test) and: Amount 0 to 2 factors (currently no Threshold adjustment there). I Note too that there is a precedent for limited effects in the Develop Persona. For example, Saturation increase is limited to 50% in the Develop Persona; If one wants really garish saturation, one has to jump over to the Photo Persona. So yes, what I'm hoping for is not how to-s but an explanation on the very different (and very good!) behavior of the Detail Refinement function in the Develop Persona. Thanks to both for your input!

Hi to all. The basics: Windows 10, Affinity Photo 1.10.5 (but this has been true since my first-ever version of AP), usually 20 mp-ish images out of a Nikon D7500. Here's what one gets searching for site:https://forum.affinity.serif.com/ "detail refinement". Therein is this post where James Ritson (of Affinity Photo's how-to videos (excellent work James!)) says that "detail refinement is indeed an unsharp mask filter," and adds, speaking of the strange use of percentages therein, that "(they are) simply 1:1 with the pixel radius (so 100% = 100px)." There are also other finds in the search result where various people say that Detail Refinement is basically a USM filter, that the USM filter in the Photo Persona does the same thing, etc. etc... But it doesn't. At least in my case. The Detail Refinement function gives way, way way better results than any of the other various methods of sharpening in AP. But it does not behave like a USM filter does. Going through the various search results and the AP help, I cannot find any convincing explanation for how it works. Because in my experience at least, it does not work like a USM filter. Try this: Open a raw photo in AP, get your exposure somewhere acceptable, then activate Detail Refinement, set Radius to 30% (or even 100%) and amount to 100%, and use Noise Reduction to tame any over-sharpening of tiny detail (or not!). So, according to James's description above, you've got a 30 pixel radius and 100% sharpening. That should, especially in my 20, 21 mpx images, give horrendous halos. But it doesn't: But hey, it's supposed to be a USM filter, so let's deactivate Detail refinement, develop the image (opening it in the Photo Persona), then apply an equivalent USM, i.e., 30 px radius, 100% factor (4) and a bit of threshold to keep it from over-sharpening small detail: Yikes! No, that's not behaving at all like Detail Refinement. Detail Refinement seems to be doing something in the vague concept of capture sharpening. And it's splendid. I love it. You can push it as far as you want, Detail Refinement won't halo; even 100% for both Radius and Amount won't cause haloing--and sometimes even works fine for certain images. But how? I am hoping that maybe a developer can step in to clarify what exactly Detail Refinement does. Sure, I don't need to know the answer to that question; I can just take advantage of this unmatched sharpening tool. But, enquiring minds and all that... By the way and to all: you can also use it post Photo Persona: once you've got your image where you want it do a Merge Visible and send that layer over to the Develop Persona for Detail Refinement. You won't be disappointed. Discuss discuss and thanks in advance to anyone who can shed light on this AP element.

Hi to all, A post to relaunch this subject. I just went through another round of cleaning out C:\Windows\System32\spool\drivers\color and the Affinity Photo Soft Proof adjustment continues to list long-deleted icc files. Everything in the preceding exchanges continues to be true except for being on AP version 1.10.4.1198 now. The "long-deleted" above is important: In the \color folder, there were many icc files downloaded for various printers and papers. After cleaning out the folder, most disappeared from the Soft Proof adjustment's Proof Profile list, but there remains a handful of them that continue to be listed, despite the fact that they no longer exist anywhere on my computer, as best as I can determine. So again, if anyone has an idea as to how to eliminate these "ghosts" from the Soft Proof adjustment's Proof Profile list, I'm all ears. And, should this thread be sent over to whoever as a bug report? Thanks and happy shooting to all.

Reporting back on the idea of deleting the metadata under discussion. I need to note here that there was a third line in the XMP metadata that I hadn't noticed before, labelled "History When" in photos affected by the problem presented here. So we actually have three potential problem lines in the XMP metadata: "Metadata Date" "History When" "Modify date" So, I made a copy of one of the images affected by the issue discussed above (in this case, a photo taken in summer but reprocessed in winter), and deleted the "Metadata Date" line using ExifToolGUI, and re-uploaded it to Google Photos. This first test photo remained affected by the problem, that is, it was out of place, because it had the "GMT+01:00" descriptor in a series of photos of "GMT+02:00" images. Remember that this first copy still had the "History When" and "Modify Date" lines (with the "+01:00" affix) in the XMP metadata. I then made a copy of the copy (thus with "Metadata Date" already deleted), and deleted the "History when" line and uploaded it to Google Photos. This second test photo too remained affected by the problem. I thereafter made a copy of the copy of the copy (thus with with "Metadata Date" and "History When" already deleted) with the intention of deleting the "Modify Date" line in the XMP metadata. But that proved a bit more difficult, because there is also a "Modify Date" line in, for example, the EXIF group, and I didn't want to delete both of those lines. So, I just used the ExifToolGUI's built-in "Remove metadata" function to delete all of the XMP metadata (but no other metadata). I thereafter uploaded this third copy to Google Photos, and this third test photo was unaffected by the problem. It went right where it belonged and showed the correct "GMT+02:00" affix on the date and time in the Google Photos info. Ideally of course, I would have liked to delete just the "Modify Date" line in the XMP metadata, for this third copy but I note that in those XMP metadata, only these three lines, "Metadata date", "History When" and "Modify Date" show the date and time at which the photo had been re-processed (in winter), with the "+01:00" affix. The only other date mentioned in the XMP metadata is "Create Date", which gives the date and time at which the photo was actually taken (in summer), and it does not have a time zone affix. So, we now know that deleting "Metadata Date" alone does not fix the problem. We know that deleting "Metadata Date" and "History When" does not fix the problem. We also know that deleting all three lines does fix the problem. What is left unknown, is whether deleting "History When" alone or deleting "Modify Date" alone would fix the problem... But I don't have the energy to go on! Hope all this helps, and I'm gonna step away from the computer now.

Hi Dan C, Thank you for this confirmation. Indeed since this doesn't happen to photos without the XMP metadata dates, I too deduct that it isn't Google defaulting to the current timezone info but rather misusing the metadata. As for deleting the XMP metadata dates and retesting, uhm, errrr, well, I'll have to figure out how to do that with exiftool (which I only use in a consultative fashion), but yes, I'll give that a try and report back. Thanks again and happy shooting!

Extra information for the above: Having just run into this again, I used the ExifTool function built into XnView MP to compare the metadata of files that I readjusted recently (thus during "normal time") and that were, or were not, affected by the above. All concerned images were taken during the summer (thus during "daylight savings time"). Those that went through Affinity Photo, and thus were affected by the above, have, in the XMP metadata, a "Modify date" and a "Metadata date" with "+01:00" affixed to the end of the data thread. Here's an example of what this looks like: "Metadata Date 2021:11:29 18:50:38+01:00". EDIT: this is the time at which I reprocessed the image. Those that did not go through Affinity Photo, and thus were not affected by the above, do not have these lines in the XMP metadata. Of course, all of the files have, in the File metadata, "File modification", "File Access" and "File Creation" dates and times with the "+01:00" affix, which is normal as they were all modified over the last few days. I hope this extra information can be of use. Again, I don't know if this is truly a bug with Affinity Photo, but I figure that you would at least like to know that there's a compatibility issue between AP and a major online photo storing application, even if this latter might be the one doing weird stuff. Thank again.

The basics: Affinity Photo v. 1.10, Windows 10 Home. I'll note here too that I have a Nikon camera in which there is a "daylight savings time" function that one activates when it comes around. So, in my camera, when daylight savings time becomes active, I don't change the time in my camera, I just change the daylight savings time function to "Yes" and the camera corrects the time automatically. Recipe for the issue: 1) Go take pictures in Winter (so no daylight saving time). 2) While still in winter, process the pictures in Affinity Photo, or a combination of AP, and, say, some other raw developer (in my case, RawTherapee). 3) Upload them to a Google Photos Album and organize the Album by "Oldest first". Everything falls into place nicely and all the photos will show the correct date and time, and the correct time zone, i.e. "GMT+01:00 Central European Time" (thus, "normal time") in my case, when you open the Info function of Google Photos. 4) Wait until summer then open one of your winter photos in AP and reprocess it for X reason and resave the image. 5) Re-upload the new version to the Google Photos Album above: the photo will be out of place. Look at the Info of the photo. The date and time will not have changed, but the time zone will be changed to "GMT+02:00 Central European Summer Time" (thus, "daylight savings time"). 6) Get frustrated, because that photo was not taken during daylight savings time, and now you have to fix the time zone and time data in Google Photos. The same thing happens in the other direction: a photo taken in summer but reworked in winter will be given the "normal time" although it was taken in "daylight savings time". HOWEVER, and here's the weird part: This problem does not manifest on my PC (neither in XnView MP (my main photo browsing app) nor in Window Explorer. Is this Affinity Photo's fault? I don't know, but here's what I can say: I do not encounter this problem for photos that do not pass through AP. For example, a photo taken and initially processed in winter only in RawTherapee (or not processed at all) will, like above, show the correct "GMT+01:00 Central European Time" in the initial upload to Google Photos. Should that photo be reprocessed in summer, again only in RawTherapee, then uploaded again to Google Photos, this new version will still have the correct "GMT+01:00 Central European Time" associated with it. I have not tested this phenomenon in any other photo editing software. So what's happening exactly here I do not know. Is AP perhaps changing how daylight savings time metadata is written to a form known by Windows and Co. but not by Google Photos (this latter resultantly defaulting to the present one)? Pure speculation on my part... Thanks for hearing me out, and if anybody else has encountered this, feel free to sound in. Happy shooting to all!

Exactly. I probably wouldn't mind the extra click on Rotate if it wasn't for the fact that it doesn't adjust to any margin post-rotation. You're just left hanging there Affinity saying, "nope; you have to do everything."

Thanks Walt for your rapid response. ... I'll try to keep my mind open as to the interest of changing that behavior, but ... that just seems silly on the part of Serif. I think I can speak for the photo community by saying that it is very rare that I'm going to crop a landscape orientation out of a portrait image. But nonetheless, thank you. @ Ali, Thanks for the idea, but no, this new behavior indeed affects all images. EDIT: I did try the "Restore Master Presets" function in the Presets Manager (both globally and by category), but that had no effect.

Hi to all, I assume a checked some box somewhere without knowing it, but for the life of me, I can't figure this out. In the past, the crop tool would default the orientation of the crops on the Presets menu to that of the image being worked on, e.g., the presets would be "3:2", "5:4" etc. if the image was in a landscape orientation, or "2:3", "4:5" etc. if the image was in portrait orientation. Now, those presets are always in landscape orientation, obliging a click on the "rotate" button if I'm working on a portrait oriented image. How do I get the crop tool back to its earlier behavior? Thanks in advance and happy shooting.

What do you mean by "a kind of index"? Do you want to send the photos you develop (raw or not) in RawTherapee to Affinity for further adjustments? If so, in RawTherapee: Click on Preferences (square button, bottom left, with three sliders on it) Under General > External Editor > Custom command line, put in the path to Affinity Photo on your computer (on my windows 10, this is C:\Program Files\Affinity\Affinity Photo\Photo.exe but it could be different in your case). This line is telling RawTherapee that you want to use Affinity as your external editor. Click OK Now, when you're developing a photo in RawTherapee and you want to send it to Affinity, you just click on the button that looks like a painting palette with a brush. It's located under the main editing Window. RawTherapee will then send the image to Affinity. By the way, this is more so a question for the RawTherapee forum than it is for the Affinity forum, but I happen to use RT myself; if I'm interpreting correctly what you wish to do, this should work. If it doesn't, you'll get more targeted answers at the RT forum.

Hmmm, my post doesn't seem to be inspiring the useful brainstorming I was hoping for... So, let me at least put my idea forward: I suggest that the Forums could be made more useful for the developers by adding a mechanism with which the forum users could express their support or not for feature suggestions and the like made by others, without necessarily having to add a comment to the thread (to avoid "+1" comments). My first idea was the addition of a simple upvote/downvote feature similar to what's on Reddit or Stack Exchange. Feel free to tell me if the already-available "like" feature functions in that way. Should that be the case, I think it would be a good idea to communicate on that and encourage its use, and furthermore to add "most liked" to the top-level choices on the "Sort by" button (it would be a shame to bury it in the "Custom" dialog). But then, I started thinking, why not a more graded choice? Greater minds than mine would be needed to find the right wording, but imagine, say, a drop-down menu or buttons tied to the initial post (there where the idea was expressed): "This feature is [critical / desirable / no opinion / unimportant / unnecessary] for Affinity Photo (Designer, etc.)." With, obviously, "no opinion" being the default. I'll leave it there. If others choose to continue all the better. Thanks for hearing me out. And, to the developers: don't worry, I know—we know—that the opinions of those using your products do count for you and that you're not ignoring the suggestions made in the forums. My goal with this idea is to maybe make it easier for you to take the pulse of your user base.

Hi John, I had seen that thread. That poster expressed more so a frustration with how slowly new features are rolled out in Affinity, and thus asked the question as to whether it is even worth it to make suggestions in the Forums. In a way, that thread inspired this one. My thread here however isn't about the frequency of adding new features to Affinity, but about how to make the forums more efficient tools for identifying what is highly desired by the community, so that the developers will better know what to concentrate their efforts on. Here, I'm not criticizing the rapidity of new feature role-outs, but seeking to start a discussion on how the forums can be improved.

Hello to all and please hear me out. I love Affinity Photo. And to all the developers: Thank you. You've made a great product at a reasonable price, and frankly, the entire world of computer program developing should be looking to you as models. Like all products, there are opportunities for improvement with those by Affinity. You're conscious of that, hence the Feedback for Affinity forums. However, the forums—I'm posting here in Feedback for Photo on Desktop, but I think this applies to all of them—are kind of a black hole for ideas. An idea gets posted, it inspires (or not) some conversation, and once that has died down, the idea just kinds of fades away, buried under the endless daily onslaught of new ideas. Sure, there's a search feature and some use it; I think most don't; but in any case it doesn't perform super-duper well. And even when someone does take the time to revive an existing idea, well, see the previous paragraphe. I know that you can order threads by "Most Viewed," or "Most Replies." That's already a start for seeing what's important, but frankly kind of a false one. Etc. etc. I actually keep a "Little Things List for Affinity" with no less than 30 items on it as I'm writing these lines. However, there's no way I'm posting it here because we're supposed to make a new post for each suggestion, not to mention that I doubt there is anything on my list that has not already been suggested, and, well, I'll quote myself: "buried under the endless daily onslaught of new ideas." I would like to start a brainstorming session with all the forum users, moderators and developers: How can these forums be improved, so that truly universally-desired/needed improvements can really take front and center and thus be identified by the developers as valuable goals, desired by many. Inversely, how can we nonetheless not make niche ideas disappear completely, because niches can become entire ecosystems when things change. How can we organize our collective thoughts to give them some discernable order, a real structure that could be explored, mined, developed, enriched by those—and we are many—who are looking to do their part for a great program? I hope this post is acceptable here, in one of the more active forums, but to the moderators: if you think it would be better elsewhere, do please move it where it needs to be. I hope we will be many to make suggestions, and to all, happy shooting!