Can't set slice export scale accurately to 0.375x

[MickM]

I'm a bit new to AD and I'm having trouble getting my head around the Export Persona UI (although I do appreciate it's power). I'm trying to output my drawing at 3/8 scale so I set the scale factor in the Slices tab to 0.375 but the tool rounds that to 0.38. Not only is that not the precise size I want, I also end up with lots of horrible aliasing effects. I did try looking through the preference settings so see if there was a universal precision I could set but I couldn't find anything. I was eventually able to make it work by specifying a pixel width that was 3/8 the size of the original width. This makes me think there is just a silly bug that won't let me provide a scale factor of more than 2 decimal places of resolution. Is there something obvious I'm doing wrong trying to set my export scale to 0.375?

[Old Bruce]

Most likely you have your Preferences set to only display 2 decimal places. Rest assured that if you type in 0.375 the application will use 0.375 and display 0.38.

[Pšenda]

50 minutes ago, Old Bruce said:

Most likely you have your Preferences set to only display 2 decimal places.

 

[R C-R]

1 hour ago, Old Bruce said:

Most likely you have your Preferences set to only display 2 decimal places. Rest assured that if you type in 0.375 the application will use 0.375 and display 0.38.

As @Pšenda shows, in the Export persona Slices panel, it doesn't matter what preferences is set to. It rounds the slice size to 2 decimal points so for example when entering 0.375x it becomes 0.38x, so for a slice that is 1920 X 1280 px, the exported slice is 730 × 486 px, not 720 x 480 px.

BTW, this is one of the few places where expressions do not seem to work, so for example I could not find a way to use 3/8 instead of decimal numbers.

[Pšenda]

11 hours ago, R C-R said:

I could not find a way to use 3/8 instead of decimal numbers.

At this point, the export size/aspect is also used as a modifier for the exported file name, where "3/8" or other expressions would not work. So the expressions for use in the file name would always have to be recalculated anyway, and it's just about the accuracy of the calculation and then the subsequent display. It's interesting that Serif didn't use the principle here - I work with maximum precision, but display fewer decimal places by preferences.

[DWright]

As @Old Bruce stated Designer will use the entered 3 decimal place values even though the UI will only show the value to 2 decimal places

[Pšenda]

38 minutes ago, DWright said:

Designer will use the entered 3 decimal place values even though the UI will only show the value to 2 decimal places

This somehow contradicts what is stated here:

15 hours ago, R C-R said:

so for example when entering 0.375x it becomes 0.38x, so for a slice that is 1920 X 1280 px, the exported slice is 730 × 486 px, not 720 x 480 px.

[thomaso]

1 hour ago, DWright said:

Designer will use the entered 3 decimal place values even though the UI will only show the value to 2 decimal places

Apart from @R C-R's size report:

• Is there a reason on purpose that the Transform panel may use the comma as separator – but the Slices panel requires the period? (while the value field and the resulting file name could handle it differently if required for any reason, right?)

• By default a slice gets created pixel aligned. But it is possible to manually type decimals when defining a slice in the Transform panel – while it gets auto-reset to integers in certain moments: Sometimes when confirming in the Transform panel with Tab or Enter key / and always if the slice gets moved in the layout window. – Are this different behaviours by concept / by design? (or possibly changed in V2 ?)

The macOS system setting for the separator appears to be language independent (one affects all):

[R C-R]

4 hours ago, DWright said:

As @Old Bruce stated Designer will use the entered 3 decimal place values even though the UI will only show the value to 2 decimal places

It did not for me, as I explained in my post above, & can be confirmed by experiment. For instance, consider this slice test.afdesign example. It has a single 200x200px slice1. In the Slices panel set it to 0.375x & export that slice to get this slice1@0.38.png file: 

Note that its size is 76x76 px, not 75x75 px (200*0.375).

[Devil_Inside]

I've ran into the same issue...

I have a slice which is 454x454. I need to scale it to 416x416, which requires a 0.9163x multiplier. The multiplier is getting rounded to 0.92x, which results in 418x418 instead.

 

[Pšenda]

3 hours ago, Devil_Inside said:

I need to scale it to 416x416, which requires a 0.9163x multiplier

Isn't it easier to use the exact dimensions of the output image for export, i.e. "416w, 416h"?

[Devil_Inside]

13 hours ago, Pšenda said:

Isn't it easier to use the exact dimensions of the output image for export, i.e. "416w, 416h"?

It's not just a fixed 454x454 to 416x416 conversion. I need a lot of slices of different sizes converted using the same scale factor.

[Pšenda]

49 minutes ago, Devil_Inside said:

I need a lot of slices of different sizes converted using the same scale factor.

So for each Slice, instead of a rounded ratio, you enter the corresponding (exactly and correctly calculated) value.

[thomaso]

1 hour ago, Devil_Inside said:

It's not just a fixed 454x454 to 416x416 conversion. I need a lot of slices of different sizes converted using the same scale factor.

Alternatively, how about scaling the entire document before export (instead of each slice) for exports with slice size 1x ?

[Devil_Inside]

3 hours ago, Pšenda said:

So for each Slice, instead of a rounded ratio, you enter the corresponding (exactly and correctly calculated) value.

I have 100+ slices which might change their size while I iterate on the design. It's too much pain to recalculate everything manually each time. Ideally this should be fixed internally and work with higher precision by default.

 

2 hours ago, thomaso said:

Alternatively, how about scaling the entire document before export (instead of each slice) for exports with slice size 1x ?

That's a viable solution, which I might try. Thanks!

Currently I scale each slice up to a size large enough that I can later batch-rescale back to the desired size without loss of quality using a 3rd party tool.

 

I hope this can be properly fixed by Serif so one wouldn't need to jump through this type of hoops.

[NotMyFault]

Even in case Affinity allows more decimal digits you will run into potential issues:

if the slice h/w are no multiple of 8, you will get fractional pixel sizes, rounded up to whole pixels by Affinity during export. This rounding can

• lead to small deviations from intended aspect ratio
• may create thin lines at right and bottom edges due to partial alpha
• You have no visual control over anti-aliasing and sharpness when scaling size at export
• and many more adverse effects (moire for fine-detailed patterns).

So I really do not understand choosing this workflow (with scaling by odd float numbers at export) if your target is to get pixel-perfect exports.

[Devil_Inside]

1 hour ago, NotMyFault said:

Even in case Affinity allows more decimal digits you will run into potential issues:

if the slice h/w are no multiple of 8, you will get fractional pixel sizes, rounded up to whole pixels by Affinity during export. This rounding can

• lead to small deviations from intended aspect ratio
• may create thin lines at right and bottom edges due to partial alpha
• You have no visual control over anti-aliasing and sharpness when scaling size at export
• and many more adverse effects (moire for fine-detailed patterns).

So I really do not understand choosing this workflow (with scaling by odd float numbers at export) if your target is to get pixel-perfect exports.

I don't care about subpixel rounding errors and I don't need EVERYTHING to be pixel-perfect. My design works just fine with this kind of scaling, I've tried it with workarounds. The limitation under discussion is not subpixel though, it's +/- 2 pixel in my case. In other cases it can be even larger. There is absolutely no reason for it to be limited to 2 decimal places.

[Devil_Inside]

Bumping in hopes that this can still be looked at internally.