Using Distort > Equations

[Polygonius]

I have problems to install your macros, are your macros AP macros?

Look at the pic - yours are missing a "s" in the file-name, compairing to this which are working???

[R C-R]

4 minutes ago, Polygonius said:

I have problems to install your macros, are your macros AP macros?

Look at the pic - yours are missing a "s" in the file-name, compairing to this which are working???

The plural form is for importing macro categories into the Library panel. The singular form is for importing a single macro into the Macro panel.

[carl123]

@John Rostron

 

Here's another formula you might want to take a look at

 

 r*max(w,h)/clampmax(800,max(w,h))

 

It uses the Polar coordinate system rather than the Cartesian one

The benefits are that it uses just one line of (relatively simple) code and it will not do anything to images less than 800px on their longest side.  Both our macros will distort them

It also works on images where width equals height

Not done extensive testing with it as yet but it appears to work Ok

 

[John Rostron]

@carl123. Another intreaguing approach. It also shows some nice lateral thinking! I shall have to give it a try. I have to admit that my macro does not take into account the possibility that the longest side is less than the target dimension.

[John Rostron]

I have just tried @carl123's formula on a variety of images, and they all resize as expected. Images less than the target max size are unaffected. I have also tried my macro on a smaller image, and this also does not change the size.

Since @carl123's version is simpler, I would propose that this becomes the definitive version. I will edit my  macro and create versions for other sizes. An interesting question: how can one incorporate a comment in a macro? I would like to acknowledge that the macro is based on @carl123s ideas.

[carl123]

30 minutes ago, John Rostron said:

I would like to acknowledge that the macro is based on @carl123s ideas.

Thanks but no need

We are only having to resort to using Equations to do this as the Macros cannot at present handle transformations properly for different image sizes

Once that is fixed Equations will no longer be needed for this sort of stuff

Hopefully not too long now.

[R C-R]

5 hours ago, carl123 said:

Here's another formula you might want to take a look at

 

 r*max(w,h)/clampmax(800,max(w,h))

I tried this with a variety of images, followed by a Clip Canvas step. It works quite well as long as w & h are even numbers but when either or both are odd, it results in one or more transparent or matte color 1 px edges, due I assume to the max/clampmax term not being an integer number.

 

For example, try it with a new Affinity Photo single pixel layer document with a canvas 805 px wide by 803 px high. Flood fill it with any solid color to make its size obvious. I get a canvas that is 801 px by 799 px, with a 1 px border on all but one edge.

[carl123]

Supposition:

Resizing a 805px by 803px image to 800px wide should give you a 800px by 798.012px image

But since you cant have fractions of a pixels Affinity rounds the number "up" to 799px which then in turn pushes the 800 value up to 801

In the case of a value of 789.012px Affinity should round the number down but I have seen it before where it incorrectly rounds up numbers like this

Not much you can do about that until it is fixed so lets hope no one has a 805px by 803px image they want to resize to 800px

As regards the 1px border problem this is why we do all that Rasterising and InPainting within the macros to get rid of it.

Anyway, time for beer, back tomorrow...

[R C-R]

1 hour ago, carl123 said:

Not much you can do about that until it is fixed so lets hope no one has a 805px by 803px image they want to resize to 800px

I mentioned the 805x803 test case only as a quick way to demonstrate the issue. As it happened, I discovered this when I was testing with a png file sized 2043 px wide × 1488 px high, made from a scan of a photograph. The details are a bit fuzzy in my memory but I think an auto-crop feature in the scanner software may have been responsible for the odd number width.

 

I mentioned the issue because it might be important for batch jobs using a macro to resize multiple files. Maybe there is some way to pre-screen batch job images for odd numbered dimensions, but I have not thought much about how that might be accomplished.

[v_kyr]

Then make w & h first always even numbers if they are odd numbers (adds +1px to odd numbers): 

• 2 * floor((x+1)/2)

[carl123]

9 hours ago, v_kyr said:

Then make w & h first always even numbers if they are odd numbers (adds +1px to odd numbers):

• 2 * floor((x+1)/2)

Which quite surprisingly does not work

The maths looks correct but you have to actually do this

2*floor((x+2)/2)

Which (again surprisingly) subtracts 1px from odd numbered pixels, rather than adds 1px

Me thinks, there be bugs somewhere, probably those Omega pixels not behaving correctly

So the full (summarised) procedure would be something like

2*floor((x+2)/2)
2*floor((y+2)/2)

Clip Canvas
Rasterise
Inpaint

 

 

 

[R C-R]

@carl123, do you mean for this revised floor expression to be used with your alternate polar coordinate version? If so, are the x & y values in it appropriate?

 

I must admit I am still having problems figuring out how it all goes together, so if you do not mind I would be thankful if you could list the complete version of each of the expressions used.

[carl123]

No, you would run 2 separate Equations

The first one to get rid of the odd number of pixels in an image using Cartesian coordinates

The 2nd Equation would be the Polar coordinates one.

 

