Photo cuts off fractional decimal digits of document size

[NotMyFault]

Hi,

despite perfectly able to handle documents with fractional pixel dimensions, Affinity Photo cuts off those decimal digits in all UI places where these numbers are exposed to the user (Resize, Move Tool / Window title, Exif panel).

The only way too see those dimensions is to activate rulers and zoom into the bottom right corner >1000%

I Contrast, Designer displays the data correctly with fractional decimals.

This leads to issues as users are unaware of fractional digits, and when exporting to raster formats, Photo adds 1px in x and y dimension causing semi-transparent bright lines.

 

 

 

[Lee D]

Thanks for the feedback, I'll move this to the Feature Requests section as it's more of an improvement for the UI and not a actual bug.

[NotMyFault]

6 hours ago, Lee D said:

Thanks for the feedback, I'll move this to the Feature Requests section as it's more of an improvement for the UI and not a actual bug.

Hi Lee, any chance to have a second look?
 

Does Affinity really thinks it is intend behavior:

• User creates a document in „inches“ or any other non-pixel unit
• This will lead in 99% of cases to fractional pixel dimensions
• User might change units to px, and Affinity will show wrongly that document has whole pixel dimensions 
• User exports document in raster format (again the 99% use case for Photo) 
• Document export gets an additional px wide row and column with a color that really hurts your eyes and ruins the exported file
• If the user is not aware of these complex dependencies, he will be unable to identify the root cause. You will easily find dozens  of questions or bug reports affected by this issue

Im my view the combined issues:

1. showing wrong document size information,
2. exporting documents in different size (adding +1px in both axis),
3. using erratic colors on those unwanted extra columns

is more a bug than a feature request. 
The most problematic part is the unwanted extra pixels in wrong colors.

If Affinity would leave the extra pixels in the original colors instead of brightening them 2 times, it would be far less severe. But in the current state every document with dark colors at the edge gets ruined in case of non-integer document size (created by unit conversions and these unfortunate decision of hiding the fractional part in UI, but enforcing them in export).

[NotMyFault]

38 minutes ago, LondonSquirrel said:

I read this bug report and the main thread with interest. I could replicate the behaviour but I didn't post anything as there was already enough information.

I disagree with your first two statements being put together like this. It will lead to a fractional pixel dimension only if the inch measurements are themselves fractional, and then only in certain circumstances. e.g. I create an image 10 x 8 inches at 400 dpi. You can see below that I have to go to three decimal places to get to fractional pixel sizes:

10.1*400 = 4040.0
10.11*400 = 4044.00
10.111*400 = 4044.400

While that will occur (as in the example given in the main thread), I don't believe that this affects 99% of cases.

Alternately I could set a 'slightly strange' pixel size and get the same effect, e.g. 401, 402, .... But I can't think why I would want to do that.

As a user from Germany (and Europe), we tend to use DIN paper formats measured in cm instead of inches. This will lead in almost every single case to fractional px values.

When using US/EN based letter formats based in inches, I agree to our argument that you will get whole pixel dimensions.

If you use pt, pica, cm, m, mm you run into the problem. The only situation not running into the problem is using integer multiples and inches as document units.

[ironie/]

I know Affinity / Serif is a UK based company, and Great Britain never accepted SI units, left the EU, drives on the wrong side of the road and the rest of Europe has to accept all this without questioning. And DPI is another anachronism nobody could ever change (this is by no means a fault of Affinity). 

[/ironie] 

 

[Old Bruce]

Just now, LondonSquirrel said:

And how horrible DIN is! Who in their right mind would want a standard paper size of 210x297 of anything? Yes I know it's aspect ratio is the square root of 2. But so what? It would have been easier if it had been 210x300 all these years. And as this is about fractions, 210 * √2 is not 297. That is rounded up.

Fold a sheet of A4 in half and you have an A5 sheet. Other than that there is no real advantage.

[NotMyFault]

2 minutes ago, LondonSquirrel said:

And how horrible DIN is! Who in their right mind would want a standard paper size of 210x297 of anything? Yes I know it's aspect ratio is the square root of 2. But so what? It would have been easier if it had been 210x300 all these years. And as this is about fractions, 210 * √2 is not 297. That is rounded up.

True. For a reason: To avoid fractional digits.

This is the core of my bug report.

Affinity should consistently round up or down. It is inconsistent to round down when displaying document size, but round up when exporting.

[ArieV]

On 4/6/2022 at 10:37 AM, NotMyFault said:

True. For a reason: To avoid fractional digits.

This is the core of my bug report.

Affinity should consistently round up or down. It is inconsistent to round down when displaying document size, but round up when exporting.

Removing fractional pixels would help me out in my processing flow.

They are cumbersome when resizing images for web.  I end up with fractional pixels producing a bright line at the edge of the image in most cases, which looks bad on a dark-skin background.  To avoid this, when I run "resize document", I set one pixel dimension, uncheck the lock icon, and then manually round down the other pixel dimension.  Not a big deal, but it does add time when resizing many images, and it is hard to automate with a macro.

On a more theoretical note, IMHO pixels should be represented by integers and anything vector-related can be represented by real numbers.  Fractional pixels just don't make sense.