Jump to content
You must now use your email address to sign in [click for more info] ×

Recommended Posts

23 minutes ago, R C-R said:

Fundamentally, it all comes down to allowing aliased output or not. If you can live with the "jaggies" that produces then you could have a single-buuton option to snap everything to whole pixel values, but I doubt most users would be very happy with that.

 

I don't believe this is correct. It very much depends on the pixel count of the image you're working with. I come from photography, and I can state confidently that a 5000 x 4000 pixel image scaled to 4167 x 3333 pixels does not in any way look pixelated even though the "correct" scaling size would be 4166.666666 x 3333.333333 pixels. And with small image sizes it very much depends on the goal pursued whether a result that is layed out in some (pseudo-)sub-pixel manner is more desirable or not.

 

Also, I don't see why floating-point pixel values displayed on a whole-pixel grid should not themselves produce some aliasing. (Perhaps less.) This would only be properly prevented by having a true sub-pixel grid that had sufficient resolution not to be detectable by the viewer.

 

The fundamental issue I see here is the whole-pixel grid that is used for display (and for export to most image formats) by Affinity Photo. Anything other than actual whole pixels must introduce some sort of oddity in the visual result. (See my previous post on that.)

 

Edit:

 

And also, you're right of course that some users would not be happy with whole-pixels only. (While others would. I wouldn't venture a guess on how many on either side.) That's why it's proposed to be a (default-off) option. ;)

Edited by Ballonseide
Link to comment
Share on other sites

28 minutes ago, Ballonseide said:

Of course, all this, in the end, is simply a consequence of the fact that pixels (in any practical sense) are indivisible, as others have stressed already. Displaying non-whole pixels is inherently problematic and, to some extent, physically impossible.

There is no need for the "practical sense" or 'to some extent" qualifiers. An image pixel can have exactly one color & one transparency/opacity value, no more & no less. There is no workaround for that, no "sub-pixel" resolution that exists other than for resolution-independent vector objects that are defined geometrically instead of by bitmaps.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

Let me put it this way: The only way to display sub-pixels is to simulate displaying sub-pixels, some way or another. Theoretically, this could be done such that the user would not notice it. But that's not how Affinity Photo works, or any other image editing software that I know of, so the point is merely academic. (Hence the qualifiers.) In practice, you have to live with significant drawbacks. I suspect for Affinity Photo a conscious decision was made to swallow some specific drawback and gain some advantage for vector- or floating point-based functions in return. What I would prefer is an option that would let the user decide what is more important to him, and enable him to work the way he needs to work.

Link to comment
Share on other sites

21 minutes ago, Ballonseide said:

Let me put it this way: The only way to display sub-pixels is to simulate displaying sub-pixels, some way or another.

But there are no sub-pixels in a bitmapped image (like a photo), so there is no "some way or other" to display them. Vector & text objects are not based on bitmaps, which is why they are resolution independent, but photos & all other rasterized images are inherently limited to the resolution of their per pixel level bitmaps. There is no sub-pixel resolution to simulate, no image information hidden below that whole pixel limit.

 

That is why, as you said, there is no image editing software that can process rasterized images at a sub-pixel level. It is not merely academic; it is because there is nothing there to work with.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

48 minutes ago, R C-R said:

But there are no sub-pixels in a bitmapped image (like a photo)

 

That is, of course, true, and inevitably so. But that's just the point: Affinity Photo is not a simple bitmap image editor, and neither does it just store simple bitmaps—not even for pixel layers. This is obvious because the pixels in those layers can have non-integer positions and non-integer sizes. That's the problem. If everything were just square pixels at integer coordinates, I would have nothing to complain about. What I—and apparently some other users—want is precisely an option to always place pixels at integer coordinates, for the very reason that otherwise you have to deal with fractions of pixels (and the way this is dealt with by Affinity Photo causes both visual and usability problems).

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.