[R C-R]

18 minutes ago, carl123 said:

No, you would run 2 separate Equations

The first one to get rid of the odd number of pixels in an image using Cartesian coordinates

The 2nd Equation would be the Polar coordinates one.

Thanks for the clarification.

 

One of the things that make mastering the use of equations harder than it should be is there is no way to see what the equation is after it has been applied, so I find it necessary to take notes while I am experimenting with them, particularly for those used in macros. It also does not help that the fields are not large enough to see all of the longer ones at once.

[John Rostron]

I have been trying out @carl123's polar co-ordinates method on odd-pixel-sized images, and indeed, they all result in a longest side of 801. I had intended to abandon my Cartesian co-ordinates algorithm in favour of his polar one, but with this extra complication and even with its solution, I think I will revert to my algorithm. I have checked this out and it always gives the correct size.

A pity, because I think the polar co-ordinates solution is what mathematicians call elegant! A pity also because I have just written a set of resize macros for several target sizes using the polar algorithm.

[R C-R]

It is even more of a pity that there are so many bugs in the equations implementation that getting them to work properly can require a lot of trial & error.

[v_kyr]

5 hours ago, carl123 said:

Which quite surprisingly does not work

The maths looks correct but you have to actually do this

2*floor((x+2)/2)

Which (again surprisingly) subtracts 1px from odd numbered pixels, rather than adds 1px

Me thinks, there be bugs somewhere, probably those Omega pixels not behaving correctly

So the full (summarised) procedure would be something like

2*floor((x+2)/2)
2*floor((y+2)/2)
...

Interesting!

Usually to round a number n to any grid r (e.g. 3rd decimal place, integer or even numbers, 0.5-step, etc.) one would use this formula:

• rounded = r * floor[(n + r/2) / r]

Examples:

4.7 should be rounded to integers (r = 1):
rounded = 1 * floor [(4.7 + 0.5) / 1] = 5

4.739999 should be rounded to 3 decimal places (r = 0.001):
rounded = 0.001 * floor [(4.739999 + 0.0005) / 0.001] = 4.74

-2.5 should be rounded to integers (r = 1):
rounded = 1 * floor [(- 2.5 + 0.5) / 1] = -2

-3.7 should be rounded to even numbers (r = 2):
rounded = 2 * floor [(- 3.7 + 1) / 2] = -4

 

So it might depend on their floor implementation, which usually in prog languages commonly does expect DOUBLE values as input instead of Integers. Further they might do also convert and/or round field input values here previously when read in.

 

[v_kyr]

Here is a quick C/C++ test with w = 803.0, h = 805.0, r = 2 ...

#include <stdio.h> 
#include <math.h> 

//
// To round a double number n to some r
//
double round_number(double n, double r)
{
    n = r * floor((n + r/2) / r);
    return n;
}

int main ()
{
  double w = 803.0, h = 805.0;
  printf ( "Round of w is %.1lf\n",   round_number (w, 2.0) );
  printf ( "Round of h is %.1lf\n\n", round_number (h, 2.0) );
  printf ( "floor of w is %.1lf\n", floor (w) );
  printf ( "floor of h is %.1lf\n", floor (h) );
  return 0;
}

...and run...

v_kyr$ cc -o test test.cc
v_kyr$ ./test
Round of w is 804.0
Round of h is 806.0

floor of w is 803.0
floor of h is 805.0
v_kyr$

...with the formula shown above only odd numbers should usually result to n+1 even numbers.

[Polygonius]

On 12. Dezember 2017 at 11:19 AM, R C-R said:

The plural form is for importing macro categories into the Library panel. The singular form is for importing a single macro into the Macro panel.

Well, but however, as you can see in the picture, my system do not seem to know it. Neither import from inside AP nor the osx "open-with" works?

[v_kyr]

This video here shows the differences, try out if the shown things there do works for you.

[R C-R]

27 minutes ago, Polygonius said:

Well, but however, as you can see in the picture, my system do not seem to know it. Neither import from inside AP nor the osx "open-with" works?

As I said, you use the Macro panel to import a .macro file:

[John Rostron]

@Polygonius, I have compiled several versions of the macro into a Category file (.afmacros). I will upload this tomorrow. It is the most up-to-date version which will work for square images. 

[Polygonius]

19 hours ago, R C-R said:

As I said, you use the Macro panel to import a .macro file:

 

Thx, it works. My fault - but there is a hidden trap - after importing a SINGLE macro it does not appear in the library, just in the macro-recorder itself.

 

@John 

yeah, as long as it not possible to edit an existing macro, it would nice to have different "factory" sizes. Please make one version with the typically foto-size (10x15 cm in europa).

[carl123]

3 minutes ago, Polygonius said:

after importing a SINGLE macro it does not appear in the library, just in the macro-recorder itself.

After you import a single macro you can then save it in the library yourself (with any name you want)

[Polygonius]

For this last step, i was clever enough, by myself;-)  But thx!