Crop to canvas in Affinity Photo

[jtlapp]

In Affinity Photo, how do I crop all objects to fit the canvas, so that when I copy the document or subsequently resize the document nothing exceeds the bounds of the crop?

The following do not work:

1. Clip Canvas -- Resizes the canvas to include the entirety of all objects, including those on hidden layers.
2. Resize Document -- Changes nothing unless I change the parameters in the dialog.
3. Crop Tool -- Changes nothing when the crop is the size of the canvas.
4. Marquee Tool -- Seems like it would do the job if I could both properly size it to the canvas and get it to select subsets of images. I'm always selecting entire objects.

I've seen people asking this question for Affinity Designer, apologies if I missed it for Affinity Photo. Thanks!

[Adriano de Regino]

Try rasterizing the layers going out-bounds.

[Gabe]

Hi @jtlapp ,

The crop tool is non-destructive. If you want to delete everything outside the canvas area, just rasterize the layers. Just beware that this will rasterise to the current size of the canvas, not to the size of the image. For example, if your canvas is 100x100px and you have a 500x500px image to fit the canvas, when rasterising, your image will resample to 100x100px. 

Thanks,

Gabe. 

[jtlapp]

Okay thank you @Adriano de Regino and @GabrielM. That did it, but with unexpected results.

I've attached snapshots before and after rasterization. After rasterization I get a transparent line of pixels at the bottom and on the right. This happens regardless of whether I have "Transparent Background" checked in the "Document" menu.

[Gabe]

Are your elements aligned on pixel values and not half-pixel values? Check it in the Transform Studio. If they are, can you please attach the .afphoto file (before the rasterize operation)?

[jtlapp]

Ah! That was it. Both the curves of my logo and the text TM had fractional pixel heights and widths. Resizing the canvas to encompass these fractions prevents the problem.

I'd be happy to send you the .afphoto file by email.

Thank you so much for your help!

[jtlapp]

The Clip Canvas operation results in displaying fractional pixels on the screen.

It isn't sufficient for me to clip the canvas to create a canvas large enough to hold a curve. I also have to increase the dimensions of the canvas by one pixel to hold the fractional dimension. Otherwise I get the transparent edges.

Compare these two images. Notice that the right-most pixel is not square in the clipped canvas. When I increase the canvas width from 240px to 241px (anchoring on the left), the pixels on the right simply widen out to a square.

This makes the clip canvas operation untrustworthy. Why do you display fractional pixels?

Also, when I go to resize a canvas that displays fractional pixels, the resize dialog rounds the fraction to an integer (nearest?). It does not inform me that the canvas has a fractional width. I have to take other measures to discover this.

 

[jtlapp]

When I clip the canvas and export, I get two different renderings depending on whether I expand the canvas on the right by one pixel first. Affinity is making a decision about whether to try to squash the text into 240 pixels or expand it into 241 -- after clipping to tell Affinity to fit the elements.

[Gabe]

If your elements fall in between 2 pixels, clip canvas will clip to the elements' values, as expected. It will not crop, nor move any elements to fit integer values.  

[jtlapp]

3 minutes ago, GabrielM said:

If your elements fall in between 2 pixels, clip canvas will clip to the elements' values, as expected. It will not crop, nor move any elements to fit integer values.  

Lemme just clarify what I was sharing above.

1. I added a text element ("TM").
2. I clipped to canvas
3. I exported to PNG and got that text element rendered as one of the pictures above.
4. I resized the canvas by making it one pixel wider, anchoring on the left.
5. I exported to PNG and got that text element rendered as the other of the pictures above.

Things to notice:

• The text elements are flush with the right side of the canvas in both images, even though one image is one pixel wider than the other.
• The text elements are the same width in both images.

Therefore, the text element was placed 1 pixel further to the right in the second image, despite my not moving it.

I confirmed the location of the text element in both images. One starts at x-coordinate 218, the other at 219.

[jtlapp]

Here are the coords and dims of the text element.

[R C-R]

On 11/9/2018 at 9:22 AM, jtlapp said:

I confirmed the location of the text element in both images. One starts at x-coordinate 218, the other at 219.

 

On 11/9/2018 at 9:25 AM, jtlapp said:

Here are the coords and dims of the text element.

The screenshot very clearly shows that the selected text element starts at 219.2 px & is 21.5 px wide. With those values there is no way for all of it to align to integer pixel values.

[jtlapp]

On 12/3/2018 at 5:19 AM, R C-R said:

 

The screenshot very clearly shows that the selected text element starts at 219.2 px & is 21.5 px wide. With those values there is no way for all of it to align to integer pixel values.

Yeah, I think we established that in another thread.

And yet all other graphics programs manage to preserve the exact image when cropping.

I think Affinity has queued a proposal for ensuring that the crop is large enough to position at fractional coordinates, which would solve the problem. (Instead of trying to shift fractional coords to align at integer boundaries.)

~joe

[jtlapp]

Also worth noting that under this situation cropping will change bitmaps that are embedded in the image, such as by adding partially transparent pixels to bitmaps having only opaque and completely transparent pixels. That's just crazy -- cropping changing embedded bitmaps. I think that's the scenario that got Affinity's attention.

[Gabe]

5 hours ago, jtlapp said:

That's just crazy -- cropping changing embedded bitmaps.

Can you give us an example please? 

[jtlapp]

6 hours ago, GabrielM said:

Can you give us an example please? 

Please see the conversation at 

 

[Gabe]

As Dan mentioned, he has already logged this as an improvement.