Selection bug

[Daniel Cremers]

If I make a printscreen then in Affinity Photo (or Designer, Publisher not tested) and New From Clipboard. Next use one of the selection tools. Select and hit Del. Now everything is deleted (also not selected). Same if I would go for Ctrl + J, everything will be copied over (also not selected) to a new layer.

 

I tried to uninstall Affinity and reinstall. Same bug occured. And it does not happen when you just import an image. But if you save your PrintScreen as affinity format and reopen, it still will have the bug.

Edited September 8, 2020 by Daniel Cremers

[Move Along People]

-

[Pšenda]

Hi @Dan C,
I understand that if you insert an external image using the Place command, it is inserted as an Image Layer object. The image can have a higher resolution than the image/document into which it is inserted, and in order to avoid its undesired degradation, its rasterization is left to the user - until he sets the appropriate location and size.
But why insert an image as an object (Image Layer) using the New From Clipboard command, when creating a document that has a resolution and dimensions identical to the inserted image? That's the purpose of the New From Clipboard command - so why does it still have to rasterize?
Thank you for the explanation.

[Dan C]

6 hours ago, Pšenda said:

But why insert an image as an object (Image Layer) using the New From Clipboard command, when creating a document that has a resolution and dimensions identical to the inserted image? That's the purpose of the New From Clipboard command - so why does it still have to rasterize?

If you copy a Pixel layer from within Affinity and use File>New From Clipboard (NFC) then the document will be created with a (Pixel) layer.

If you're copying an image from outside of the Affinity app and then using File>NFC, it will be placed as an (Image) layer to retain any colour space, metadata etc, and we then give the user the option to rasterise this into their document, if they wish.

I hope this clears things up!

[Pšenda]

Thanks for the answer, but I don't understand the reason for the different approach to the image stored in the Clipboard. It's just some image data stored by the user from any application that creates a new document. The same resolution is used, the same color space (if the information is available, otherwise the default is used), the same metadata as if a resterization were performed immediately. If the user wants to transform the image stored in the Clipboard into another resolution/space/metadata - simply into another document, he will use Paste and will not create a new document using NFC.

[R C-R]

43 minutes ago, Pšenda said:

Thanks for the answer, but I don't understand the reason for the different approach to the image stored in the Clipboard. It's just some image data stored by the user from any application that creates a new document.

There is more to the clipboard than you might think. For instance, at least on Macs apps can have their own private clipboard with data that is not shared with any other app, for example for security reasons or because of sandboxing requirements. Shared clipboards can have multiple kinds of data in them. Apps may or may not be able to use all of it, or unambiguously determine which kind(s) of data a user wants to paste into another app.

It is probably much the same for Windows.

[Pšenda]

7 hours ago, R C-R said:

It is probably much the same for Windows.

Of course, so does Windows. E.g. Affinity transfers data via a special file during Copy/Paste operations (it then informs about its name in the Clipboard).

But how does this relate to my question that a new document created from image data stored in a clipboard has yet to be rasterized, and why not do it right away? For users, the different way of processing data from the clipboard depending on which application pasted it is only confusing.

[R C-R]

2 hours ago, Pšenda said:

But how does this relate to my question that a new document created from image data stored in a clipboard has yet to be rasterized, and why not do it right away?

Why should the Affinity app rasterize it at all? Why not give the user the choice of if or when to do that?

[thomaso]

1 hour ago, R C-R said:

Why should the Affinity app rasterize it at all? Why not give the user the choice of if or when to do that?

Because in this particular case of NFC the "choice" feels like fake news: here APh seems to be aware of bitmap content and also seems to be no advantage to have it created as an image layer since, as mentioned by Pšenda, the image content of the clipboard and the layer of the new document created from the clipboard have the same properties. There appears to be no difference (no advantage or disadvantage) in this new layer being either image or pixel layer, from this perspective the "choice" has nothing to choose. Now, since being a pixel layer is required to allow certain edits to this new layer, the "choice" appears rather like a unnecessary lock than a real option for altering this specific NFC layer's properties.

Vice versa being an image layer by default can even give a wrong impression of having options, e.g. a different resolution which would allow non-destructive up-scaling of this layer. Since the app is well aware that there is no difference (or choice) it would appear more true or honest to get placed the NFC layer directly as pixel layer.

In fact, I would expect an NFC layer to be a locked "Background (Pixels)" layer by default – as would any other bitmap content opened in APh from an external source.

