User_783649

It would be really handy to have Designer's Export Persona available in Publisher.
Thanks for your consideration.

Agreed. As someone who only sits in Publisher when doing Designer work (I mean seriously, there is literally no point in using Designer if you own Publisher and Photo as well), the only thing missing is the Export Persona. While I would appreciate having access to the other missing Photo Personas as well, the Export Persona is the most important one for me.

Just to mention another bug affecting RGB/16: on Windows, the color chooser is broken when set to hex mode / 16bit resolution. It does not display the lower 8 bits, but repeats the upper 8 bit by mistake. Again, the data within the file are treated correctly, only the display of the color numbers in the color panel is bogus.
still unfixed in 1.10.5 retail.

RGB/16 still show values (depending on color chooser / info panel settings) from 0-1, 0-100%, 0-255.
The difference is that you have smaller steps. 
 
But you can proof the higher bit depth indirectly, using the procedural texture filter, or boosting brightness so that shadows start to show the higher resolution.
To check at your own:
open a RGB16 file export as RGB8 file place RGB8 file so positions match  set blend mode to difference add levels adjustment on top (not nested), and set white level to 1% Now you see colors from the “lower bits” If in contrast you do the same process starting with a RGB8 image, it will stay black.
 
RGB/16 is still capped at 1.0 - the data is stored as 16 bit integer and converted for display only.
Only if you use RGB/32 you can use values above 1.0, called unbound values in tutorials.
you can use the histogram and adjust min/max settings to check for pixels > 1.0
 
please note that Affinity Apps are currently unable to render the RGB/16 images correctly on screen. The rendering is limited to 8 bit. This has been raised as bug already. Never the less, the exports and files use 16 bit. 
 

Then I think that you will be very pleasantly surprised .....
 

Agree, Aaron. To beat the others in UI/UX field, Serif needs to implement three key things: 
A really fast, low latency multi-player editing mode with state-of-the-art built-in conflict resolving so file damage will never happen whatever everyone does. Existing incremental file saving model may be super beneficial here in order to reduce network overhead. Symbols should be taken to the next level. They should evolve into powerful interactive components with multiple states support and proper encapsulation (nesting). There’s also a need for powerful prototyping tools with optional, customizable animations/micro-interactions. All the rest and truly great stuff is already here (think about existing StudioLink, very powerful text editing and image editing abilities and other useful stuff).

Here too. 👍 Thank you!
Has anyone an idea how this happens? Assuming the command to create a chord is in both panels the same the difference would be in the condition, the color definition. This seems to mean that in Affinity a colour swatch can have a different definition than its corresponding colour well in the colour panel, even if represented by the correct slider / range … ?

@lacerto And what if you try to add tint chord from Swatches panel? Try selecting newly created color swatch in Swatches panel and then create tint chord (via the same icon at the top of the panel or by right clicking the swatch). In your video I noticed that you always creating tint chords from Color panel. Try Swatches panel this time.

Yes, this works!

@lacerto And what if you try to add tint chord from Swatches panel? Try selecting newly created color swatch in Swatches panel and then create tint chord (via the same icon at the top of the panel or by right clicking the swatch). In your video I noticed that you always creating tint chords from Color panel. Try Swatches panel this time.

Until everyone will finally learn that using any kind of cloud synced folders for storing current project files during working with them is a very bad practice and should be avoided.
It may lead to all sorts of syncing errors and unwanted partial fragmentation that might occur when one app is using incremental saving method and cloud service is uploading file by parts at the same time.
It’s always better to temporarily pause syncing while you work on the files and then just turn it back on once you’re done for today.
That should save you from most kinds of possible file damage.

Until everyone will finally learn that using any kind of cloud synced folders for storing current project files during working with them is a very bad practice and should be avoided.
It may lead to all sorts of syncing errors and unwanted partial fragmentation that might occur when one app is using incremental saving method and cloud service is uploading file by parts at the same time.
It’s always better to temporarily pause syncing while you work on the files and then just turn it back on once you’re done for today.
That should save you from most kinds of possible file damage.

@lacerto Seems like I found the way to keep the desired color mode for tint chords — we need to explicitly (re)set the color picker mode when choosing the color. Please see the video attached.

