Chris B

Yes, a Preset field (not only in JPEG export) becomes empty if the entire collection of controls does not match the definition of any preset.

I agree that the term "selection" is overused and ill-defined.
But the particular usage under discussion has, I think, been there for many years already in the Affinity suite, and I don't recall having seen this question very often, if ever. So it is, apparently, not confusing many users (or, at least, they're not posting about it ).

Where it uses the word selection in the Export screen it is not referring to a pixel selection it is referring to...
"currently selected layer content"
Which means you need to copy each part of your image to separate layers in order to export them as individual PNG files

I have an image which consists of about 10 separate parts. I wanted to export each of them as PNGs to individual files.
However, when I select the export option and choose "selection" (with or without background), the entire document is exported rather than just the stuff inside my selection rectangle.

This is what dev has just said—would this be everyone's preferred method? If so, I can log it as a formal improvement. 
Edit - I've just logged this. It seems this would be the preferred method internally so I hope this satisfies everyone else  

Perfect—thank you MarkXKR,
I also created the .dmp files so this should give dev something to go on. Curiously, a huge discussion has broken out about this so this is really positive. I really appreciate you posting this.

Glad I could help - and there was me thinking I'd caused the issue 😂

Hi Chris
I had two crash reports from yesterday which I've attached. Hope it helps. Let me know if you need anything else.
e953ab70-fb47-4f3b-ae6a-c6103b30e5d7.dmp de7bff3c-72e7-4c4e-ab86-7ec130b93251.dmp