It appears APh doesn't handle for NFC any other external clipboard content than pixels (different to "paste" !) but replies with an error message, for instance with text in the clipboard:

It appears interesting but odd that APh pastes clipboard content of a vector shape object which got copied to clipboard from a PDF with Acrobat's object selection tool not as shape but as an empty "(Frame Text)" layer. While with NFC it reports the message above.

[R C-R]

@thomaso, try this:

Open a a variety of PNG files in the Mac Preview app. Open the Inspector window & note that depending on the source there may be various different kinds of data listed in the General, PNG, EXIF, JFIF, IPTC, & TIFF info categories, or maybe just General & PNG, perhaps without any color profile or document unit resolution info at all. There may be nothing more than a software source or an interface type number; there may be different DPI height & depth numbers; & maybe other metadata relevant to one or more data types.

Do the same with a variety of jpg images & you should see the same thing.

Now, still in Preview, copy the file to the clipboard & then, from Finder's Edit menu choose Show Clipboard. Note that regardless of the image file type, it says "Clipboard contents: TIFF image." Of course, that does not really mean there is a TIFF image on the clipboard, only that depending on the app it is pasted into, some or all of the data on it could be interpreted as part or all of a tagged TIFF image.

It is actually much more complicated than that. At that point, it is just a collection of unprocessed raw data that the OS can dynamically process in different ways so it can be pasted into different apps in some usable format. That also depends on what type(s) of data an app can parse to extract the data relevant to the targeted app object, which could be a collection of pixels, vectors, text strings, etc. So the app could receive anything from a few hundred to many megabytes of data, & that may or may not include color profile, document units, or other metadata necessary to create a new document object with the expected/desired properties.

Long story short, it is not true that the clipboard will always contain an image bitmap in a format that can be opened & then rasterized in only one way.

[thomaso]

2 minutes ago, R C-R said:

Long story short, it is not true that the clipboard will always contain an image bitmap in a format that can be opened & then rasterized in only one way.

I am aware that the clipboard can contain various types of content, so I don't think and did not say that "the clipboard will always contain an image bitmap".

1. But the confusing (or disturbing) part is how APh handles clipboard content a.) for NFC and b.) for pasting. Initially the question by @Pšenda was reduced to the part why (= for what purpose or advantage) a screenshot from the clipboard (note: bitmap !) gets pasted as (Image) layer instead of (Pixels) layer. You replied to maintain a choice – but I don't see a real choice as described in my recent post.
––> What advantage can I get from the layer type "(Image)" created as new document from a screenshot in the clipboard? What "choice" in particular do you see?

2. Then, after that thoughts, I tried different clipboard content a.) some "text" from a browser window and b.) a "vector object" from Acrobat. With both these types APh irritates me, too, additionally to the layer-type question before: The app obviously is able to handle both external clipboard types via "paste" but is not able to NFC for the same content.
––> That seems odd, doesn't it?

[R C-R]

1 minute ago, thomaso said:

I am aware that the clipboard can contain various types of content, so I don't think and did not say that "the clipboard will always contain an image bitmap".

I think you may be missing the point of what I wrote following that, that being "in a format that can be opened & then rasterized in only one way." 

6 minutes ago, thomaso said:

Initially the question by @Pšenda was reduced to the part why (= for what purpose or advantage) a screenshot from the clipboard (note: bitmap !) gets pasted as (Image) layer instead of (Pixels) layer.

If I take a screenshot on my iMac, it is not copied to the clipboard. Instead, a new file is created, for me currently a jpg file on the desktop. I also have the option via the third party app TinkerTool to set the screenshot format to the system default or to any of 9 other formats (including PNG, TIFF, JPEG 2000, & even PSD); to include or exclude the shadow when using CMD+Shift+4 to capture a window; & my choice of destination folders. Note that TinkerTool just enables access to normally hidden additional preferences already built into the OS & they can also be accessed via Terminal, so this must be considered when taking a screenshot on a Mac.

If I then open that file, for example with Preview, the Info panel tells me that its color profile is "iMac," its DPI is 144, the bit depth is 8, & the color model is RGB. If from Preview I copy it to the clipboard & then use NFC in Affinity, not surprisingly among other things its color profile is "Display" which is probably not what I want! Because this is a 5K retina iMac, it includes far more pixels than if I had done this on a non-retina Mac. And of course, if I change the screenshot format to something other than the OS default, or open the file with another app & copy it to the clipboard from that app, there is no guarantee that in Affinity NFC will always create the same type of image with the same number of pixels. In fact, if I copy from some apps an alpha channel is created, in others not; that may result in a different document size via NFC in Affinity, & that possibly could depend on some preference in the app I copied the file from.