tint-chords.mov

That's not the behaviour I'm seeing on my macOS machine. So I'm with @NotMyFault here. No problems with adding tint chords in CMYK colors.
The only difference I noticed is that if I'm adding color chord straight from Color panel — in that case chords added as RGB colors. And if I create a swatch first (global or not) and create a color chord from it (in Swatches panel) — then it will honor its color mode and create proper CMYK chords.

Well, that was to be expected, wasn't it? - When Apple announces a new, or revised hardware product, they always also give a brief insight into any software innovations that can be expected to come along in this regard. - In this case for iPad hardware, then also a slightly peek preview of a new upcoming "APub for iPad" software.
And Serif of course also has an interest in it that Apple then (pre)shows some of their upcoming products, so to say a win-win situation and good advert for both sides then!

Instead of ‘importing’ the slices into a new document, why not set-up the slices as you need them and then replace the underlying image in the existing document?

I think it will become redundant presently. (hopefully for positive reasons rather than a worldwide disaster)

Strange because v1.7 doesn't work while v1.6 does, respectively a strange X-1 suggestion, assuming that flattening is not the wanted option for the OP.

Very interesting, Bryan. Same images in TIFF format exporting with shadows correctly. Seems like an issue with PNGs.
In APub:

Export to PDF:

Strange, with your used PDF v1.7 (preset "for print"?) my ancient Acrobat reports an issue with the minimum required PDF v.1.4 …


… whereas it works if exported as PDF/X-4, though it reports a lower PDF version (1.6). But then the image gets compressed as JPEG – different to the zip/deflate compression with your PDF.
alpha_X-4.pdf

One last update

Well - My old PC (2018)  and current M1 Mac are perfectly capable to render RGB/32 documents in Photo with higher bit depth, and ok performance
I don't need an App which renders a document fast but wrong. I need an App which renders the document correct, in best possible performance.
 
I always hated disliked jpeg images for visible banding in smooth blue sky caused by the 8 bit limit. Unfortunately Apple still creates 8-bit only in HEIF, whereas Canon / Sony create files with more bit depth. And I hate dislike Affinity to enforce dithering on those self-limited 8 bit gradients (even in RGB/16 documents.

To answer some possible questions:
Preferences->Dither gradients has no impact. The gradient was created by a procedural texture filter, not by a gradient fill. I strongly assume this impacts all platforms (Windows, MacOS, iPad OS) this never worked in any Version of Photo since about 1.5. I use 10bit capable displays since 2009, and a 16bit capable Scanner since 2003. it is a real pity that Affinity does not allow to utilise this essential functionality. Going to RGB/32 is no suitable workaround, because of 2x storage, linear gamma issues, unavailability of many live filters. Will try again with HW acceleration inactive.

please find a even more convincing example below.
I made 3 copies of the file in RBG 8 / 16 / 32 bit.
Then, I exported a PNG version directly from photo. 
Note that the 32 bit version exports to a 16 bit PNG, but it uses a linear gamma, so the grey color differs fro the other examples.
Then again, I opened the PNG files in parallel to the 3 afphoto files and made a screenshot:

Imported this screenshot again into Photo, added a curves adjustment to boost the contrast around the visible mid-grey tone.
Now you can clearly see that Preview renders 16 bit PNG with all 10-bit color depth, whereas Photo only renders 8-bit color depth.

 



grad rgb 8a.afphoto grad rgb 16a.afphoto grad rgb 32a.afphoto

Hi,
this has maybe been reported before, I can't find the old post right now.
If you have a display capable to display 10 bit (or 12 bit), you clearly want to use this in Photo.
Unfortunately, while being capable to crate such documents correctly, the rendering to the display is always limited to 8 bit color depth.
Only when you switch to RBG/32 and EDR mode, Photo is able to render more than 8 bit color depth to the display.
 
The screenshots (from M1 Mac mini with 10 bit capable display) shows the issue by comparing Mac Preview and Photo showing the identical test image.Test file:
https://raw.githubusercontent.com/jursonovicst/gradient/master/test_sequences/1920x1080/gradient_1920-1080_25-50.png