vector command depends on the chosen “DPI”

[Oval]

Not really expected/logical that the accuracy of vector commands like “Expand Stroke” depends on the chosen “DPI”.

 

Will this behaviour be corrected?

[Patrick Connor]

1 hour ago, Oval said:

Not really expected/logical that the accuracy of vector commands like “Expand Stroke” depends on the chosen “DPI”.

 

Will this behaviour be corrected?

Other than the fact that the result seems to not follow as closely as I would expect, you can see how line/curve fitting part of stroke expansion will be done to a tolerance, and that the tolerance should be in relation to the document resolution, in other words what you consider to be the granularity of the document. If an effect rasterizes you know that you do not want to see individual pixels so you choose a document resolution that makes the effect look like you wish and you are not distracted by the individual pixels. Vector stroke expansion has used the same logic as to the "resolution" that the stroke has been expanded to.

 

So in my opinion the result should more closely fit the source stroke for all these, but I would expect to see a difference depending upon the document resolution, with the lines fitting less closely on a lower resolution document. So for me it is logical that the accuracy depends on the chosen document DPI.

 

Your simple example does have a logical mathematical solution that could be 100% accurate, that is why your request looks like it is showing a bug. However the Expand Stroke has to cope with any curve and does so with a tolerance that is dpi dependent. To write a generic algorithm for all cases of lines and curves with 100% accuracy is not as simple as correcting the result in this simplified case.

 

Perhaps if the line is made only of straight lines then a different algorithm should be written/used. Is that what you are saying?

 

This seems strongly related to your other recent thread here, please  stick to one thread for one issue.

 

Edited October 25, 2017 by Patrick Connor
linked to similar thread as an after thought

[Alfred]

17 minutes ago, Patrick Connor said:

Perhaps if the line is made only of straight lines then a different algorithm should be written/used. Is that what you are saying?

 

But the OP's isn't made only of straight lines! The right-hand end is curved, and that's where the poorest mismatch occurs at 300dpi. 

 

[Patrick Connor]

Just now, Alfred said:

 

But the OP's isn't made only of straight lines! The right-hand end is curved, and that's where the poorest mismatch occurs at 300dpi. 

 

Hoisted by my own... and at the same time backing up the point I'm making about the algorithm needing to be flexible. Thanks Alfred.

 

I love to be proven completely wrong and for there to be a way to make an expanded stroke that is always a perfect fit (but if we could I do not think it would have the number of curve points that you would expect).

[Oval]

38 minutes ago, Patrick Connor said:

Hoisted by my own... and at the same time backing up the point I'm making about the algorithm needing to be flexible. Thanks Alfred.

 

I love to be proven completely wrong and for there to be a way to make an expanded stroke that is always a perfect fit (but if we could I do not think it would have the number of curve points that you would expect).

 

That vector command should be resolution independently with high accuracy like in other apps (like Inkscape) and should not delete needed points like in the upper example (puny ten points). Afterwards it can be recalculated depending on (output) resolution.

[Oval]

1 hour ago, Patrick Connor said:

other recent thread here

 

Our explanations were deleted there … so we tried it with a new thread here.

[Patrick Connor]

I think that the line fitting to the expanded curve could be improved, but you are suggesting that it is possible to be 100% accurate and I am saying it is not and that users expect less points than this high level of accuracy creates. I am not suggesting that it is being rasterized, but that the vector smoothing has to be done to result in an acceptable number few points. The vector smoothing has a tolerance. If we set the tolerance according to the document DPI then you get some level of consistency as to curve fitting and the concept of "detail". It's a complicated topic that I did a PhD on (never written up, but I did one) and the algorithms are not as simple as you are suggesting. Although you would expect the same result converting this identical object to a stroke independent of the document resolution it is the equivalent of placing the same shape on a document 3 times once a bit more than twice the smallest one and once 10 times the size of the smallest one. Now when converted to stroke we need some level of tolerance to decide how many points is too many and how many is too few. If you use a fitting algorithm for the largest one that results in exacly the same stroke as when converting the smallest one, you have effectively decided that the smallest one needs more detail than the largest one and deserves to fit better than the largest in that the fit of the stroke for the smallest is within fewer pixels of the original than the stroke for the largest. If you could convert with 100% accuracy then this would not be the case, but as soon as you accept that the expanded stroke does not fit perfectly the 'outline' of the line then the "size" of the object is relevant to the detail that you want, and the "size" of the object is determined by the document DPI and the size it is placed on that document.

 

