marcus.fehse

does „by design“ mean it’s an elaborated decision because of something unalterable? i want to apologize for insisting but – with my little knowledge of coding – i would think the function which adds the metadata to the default slice could doubtless be called while exporting any other slice too.

just to explain, why other slices than the default slice could be important: imagine one retouched a photo. the client needs the image in full resolution and a 1:1 version for social media or a somehow cropped version for his website or a PRINT version with some margin around or ... in my workflow i would cascade the MOTIF inside a masked group. my default slice always points to a legacy copy of the document for coworkers who ask for .PSD-files. the second slice would contain the CROP the next the MOTIF and so on. my workaround for now is clipping the canvas before exporting through the default slice to different file formats needed for the MOTIF and then clipping the canvas again to the cropped version with another file format preset for the CROP and so on. it’s much better than restoring all the lost metadata with some tool of your choice. but it’s not as convenient as it could be. wouldn’t it be much easier to have the metadata preserved by the raster graphics editor – as i would definitely expect? ober!schöne grüße, marcus.

hi. as i learned these days: the export persona of affinity photo embeds all the metadata of a document in the default slice only. for all the other slices all metadata – especially CAMERA and GPS data – is lost. it’s not the right place to ask: why? please preserve the metadata through all slices of export persona unless they are checked off. thank you. ober!schöne grüße, marcus.

exactly. thank you for investigating further, @- S -. (i’ve never read this tooltip info inside export persona. my bad.) is there any idea or logical explanation why one would want this behaviour? i’m often exporting my work to different sizes and formats (incl. different colour spaces) for different needs. in most cases CAMERA- and GPS-data is not so important. my personal info, title and subject are added afterwards via an exiftool based script. but loosing all CAMERA- and GPS-data unintended would be no option to me. hence: the tooltip info inside export persona tells me it’s a „feature“. i should definitely place a feature request.

as i wrote before: it is basically the same image exported either via export persona or file > export. after this both exported files got their additional EXIF-data via a script using exiftool written by phil harvey. EXIF-data of the camera and GPS-data is not touched (neither added nor deleted) by this. it’s just used by the script to make some cryptic – or for some software hidden – info human readable like in IPTC:Keywords where the altitude above mean sea level, the camera direction relative to north and the gimbal pitch is noted. any processing prior to the export should not be interesting.

no problem. here we go ... MF-dig-2023_08_05-0009_export.zip

hi. while developing some photos in affinity photo [v2.1.1/macos] unfortunately all EXIF- and GPS-information was lost, after exporting some different formats via the export persona. yes, the „embed metadata“ checkboxes are all checked! to preserve the EXIF- and GPS-information i had to export every slice to every format „by hand“. is there a special setting i’m missing? ... or is this just another BUG? you might check the metadata of both images – one saved with export persona and one with file > export. ober!schöne grüße, marcus.

is there any chance to see this improvement in the near future? i see others also fighting with this strange sub-pixel behaviour since V1.

the files are on their way. my workflow: the aerial was developed in DxO and saved as 16-bit data in sRGB IEC61966-2.1 colour space. the renderings are HDR saved as 32-bit linear openEXR files. in most cases i add some layers for ambient occlusion or a depth layer and group them with a alpha-mask before pasting this to the photo. but even the unedited openEXR file colour- or gamma-shifts when pasted to the 16-bit document. my workaround at the moment is to change the colour space before pasting – either the aerial to 32-bit HDR or the rendering to 16-bit. but this is not intended, isn’t it?

i understand. thank you for keeping this problem in your mind and bringing this issue up again. hej, @serif did you notice the annoying „colour management broken while pasting“ BUG? =;^)

how do you know?

as already mentioned here: not helpful too. you might know a lot about graphics, bit-depth and colour spaces but not enough about respectful behaviour. if a user reports a bug (or what feels like a bug at least) the intention is to help the developers to improve their product. „You should really preprocess ...“ is an advice based on your opinions. you should really ask yourself if someone who reports a bug with the conclusion „in photo1 inserting these layer(s) gives the expected result.“ – which doesn’t sound like a first-time user – wants to hear it’s her or his fault. itIsYourFault again, @NotMyFault! just think about it. ... and sorry to all the others for getting off-topic! i just hope my comment improves the quality of conversation in this part of the affinity-forum a bit.

good to know. let’s hope it’ll get logged as a bug now!

hej @NotMyFault, let’s get serious! i understand your intention to help. but it definitely did not in this case – at least for me. ... and i did not ask for some help. we are in the bug reporting section of this forum. if someone tells me, it’s not a bug, it’s intended, and asks for „one of the source files, and screenshots of the export settings to check if this causes the seam in your case“ with a royal „We would need ...“ on top newbies like me could expect to interact with an official or at least a freelancer. just to be funny: itIsYourFault! ask yourself if this is the right way to communicate. to be honest: the upsizing vectors to a high resolution explanation gave me an idea of why one could decide to rasterise AFTER resizing at least – resulting in a new feature request at the end. so long and take care, m.

thanks @,,,. it’s a bit more complicated at the end, if you work with different, partly nested groups of layers and slices in export persona. but for a direct export via menu or shift+opt+cmd+S it’s a reasonable workaround.

