Cog and Circle not the same size

[abject39]

In affinity Designer, if I create a 1000x1000px black COG and 1000x1000px white circle and center them on each other, they will not be the same size. Even if I set the Inner radius and Tooth size to 100% and the Notch size to 0%, I can easily see that the Cog is bigger once I zoom in. Is this a bug, or am I misunderstanding how the Cog and Ellipse tool works?

[Alfred]

I see a difference here, too, on Windows and iPad, but in both cases the circle is bigger than the cogwheel (so with the cogwheel on top there’s a thin white circular arc between the each tooth and the coloured square that I positioned behind the other two shapes).

[thomaso]

To me with Ø 350 px a cog is about 0.02 px larger than an ellipse. This deviation increases with the object size. Below Ø 350, 100 and 1000 px at 100,000% zoom level:

[GarryP]

On Windows I can see a slight discrepancy between the sizes. It’s very small but noticeable.

Selecting both the Cog and Ellipse, where the Ellipse is below the Cog in the layer stack, and then using Geometry Subtract shows some small ‘slivers’ where the shapes didn’t quite ‘meet’ – see attached image where lines can be seen between some (but not all) of the ‘islands’ left behind by the Subtract (only some points of interest have been marked).

I wouldn’t like to call this a bug, as such, because I don’t know if this should matter in a general purpose illustration application (rather than a CAD application), but I would say that it’s maybe something that we would be better-off not having to deal with if possible.

I’m pretty sure that this has been brought up before.

[PaulEC]

This is one of those things that I think of as a "theoretical" bug. Yes, it probably is a bug, but it's so  insignificant and obscure that it hardly seems worth worrying about when there are other much more important bugs that do actually impact the usability of the software. 

[Komatös]

The protrusion is caused by the fact that the teeth are flat and not convex.

[GarryP]

11 minutes ago, Komatös said:

The protrusion is caused by the fact that the teeth are flat and not convex.

The teeth aren’t always flat – see attached image.

And if they were always flat I would expect there to be no ‘gaps’ between the ‘islands’ after Subtracting because there would be a sets of thin segments left over.

[abject39]

I'm glad others have been able to verify my findings. What I find odd about this behavior is that even if the cog is converted into Curves, it maintains the same 1000x1000px ratio (up to 6 decimal places), even when we can see the reading is visually incorrect. 

[NotMyFault]

Currently there is only an ellipse shape, not a circle shape. Th ellipse uses 4 nodes and is 1/5000 wrong at maximum vs. Circle. The cog wheel with more nodes gives a better approximation of a circle.

see

 

[NotMyFault]

In other words: the forum is re-inventing the wheel about every 3 years.

[TestTools]

11 hours ago, PaulEC said:

This is one of those things that I think of as a "theoretical" bug. Yes, it probably is a bug, but it's so  insignificant and obscure that it hardly seems worth worrying about when there are other much more important bugs that do actually impact the usability of the software. 

It seems insignificant until that one little thread of an uncovered color appears when the image is magnified on a much larger screen. I have Command-D duplicated circles that then become different colors and in Command-0 mode it is all fine. But when that 20 cm tall image is suddenly 20 meters, these insignificant and obscure theoretical bugs make something unusable …or sucks hours and hours of work to disguise an issue.  

[PaulEC]

I'm sure you're right. But I do wonder just how many people will ever need to put a circle on another shape, then enlarge it to 20 metres tall, and, if they do, if anyone viewing, from a reasonable distance, it will actually notice any problems! As NotMyFault pointed out, the Ellipse Tool does not produce a perfect circle anyway, so it is probably not the best tool if you need a perfect circle! As I said, maybe it is a bug, but maybe it's because you're doing something that the Ellipse Tool wasn't designed to do. (Maybe we need a true Circle Tool!) 

[TestTools]

Indeed; sometimes it sticks out like a sore thumb, sometimes I am the only one who sees it – it depends on what the viewers eyes get entranced with. I, of course, get entranced with the error, and I just cannot un-see it !   

Since the slides are usually made for evaluation of a system – trying to make objective an inherently subjective system, it just can't be released with a flaw. The user might think that it means there is something wrong with their display, then they spend the hours that I should have spent making things perfect, only to find it is not their issue.

Long ago I shared this drawing < https://cinematesttools.com/download/primary-and-secondary-radial-squares/> when I was wondering what I was doing wrong when squares wouldn’t align perfectly – the size of the square would be off just enough. I don’t know if that is still the case. I seem to remember that the solution was to add a lot of zeros in the dimension boxes, so instead of 1.5, make it 1.5000000000. …or so it seemed at the time. 

Good luck to us all.

[thomaso]

11 hours ago, TestTools said:

when that 20 cm tall image is suddenly 20 meters, these insignificant and obscure theoretical bugs make something unusable …

In what way unsuable ?

• If the 20 cm objects get displayed as vector with a projector to 20 m size you would need a projector with a resolution that currently is not available yet to get aware of the deviation. With the available resolution the edges appear jaggy/blurred anyway if upscaled that much.

• When the 20 cm objects are 2D printed at a size of 20 m, they are rasterized and the antialiasing function changes (blurs, smoothes) the edges and object sizes anyway.

• If the 20 cm objects get scaled for 3D output via CNC the deviation hardly matters, for instance if laser cut or printed as 3D object in 20 m size. However, Affinity would hardly be used for the production of technical objects where such deviations must be prevented.

By the way, the example of 20 cm -> 20 m means a scaling of “only” 10,000%, while for a deviation of about 2.5 cm you would need a scaling factor of 100,000% and a resulting object size of 200 m.

[TestTools]

Yes to all these things. But if this ‘orange where it should be yellow’ edge shows up at all, it stands out. You’ve certainly seen fringing where it shouldn’t be regardless of if it is in the jaggy – and the blur is unacceptable if it is a 3rd color when it is supposed to be 2. Of course, if it is a motion picture, it is unnoticeable. But if it is a test slide, then the anomaly shouldn’t be there. 

On a straight horizontal or vertical line, if the color isn’t exactly on the mirror, its non-edge stands out and the wrong shade stands out. Sure, a line at a diagonal will have a jaggy aspect regardless (especially if seen to close). But if colors or shades leak in that aren’t what they should be, it will look like the alignment is wrong, (the appearance of fringing) –  and the tech will wonder why. And now with extremely fine LED screens and laser projectors, precision is even more required. Fringing shows up on the LED screens in different ways with different colors depending on the pixel element placement and algorithm anyway – so it is appropriate that the test material is not a factor.

[abject39]

On 6/23/2024 at 2:15 AM, TestTools said:

Yes to all these things. But if this ‘orange where it should be yellow’ edge shows up at all, it stands out. You’ve certainly seen fringing where it shouldn’t be regardless of if it is in the jaggy – and the blur is unacceptable if it is a 3rd color when it is supposed to be 2. 

This is exactly how I noticed the issue. I create GUIs for my own audio software, which is rasterized and often layered. I work in pixels, where precision is important and could see frindging pixels that were a different color. 

[thomaso]

32 minutes ago, abject39 said:

This is exactly how I noticed the issue. I create GUIs for my own audio software, which is rasterized and often layered. I work in pixels, where precision is important and could see frindging pixels that were a different color. 

Those also could be caused by antialiasing. It is reported quite a few times for vector objects and caused by the way how Affinity renders objects on screen. One way to avoid this may be to adjust the "coverage map" in the layers blend range options, another would be to avoid "Pixel View Mode" in AD …