Just trying to save a file and received the message:
'access to the document's file was lost while performing loading'
The file saved was 0bytes and Affinity closed down.
Tried several times, same result. 
Tried shutdown/restart, same result.
Tried saving to a short folder path and saved, no problem.
Original path: FAILED
C:\Users\xxnamexxxx\xxcompanyInsightxxxxxxx\IGM - Documents\Jobs\xxxxxx\4690-01 website\logo\FAVICON\xxxxxx-LOGO_RGB-favicon.afphoto
Revised path: SAVED
C:\Users\xxnamexxxx\xxcompanyInsightxxxxxxx\IGM - Documents\Jobs\xxxxxx\logo\FAVICON\xxxxxx-LOGO_RGB-favicon.afphoto
Is there a limit on the save folder/file character length?
PC / Win10 / AffinityPhoto v1.8.0.585 (haven't upgraded to latest versions as upgrades tend to crash/corrupt)
 

Usually on Windows 10, you've got a max lenght for path of 260 characters.
You can have more modifying the registry.

Hi Wosven
Thx for that. I checked the failing path length and it is 132 characters, which would appear to be within the 260 max. but got me thinking, the local folder is synced with OneDrive and I found this reference below to file path lengths, which may explain it i.e. some of the hidden strings and characters encoding could, in this instance, push it past the maximum length.
A given element (file or folder) cannot be more than 128 characters. A total file path including full path + file name cannot be more than 260 characters. All must be URL encoded so many characters count as 3 characters. This means the limit can be reached faster than expected.  Now need to find out if I can uncover the encoding and resultant length.
 
Thx
 

Publisher shows the same behavior. Makes sense as it is probably the same colormanagement engine. I am doing webconsultantcy work at the moment where I use a lot of screenhots. So in order to get around the colorshift I opened the screenshots in Photoshop and saved them again as both .jpg and .png with the display profile included. But the images still show oversaturated colors. Only if I convert the screenshots in Photoshop to another profile (sRGB) and save them with the sRGB profile included, Publisher gets it right.
Question: do I need to report the bug on the Publisher forum as well?
Thanks

Hi,
If I do all as You described (importing profile then convert to my printer profile) printed image is correct. When it comes to Soft Proof - after conversion I did not see any differences when soft proofing was applied for the selected image with same profile as document. Before printing soft proof layer always was removed.
I think it is good for You all when You working from home - there is much more time for family instead of wasted for traffic jams.

Hi numberonesoniafan
Thanks for reporting this. I'm not sure exactly what's wrong as yet, but I note that if I change the format to RGB/32 (HDR) before converting from the scanner profile to ProPhoto, then it seems to work correctly.
Regards
Justin

Expected behavior: In Affinity Photo, apply a scanner profile to a raw scan with no profile, then convert to a working space such as ROMM RGB. 1) Results should be very similar to doing the same steps in an external app (I don't expect that they'd be pixel-perfect, but any differences should not be perceptible). 2) There shouldn't be any visible color casts in the result.
Actual behavior: Results are perceptibly different between Affinity Photo's result and argyllcms' cctiff. Given a scanned IT8/7.2 target with the profile applied and then converted to ROMM RGB (once in Affinity, and then once with cctiff on a copy of the image), for Affinity Photo the dark grey rectangles in the image have a reddish color cast to them, whereas the output of cctiff has those squares as a neutral grey.
Repro steps:
To generate the Affinity Photo output:
Open the unprofiled image ("raw0010_2019-5-20-downsampled.tiff"). Document->Assign ICC Profile... then Assign the desired scanner profile ("2019-10-27_qh_as_u"). Document->Convert Format/ICC Profile... then Convert to the desired working space profile ("ProPhoto RGB"--see Note 1). Rendering Intent is Relative Colourimetric. Black Point Compensation is on (it also repros with BPC off... doesn't matter). Observe that the grey rectangles at the bottom of the image have a reddish color cast to some of them, #19-21 in particular. (The RGB values confirm that there's more red present.) To generate the cctiff output (can use GIMP instead--see Note 3):
Install cctiff. I downloaded the source code, v2.1.1, at https://www.argyllcms.com/downloadsrc.html and compiled it on my Mac. Run cctiff like so: ~/Argyll_V2.1.1/imdi/cctiff -e ~/Argyll_V2.1.1/icc/ProPhoto.icm -ir /PATH/TO/2019-10-27_qh_as_u.icc -ir ~/Argyll_V2.1.1/icc/ProPhoto.icm /PATH/TO/raw0010_2019-5-20-downsampled.tiff /PATH/TO/2019-5-20-downsampled-output_of_cctiff.tiff
Observe that the grey rectangles at the bottom of the image are all neutral grey.
Notes:
ProPhoto.icm (which displays as "ProPhoto RGB" in Affinity Photo) is argyll's included ProPhoto color profile (which I imported into Affinity's color profiles by just opening some existing file that already had that profile embedded). However, this still repros if I instead convert to the included ROMM RGB profile in Affinity. The scanner profile was generated by argyll separately (scanin and colprof). (I actually used this exact raw image to generate the profile.) I can also generate the expected output (i.e. no reddish color cast in the dark greys) with GIMP (it's using argyllcms under the hood). Just apply the scanner profile, then convert. I don't have Photoshop so I can't do this experiment there. I'm on Affinity Photo 1.8.3, but this repros on 1.7.x as well. I've also attached the output of Affinity Photo's Preferences->Color menu, just in case those settings matter. ProPhoto.icm 2019-10-27_qh_as_u.icc raw0010_2019-5-20-downsampled.tiff 2019-5-20-downsampled-output_of_affinity_photo.tiff 2019-5-20-downsampled-output_of_cctiff.tiff

Chris,
I've uploaded a "bunch" of files.  The AFP file beginning with _DSC2980... has the behavior I described, i.e., slow to load the print dialog (64 sec.), slow to change the printer in the dialog (50 - 55 sec.) and slow to finish the print (64 sec. before the printing message disappears in AFP).
With the other files I have a problem with printing that I just discovered while timing it.  The timing in the print is OK (this is the one that is about as large as yours), but the printout is drastically different from what soft proof shows in AFP, not to mention how everything appears on the screen.  When I export to tiff then print that from Preview, the results very closely resemble the appearance in AFP on my display.  When I print directly from AFP, the result looks like the .pdf that I uploaded.  I produced it by printing to PDF in the print dialog, incl. specifying the ICC profile for the printer.  That is pretty much how the actual print from AFP to the printer looks.  In the AFP file you see at the top a group "Soft proof & corrections".  I use the stuff in here to soft proof with out of gamut stuff displayed, then use adjustments below the soft proof adjustment to correct.  I rarely need to use it, but the result was no different when I did this time.  The print didn't improve at all when I activated the group and the corrections but not the soft proof.  It resembled the print without the corrections.  What's going on?

Hi Chris B,
I was using the monitor with profile emulation REC709, but the problem still remained with other monitor profile settings.
I use monitor profiles and calibrations according to the destination of the images,
one for printing, (custom profile)
one for publication on the WEB ( sRGB with monitor calibration )
one for the creation of audiovisuals ( REC709 with monitor calibration )
Good day and good work Amadio Parolini
 

Thanks, Chris. Renaming the folder was the solution. It works now.

Thanks for confirming I will pass this back to the developers.
@paro - what profile were you using out of curiosity?

Hi Chris B,
I unchecked "Use my settings for this device", then
I installed Photo and after that
I enabled my color management system (Eizo Color Navigator 7) again.
Now Photo works properly.
Thanks a lot
Amadio Parolini

Hello,
I am new to Affinity, so I am sorry if it's my fault. When i tried making pixel art with symmetry turned on and width of the pixel tool was an even number, symmetry mode became inconsistent, it started adding more pixels to one side and doing some weird shapes. It happens everytime.
I have Windows 10, version 1909 and build 18363.836
Sorry for my english, I speak czech
AffinityPhotoReportBug.mp4

Hi Depa
Thanks for the file. This has been fixed for the next beta.
Cheers
Justin

Thank you for the information. Yes, I think it is a layer moving issue, after noticing more closely. The application doesn't exactly crash, but everything freezes up and when I try to close, I get a save dialogue question which I usually cannot click, so I have to force close.
 
Thanks again.

It's one of those improvement that I'm hoping will have no noticeable difference to the majority of users. When it works it should be invisible. Basically, if your node is a child object, it will attempt to keep it within the same parent (keeping it inside the group if possible) no matter where you initiate the drag.
 

Hi Chris, same problem here, I just bought Affinity Designer a few days ago, and started testing it with my tablet today,
 
I did try this actually, but it didnt work.
The other thing is my tablet is kinda old, so the wacom preferences software doesnt even show the Windows Ink button (Although I did check with Wacom and downloaded the only driver for my tablet that works with W10), I have a CTH-670 (Bamboo Create).
Driver: 5.3.5-3

I haven't tried the beta version, so I'll do that right now.

EDIT:
Alright, so with the latest beta 1.8.4.650, the problem seems to be fixed, even with Windows Ink turned on over in the settings section.  👍