not considering it could be intended i initially reported it as a bug (you will notice i’m new here): it looks like all layers of a document in photo are rescaled before rasterised in a second step and then exported to the harddrive. this might be a good idea for vector artwork which is smaller than the later output BUT gives some really strange results in pixel based documents. even if two pixel squares on different layers are in pixel-perfect position side by side the fraction of a pixel at the edges after resizing gives an (at least for me) unexpected result. from my perspective as a user it is a not the best programmers decision to resize every single layer BEFORE rasterising them in a software which is intended for pixelbased input like photos. it’s on top „expensive“. two full-size layers take the double for computing. masks and effects have to be resized too! but even if you think it’s worth it for some good reason: please give the users the option to rasterise (and crop slices) BEFORE resizing on export. add a small checkbox in the export options please – especially in export persona. thanks.

dear @Dan C. thanks for investigating and your workaround. as i wrote: just deactivating the white rectangle while retouching is sufficient too. best regards, m.

okay. your replies misled me. sorry for my offense. --- sorry, but who is „we“?

well, bug reporting takes time. but i’m neither on their pay role nor beta-tester. what’s your relationship to serif? if my assumption is correct suggesting a small checkbox in the export menu and your consent should be enough from my side to bring it on the way. this is how i see customer relationsship. please tell me if i’m wrong.

i made a screen recording for you. hope this helps. to provide the source files i need more space on your the server (my files are a bit too heavy). screenRecording_2303071252.mov

hm. i work with affinity photo 1 for some years now. if i open some CGI content – always 32-bit HDR in openEXR format – and copy it into a 16-bit RGB document the software works in a – let’s say – consistent way. there is now visible difference between the 32-bit HDR document and the 16-bit RGB document at the end. i would deduce that photo 1 interprets the unbound color values of my openEXR document(s) using some given gamma and clipping. ... and imagine: i’m happy with that! i would understand, if the RGB/32 HDR content would show up darkened because of the gamma and clipping or whatever in the new software. but it shows up like expected (and already known from photo 1)! the problem occures with copy/paste. in other words: in affinity photo 2 i’m forced to decide either to convert my RGB/16 document into RGB/32 color space or my RGB/32 HDR content into RGB/16 color space before composing it even if i’m fine with the fixed interpretation the software already did to show me the RGB/32 HDR content on my 8- or 10-bit device. as any user (aka. client) i’m wondering: why should i? most decisions for brightness, light temperature and so on are already made in CGI (under the influence of monitor/graphics card gamma, operating system and software) before rendering. in most cases there is no need to adjust it once again. just take the RGB/32 layer and paste it to the RGB/16 document like seen in the other tab (and like it did in the previous software version). from the users point of view there is no need to reinterpret the data while pasting.

you are right: upscaling of rasterized vector artwork gives blurry results. of course. but affinity photo is used for pixel based work in most cases ... at least in my subjective perception. at the end it’s up to you to decide if you see more users upscaling small sized vector artwork and fighting with strange results or (either up- or down)scaling pixel based documents resulting in some really weird scaling effects in affinity photo. just a suggestion (you may call it a feature request): how about a small checkbox in the export menu to force affinity photo to rasterize BEFORE scaling? let the users decide if they want some added pixels at the bottom and/or right layer edges! the source file and a screenshot of the export settings are attached for investigation. exportMirrored_v1_10.6.afphoto

NOT new to photo2 but still there: i often use the export persona to export one motif to different sizes (and file formats). i’m not sure if my expectations are wrong but i would reduce all layers to one (rasterize) BEFORE resizing the image. BUT it feels like affinity photo resizes before rasterising. hopefully for a good reason or two! in the past i had to adjust the alignment of some highres panoramic views. i had to rasterize all adjusted panoramas „by hand“ because of an annoying vertical white line at the seam which always appeared on the downsized files. to quickly show the effect i have simulated it by mirroring a digital photo. please notice the thin white vertical line in the middle of the image best seen in the sky which disappears when rasterised on one layer BEFORE exporting another example? i often work on complex highres composings. to show the effect of rasterizing BEFORE resizing have a detailed look on the imprecise masked trees in this example: when exporting a fullHD of this composing we get a kind of grey halo around the trees if the composing is rasterized before exporting the trees appear a bit „crisper“ it’s a very small difference but if one opens the files and magnifies to – let’s say – 400% the effect is visible on the trees in the back. ... and i would expect to reduce the time for recalculation while exporting too, if rasterized BEFORE resizing. especially on pretty complex multilayer composings and lanczos 3 filtering.

NOT new to photo2 but still there: i often use white (hex FFFFFF) rectangles to define the crop (or different crops) of an image. this works pretty good with the export persona. if you move or resize the rectangle the dimensions of the slice to export are updated like linked to the rectangle. nice. BUT ... if i use a stamp to retouch the image on a pixel layer overlay (inside a group cropped by a rectangle) the stamp tool doesn’t work. deactivating the white rectangle while retouching helps =;^) well, i would expect the same behaviour like with a mask layer which does its job. before being asked: white rectangles feel much better for cropping than mask layers. stampWithRectMask_v2.0.4.afphoto

it’s a photo2 behaviour: while inserting a CGI overlay rendered to HDR/32-bit openEXR documents as a layer or a group of layers into a 16-bit document containing a digiphoto levels (or exposure) of the inserted layer(s) shifts to dark. no idea, if i miss a setting (which should be the same in photo1 and photo2). in photo1 inserting these layer(s) gives the expected result.