Mac Photo: manipulating selections not working

[R C-R]

9 minutes ago, anon2 said:

It's the PPI (or DPI if you prefer) that enables an unambiguous determination of the intended physical size of the output.

The intended physical output size can be considerably different from the document's working DPI/PPI, or for exports the DPI & units specified in the file's metadata.

For example, consider the two files in Silly faces.zip. One is a jpg & the other a png. Opened in Preview app, each specifies TIFF metadata resolution units as inches & X & Y resolutions as 96:

Note also that in the "General" tab Apple has chosen to use "DPI" for Width & Height:

That in no way prevents me from printing out either one using Preview's print options to scale the printout to for example 400% or to one of its Scale to fit options. The same thing applies to using Affinity's print options.

I might intend to print these files (or the native Affinity raster version) at any of these scaled sizes for various reasons, for example because I intend for them to be viewed from far away so it won't matter if they are highly pixelated or blurry due to anti-aliasing, & I want to avoid unnecessarily large file sizes that saving them at a higher DPI or whatever you want to call it would require.

[R C-R]

18 minutes ago, anon2 said:

Dragging, instead of clicking, while placing is resizing the Image object that has been initially created with the same pixel density as the document.

Nope. The image object is not created until it is actually placed in the document, which for clicking & dragging does not occur until the mouse button is released.

20 minutes ago, anon2 said:

The Original Size button will restore the object to its initial pixel density which matches the document pixel density.

Nope. It restores it to the source file's pixel dimensions, whatever they are.

[lepr]

4 minutes ago, R C-R said:

Nope. The image object is not created until it is actually placed in the document, which for clicking & dragging does not occur until the mouse button is released.

Wrong again (that's an error rate of close to 100% for your statements in this thread). You are only considering the UI and not the data structures in the background. The user does not see the Image object at its initial full size, but it has been created by the time you begin dragging and see it rendered at a tiny scale and then increasingly larger as the drag continues.

 

21 minutes ago, R C-R said:

Nope. It restores it to the source file's pixel dimensions, whatever they are.

LOL. You should have written yes, not nope. Restored to the source file's pixel dimensions implies restored to the document pixel density since the object is in the context of the document. 

[R C-R]

1 minute ago, anon2 said:

 The user does not see the Image object at its initial full size, but it has been created by the time you begin dragging and see it rendered at a tiny scale and then increasingly larger as the drag continues.

If you can't see it, how do you know it actually has been created & added at any scale to the document's memory space allocation? I did a few tests with Activity Monitor open to its Memory tab while I placed quite large png & jpeg files (10 MB & larger) into an AP document. At no time during the place process did AP's memory use increase by more than a MB or two, whether or not I just dropped it or dragged it out.

I am not entirely sure what to make of this but it does not seem to be safe to make any assumptions about how this works.

22 minutes ago, anon2 said:

LOL. You should have written yes, not nope. Restored to the source file's pixel dimensions implies restored to the document pixel density since the object is in the context of the document. 

Have you actually tested this? I have done quite a few tests with very large differences between the document & the placed file's Image DPI. (I am using DPI here to avoid confusion because that is what is shown in the context menu dropdown menu that has the Original Size button.) In every test, that button restores the placed image to its original size, not to that of the document.

Are you seeing something different?

[lepr]

1 minute ago, R C-R said:

If you can't see it, how do you know it actually has been created & added at any scale to the document's memory space allocation? I did a few tests with Activity Monitor open to its Memory tab while I placed quite large png & jpeg files (10 MB & larger) into an AP document. At no time during the place process did AP's memory use increase by more than a MB or two, whether or not I just dropped it or dragged it out.

Once again, you look through the wrong end of the telescope. The app doesn't create an object from something that is on the screen; it renders to the screen a representation of an object that has been created.

15 minutes ago, R C-R said:

Have you actually tested this? I have done quite a few tests with very large differences between the document & the placed file's Image DPI. (I am using DPI here to avoid confusion because that is what is shown in the context menu dropdown menu that has the Original Size button.) In every test, that button restores the placed image to its original size, not to that of the document.

Are you seeing something different?

I never said the Image object is restored to the size of the document. Re-read my post.

[VectorCat]

Is it correct to view this Placed Image layer as something that allows you to incorporate higher-res assets, scale them up, down, back up again, until you get your design / illustration just right, without losing resolution of that placed asset..then when you've achieved your desired image, you export, but still have the placed images' resolutions preserved?

 

[R C-R]

4 hours ago, anon2 said:

The app doesn't create an object from something that is on the screen; it renders to the screen a representation of an object that has been created.

I did not say the placed object was rendered from something on the screen. That would be impossible because there is nothing there until it is placed. It does indeed render a representation of an object, that being the image in the file being placed. It is clear it could be rendered at a size different from its native one if the file was just opened to that size.

What is not clear is what that representation actually is or when it is created. If I have this right, you maintain that it is first created as a full sized document object independently of how its representation is then rendered during the placement procedure. I agree that this seems logical, but the problem is a) we do not know if this is what actually is happening 'under the hood," & b) there does not seem to be any indication that the memory used by the app increases during this procedure in a way that would be consistent with that.