[Patrick Connor]

25 minutes ago, Oval said:

 

Our explanations were deleted there … so we created a new thread here.

I was not aware, thanks for the explanation. (is that the Royal 'we' or am I talking to more than one user?)

[Oval]

On 25. Oktober 2017 at 2:45 PM, Patrick Connor said:

but you are suggesting that it is possible to be 100% accurate

 

No, you used “perfect fit”. We just like to have (at least) the same accuracy like in Inkscape:

 

 

10 points are not enough for that curve.

[Patrick Connor]

Yup, agreed

[Mark Ingram]

10 minutes ago, Oval said:

we

 

Can I ask an unrelated question, who is 'we'?

[Patrick Connor]

4 minutes ago, Patrick Connor said:

Yup, agreed

<Edit> but not if your object is "very small" i.e. is on a very low resolution document or is very small on a high resolution document </Edit>

[Oval]

1 hour ago, Patrick Connor said:

<Edit> but not if your object is "very small" i.e. is on a very low resolution document or is very small on a high resolution document </Edit>

 

We used almost the smallest possible object in Inkscape and got a much better result than in AD. Because Serif claims “most precise vector graphic design software available” purchasers expect that “Expand Stroke” produces at least the same good results.

[MikeW]

I've never understood the decision to make vector document resolution dependent.

 

This image was done in another application. ZOOM is 5000%. The top is the line at 3.34mm. The middle is that line duplicated on itself. The bottom is a view in wireframe mode after converting the duplicated line to curves.

 

[Patrick Connor]

10 minutes ago, MikeW said:

I've never understood the decision to make vector document resolution dependent.

 

This image was done in another application. ZOOM is 5000%. The top is the line at 3.34mm. The middle is that line duplicated on itself. The bottom is a view in wireframe mode after converting the duplicated line to curves.

 

 

That is the sort of result I would hope for too on a small object at that zoom, but I am not writing the code. 

[MikeW]

Thanks for the reply, Patrick.

 