So to oversimplify a bit, you can't justifiably make the assumption that whatever is on the clipboard is any one specific type of object or whatever data is pasted from it into an app is always going to have the same properties. It just doesn't work like that.

[thomaso]

35 minutes ago, R C-R said:

If I take a screenshot on my iMac, it is not copied to the clipboard. Instead, a new file is created, for me currently a jpg file on the desktop. I also have the option via the third party app TinkerTool to set the screenshot format

That may be your current workflow which you can alter within macOS (without TinkerTool) when you press cmd-5 and choose form the options pull-down the pasteboard as screenshot's target. – In my understanding yours is not this thread's workflow. Remember this topic's start:

On 9/8/2020 at 10:54 AM, Daniel Cremers said:

If I make a printscreen then in Affinity Photo (or Designer, Publisher not tested) and New From Clipboard.

This 'sounds', at least, that in the OP's workflow no externally saved file is involved which got opened by APh. Your samples and excursions are correct but If I suppose right they simply aren't relevant for this discussion and the question for what purpose the screenshot from clipboard (not a file copied to clipboard) get's created in APh via NFC as "(Image)" layer.

And additionally I would like to understand why APh treats various types of content from the clipboard differently, depending on the task to create a layer: either via NFC or via Paste. How comes that APh reports an error message for NFC while it is able to read, transfer and provide the same clipboard content via "Paste"?

[R C-R]

5 hours ago, thomaso said:

This 'sounds', at least, that in the OP's workflow no externally saved file is involved which got opened by APh.

My assumption is that "printscreen" is a Windows only feature, which according to this article may create a file in the Windows Pictures > screenshots folder or just copy the screen image to the Windows clipboard, depending on the OS version & device.

Either way, without knowing the details of what data types the Affinity apps can access from the Windows clipboard (which I assume might be different depending on which store the app came from because of sandboxing), I do not know to what extent either of our assumptions is relevant.

6 hours ago, thomaso said:

And additionally I would like to understand why APh treats various types of content from the clipboard differently, depending on the task to create a layer: either via NFC or via Paste. How comes that APh reports an error message for NFC while it is able to read, transfer and provide the same clipboard content via "Paste"?

I am not entirely sure what you mean by this. NFC & paste have two different targets (a new document vs. a new layer in an existing document). I also do not expect the Affinity or any other app to treat all file or chipboard content types the same way.

[h_d]

6 hours ago, thomaso said:

when you press cmd-5 and choose form the options pull-down the pasteboard as screenshot's target.

You sure? Cmd-5 does nothing for me and Shift-Cmd-5 does not offer the option to save to "pasteboard" (Clipboard on macOS).

[R C-R]

3 hours ago, h_d said:

You sure? Cmd-5 does nothing for me and Shift-Cmd-5 does not offer the option to save to "pasteboard" (Clipboard on macOS).

On my iMac running Mojave or Catalina Shift-Cmd-5 brings up the options shown here, but the result of clicking the record or capture button is always the creation of a file.

EDIT: I just noticed there is an option to save to the clipboard.

[h_d]

5 hours ago, R C-R said:

EDIT: I just noticed there is an option to save to the clipboard.

I will go my grave swearing that I did not have that option when I first looked on screen, but I then checked the Touch Bar on my MacBook Pro and it was there, and when I checked again on screen it was there too. 

[R C-R]

1 hour ago, h_d said:

I will go my grave swearing that I did not have that option when I first looked on screen, but I then checked the Touch Bar on my MacBook Pro and it was there, and when I checked again on screen it was there too. 

As documented here, by default Shift-Cmd-5 launches Screenshot, an app in the Applications/Utilities folder, but as with all the other screenshot related keyboard shortcuts, they can be customized (or disabled) in the Screenshots item in the System Preferences > Keyboard > Shortcuts tab.

I don't have a Mac with a Touch Bar so I do not have the Capture Touch Bar items but since you do, you could even capture that to a file or a clipboard.

There are now so many possible system & application level keyboard shortcuts in the recent versions of the macOS that it is hard to keep track of them all. 😕

[Daniel Cremers]

It is confusing to users to do things this way. If you want to use it this way, there should be some warning and settings for automation. It made me move to another drawing program (for this task) just because I could not figure this out.