4 hours ago, anon2 said:

I never said the Image object is restored to the size of the document. Re-read my post.

You wrote 

Quote

Restored to the source file's pixel dimensions implies restored to the document pixel density since the object is in the context of the document.

What does "context of the document" refer to if not that of the size of the current frontmost document?

[R C-R]

7 hours ago, VectorCat said:

Is it correct to view this Placed Image layer as something that allows you to incorporate higher-res assets, scale them up, down, back up again, until you get your design / illustration just right, without losing resolution of that placed asset.

Yes, that much is correct.

7 hours ago, VectorCat said:

.then when you've achieved your desired image, you export, but still have the placed images' resolutions preserved?

No, depending on the export file type, when the file is exported the image is converted to the document resolution.

[lepr]

2 hours ago, R C-R said:

I did not say [...] 

[...] current frontmost document?

I have real world work to do for the next several hours. I'll return to this thread later today.

[lacerto]

(...)

[R C-R]

1 hour ago, Lagarto said:

It does not matter at which size the image is placed on the document (by dragging the size): if you click the “Original Size” button, it will be reset to the size determined by the document dpi setting...

I think you are right that this is how it should work, but for me sometimes it works like that & other times it does not. For example, sometimes the indicated "Image DPI x" & "Image DPI y" differ from each other, or from the document DPI, or from both.

I have not so far figured out why the behavior is inconsistent or a process that makes it act this way every time.

 

[lacerto]

(...)

[R C-R]

23 minutes ago, Lagarto said:

At least there seem to be rounding errors so for a 300dpi document dpi when resetting heavily distorted image it is common to see e.g. 300 dpi horizontal and 299 dpi vertical ppi.

I sometimes see considerably more difference in the x & y values than rounding errors could explain. I think this might have something to do with some combination of using the History panel or undo/redo, cycling the selection box, changing document units on-the-fly from the ruler, & possibly something else as yet unidentified, but there are so many possible combinations that I have all but given up trying to pin it down to some repeatable sequence that always does this. 

[walt.farrell]

2 hours ago, R C-R said:

I think you are right that this is how it should work, but for me sometimes it works like that & other times it does not. For example, sometimes the indicated "Image DPI x" & "Image DPI y" differ from each other, or from the document DPI, or from both.

I have not so far figured out why the behavior is inconsistent or a process that makes it act this way every time.

(Image) layers have an intrinsic aspect ratio. If you Place the image by clicking or by dragging without the Shift key pressed that aspect ratio will be maintained. In addition, the image's current DPI (PPI) will be a scaled version of the original DPI. At that point, if the original image has equal DPI/PPI in the X and Y directions, it will still have equal DPI/PPI in the scaled version, and Affinity will show only one current DPI value.

On the other hand, when Placing, if you click+drag while holding Shift, you will distort the intrinsic aspect ratio of the image, ending up with different scaling percentages and different DPIs in the X and Y direction. (You can also cause this after the image is Placed, by dragging a corner node while holding Shift.)

[lacerto]

(...)

[walt.farrell]

5 minutes ago, Lagarto said:

I was referring to a state AFTER the user has clicked the "Original Size" button

Thanks. If that is what @R C-R was also referring to, then I can't explain it.

[R C-R]

Just now, walt.farrell said:

Thanks. If that is what @R C-R was also referring to, then I can't explain it.

It was, & I can't explain it either.

[VectorCat]

12 hours ago, R C-R said:

14 hours ago, VectorCat said:

.then when you've achieved your desired image, you export, but still have the placed images' resolutions preserved?

No, depending on the export file type, when the file is exported the image is converted to the document resolution.

What I mean is that, back in the Photo persona, the placed Images' resolution is preserved. You can export to the resolution / format you want, yet still return to the (non-destructive) realm of Photo and make changes using the placed images' preserved resolution. If I'm understanding correctly.

[VectorCat]

This is a good conversation and has teased out important concepts. This feature IMO deserves a better explanation. I'd put it front and center as one of the benefits of using Photo, same discussion as for the other non-destructive tools. I can see myself using this heavily.

[lepr]

20 hours ago, R C-R said:

If you can't see it, how do you know it actually has been created & added at any scale to the document's memory space allocation? I did a few tests with Activity Monitor open to its Memory tab while I placed quite large png & jpeg files (10 MB & larger) into an AP document. At no time during the place process did AP's memory use increase by more than a MB or two, whether or not I just dropped it or dragged it out.

I am not entirely sure what to make of this but it does not seem to be safe to make any assumptions about how this works.

Unsurprisingly, the software behaves differently (and logically) on my Mac to how you allege it behaves on your Mac.

I initiate the Place command and select the image file to place. Before I can click on the canvas to position the Image or click-drag on the canvas to position and size the Image, the memory consumption of AP jumps up by more than the storage space of the image file. When I do actually click or drag to position the Image object's representation on the canvas, there is almost no change in Photo's memory consumption. As I told you, an Image object is created before the user actually sees its rendered representation on the canvas.

There are many threads where your account of the behaviour of your Mac is contrary to the reported behaviour of anybody elses Mac. Either your mac is uniquely endowed with magical properties, or you make mistakes in your testing procedures, or you see what you want to see instead of what is really there. The magical explanation seems least likely to me.

 

[lepr]

 

13 hours ago, R C-R said:

I did not say the placed object was rendered from something on the screen. That would be impossible because there is nothing there until it is placed. It does indeed render a representation of an object, that being the image in the file being placed. It is clear it could be rendered at a size different from its native one if the file was just opened to that size.

An image file will be opened and the entire content of the file will be read, so I don't know what you mean by  "just opened to that size".

 

13 hours ago, R C-R said:

What is not clear is what that representation actually is or when it is created. If I have this right, you maintain that it is first created as a full sized document object independently of how its representation is then rendered during the placement procedure. I agree that this seems logical, but the problem is a) we do not know if this is what actually is happening 'under the hood," & b) there does not seem to be any indication that the memory used by the app increases during this procedure in a way that would be consistent with that.

See my post immediately before this post. Your testing is flawed or you are blind to the evidence that AP creates an Image object before you see a rendered representation of the placed image on the canvas.

 

13 hours ago, R C-R said:

You wrote 

Quote

Restored to the source file's pixel dimensions implies restored to the document pixel density since the object is in the context of the document.

What does "context of the document" refer to if not that of the size of the current frontmost document?

The object's environment, which is the document in which it resides, not the particular pixel dimensions of the document.

[R C-R]

4 hours ago, anon2 said:

Unsurprisingly, the software behaves differently (and logically) on my Mac to how you allege it behaves on your Mac.

There are several things that the software seems to be doing differently on my Mac than it should. I have *.autosave documents that are not removed after the app is quit normally & restarted later. I have fsCachedData folders with hundreds of files in them. The apps sometimes crash when doing something I have done many times without problems, even a few minutes earlier, & then don't crash again after I relaunch the app & do the same thing again.

I am not sure but I think all this either started or became more frequent after I updated the OS from High Sierra to Mojave, which also changed the file system from HFS+ to APSF. That caused a number of performance issues, apparently because APSF does not work well with rotating HD's like the one in my iMac. A month or so ago, I went through a six hour long, tedious procedure to reformat the drive to HFS+ & copy back my apps, user data, document files, etc. to it, file by file. That fixed the performance issues but I still have a number of issues I have been unable to resolve, even after doing everything from reinstalling the OS several more times to repeatedly running Disk Utility, resetting PRAM, & everything else I could think of, including reinstalling the Affinity apps & resetting them. Hardware tests can find nothing wrong but something somewhere definitely is.

[lepr]

19 hours ago, R C-R said:

There are several things that the software seems to be doing differently on my Mac than it should. I have *.autosave documents that are not removed after the app is quit normally & restarted later. I have fsCachedData folders with hundreds of files in them. The apps sometimes crash when doing something I have done many times without problems, even a few minutes earlier, & then don't crash again after I relaunch the app & do the same thing again.

I am not sure but I think all this either started or became more frequent after I updated the OS from High Sierra to Mojave, which also changed the file system from HFS+ to APSF. That caused a number of performance issues, apparently because APSF does not work well with rotating HD's like the one in my iMac. A month or so ago, I went through a six hour long, tedious procedure to reformat the drive to HFS+ & copy back my apps, user data, document files, etc. to it, file by file. That fixed the performance issues but I still have a number of issues I have been unable to resolve, even after doing everything from reinstalling the OS several more times to repeatedly running Disk Utility, resetting PRAM, & everything else I could think of, including reinstalling the Affinity apps & resetting them. Hardware tests can find nothing wrong but something somewhere definitely is.

If your computer operates so mysteriously and unreliably, you might consider stopping using observations of your computer's behaviour as a basis for arguing against information that I post.