And I'm not even an armchair programmer these days*...just a user/observer. And heck, I don't draw that small for the most part (other than detail that doesn't matter a whole lot). That said, I will enjoy when even the larger items get more accurate than they are--and they have been improved since the early betas and release.

 

Thanks again, Mike

 

(*Though it looks like I may be touching code for an application I finished in early 2005. Now that is gonna be fun...)

[Oval]

2 hours ago, Mark Ingram said:

 

Can I ask an unrelated question, who is 'we'?

Was already discussed. We are some users that hope that Affinity will be the best solution in future. At least seven professionals have shared the same opinion here.

[Mark Ingram]

4 minutes ago, Oval said:

Was already discussed. We are some users that hope that Affinity will be the best solution in future. At least seven professionals have shared the same opinion here.

 

Thanks, but you have 1190 posts, so I don't fancy scrolling through them all to find out! 

I was just puzzled as to why you don't have your own forum accounts?

[Oval]

52 minutes ago, Patrick Connor said:

 

That is the sort of result I would hope for too on a small object at that zoom, but I am not writing the code. 

 

Seems to be the reason why users that have been bashed because they don’t want to discuss code reasons they cannot examine but asked for corrections. Now we have the RC and must ask again.

[Oval]

20 minutes ago, Mark Ingram said:

 

Thanks, but you have 1190 posts, so I don't fancy scrolling through them all to find out! 

I was just puzzled as to why you don't have your own forum accounts?

 

This is why we explained it here. Not all of us have the time to translate, write, upload, make snapshots, create examples, videos, … and it is better to represent an opinion that is secured because multiple users share the same.

[Patrick Connor]

16 hours ago, Oval said:

....Now we have the RC and must ask again.

 

No Oval, just no. We do not have the memory of goldfish. You have asked and do not need to ask again (and again and again) that will not get your request acted on faster.

[MattP]

16 hours ago, Oval said:

 

Seems to be the reason why users that have been bashed because they don’t want to discuss code reasons they cannot examine but asked for corrections. Now we have the RC and must ask again.

Actually, I said earlier in a post with you that I had not got time to fix the stroke expansion problem properly for this version but that I would simply try to optimise the results of the current expansion. I stated that stroke expansion would get fixed in a future release. I made it pretty clear at the time, I thought?

[Oval]

On 25. Oktober 2017 at 6:15 PM, Patrick Connor said:

 

No Oval, just no. We do not have the memory of goldfish.

 

Thanks and just fyi, Patrick: Still unanswered questions since 2015 like “Any news about fixing?”. Almost 30 months ago Serif wrote “this will get fixed and it is a priority” and “wasn't fixed yet because we needed to keep the code stable for the Affinity Photo release”; more than 15 months ago “Expand Stroke will be worked on very soon”. If “Expand Stroke” has not reached the quality of other apps like Inkscape in a few months, probably there will be more questions.

[A_B_C]

Hey Oval,

 

come on, you are seven people, so maybe you could sit down in your office for a moment and talk this through? Everyone knows that the Expand Stroke function is far from perfect at the moment, and yes, it has been a long time since this issue was brought up first. But please let us apply a little common sense now. I don’t think we will get faster results by repeating the same complaints over and over again, as justified as they are.

 

See, I am the last one to doubt that we would need improvements in this case. But I have been using Affinity Designer and Affinity Photo for a lot of projects in the last two years. All of them were completed, and where I had problems, I found a workaround or used a different app. I guess you will do it just the same. In some of my projects, I was actually swearing at the screen, since I would have needed, for instance, to snap those Bézier handles back to a vertical or horizontal position, once they had been moved. This can get excruciating. I know. However, I believe you should see the bigger picture. We have a team of highly motivated and accessible developers who found some really great solutions for problems that were never solved as elegantly before (or as far as I am aware). In quite a few cases, I would have been happy, if I would have had Affinity Designer five or ten years ago. From all I read from you on the forum, I have the impression that you are professionals in your field. So come on, don’t waste your time fighting. The developers have signaled their “Message understood.” I can understand your insistence, but I have the impression that it is time to move on.

 

No offense … 

Alex

[Oval]

3 hours ago, A_B_C said:

I don’t think we will get faster results by repeating the same complaints over and over again, as justified as they are.

 

Danke, lieber Alex. Wenn Patrick Connor zuerst das hier eindeutig illustrierte Problem – dabei geht es um einen bisher nicht behobenen Grundsatzfehler – scheinbar nicht versteht und mit viel Text antwortet – ein Ja oder Nein wäre praktisch gewesen –, wenn wiederholt keine Antwort zu anderen Problemen erfolgt und deshalb gebashed und zurückgestuft wird und wenn dann unterstellt wird, dass man denken könnte, dass Serif das Gedächtnis eines Goldfischs hat, dann ist es doch sinnvoll, ihm in einer kurzen Zusammenfassung zu schildern, warum es im Zeitraum von mehreren Jahren, in denen die anderen Expand-Stroke-Probleme, die nun leider hier vermischt wurden, trotz anderer Bekundungen nicht behoben wurden, immer wieder zu berechtigten Nachfragen kommen muss. Hier wurden keine Vorwürfe formuliert, sondern sachliche Informationen mitgeteilt. In keiner Silbe wurde gedrängt. Nach dem Goldfisch-Vergleich werden wir uns allerdings davor hüten, zu fragen, ob Expand-Stroke vor der neuen MAS-Version weiter verbessert wird. Zeitweise hatte sich die Qualität ja sogar verschlechtert und die Entwicklung stoppte; da drängte sich die Frage förmlich auf.