[Bug] PCB exposure yields distorted PCB polygons on printers with non-square pixels

[yaqwsx]

System

UVtools v4.0.0 X64
Operative system: Linux 6.6.10-060610-generic #202401051437 SMP PREEMPT_DYNAMIC Fri Jan  5 21:22:38 UTC 2024 X64
Processor: AMD Ryzen 7 PRO 7840U w/ Radeon 780M Graphics
Processor cores: 16
Memory RAM: 22.51 / 30.06 GB
Runtime: ubuntu.22.04-x64
Framework: .NET 6.0.22
AvaloniaUI: 11.0.4
OpenCV: 4.8.0

Sreens, resolution, working area, usable area:
1: 1920 x 1080 @ 100% (Primary)
    WA: 1920 x 1080    UA: 1920 x 1080

Path:       /tmp/.mount_UVtooljniHJb/usr/bin/
Executable: /tmp/.mount_UVtooljniHJb/usr/bin/UVtools
Loaded file: UVtools_demo_file.sl1 [Version: 0] [Class: SL1File]

Printer and Slicer

• Printer: Elegoo Saturn 3 Ultra
• Slicer: source file coming from ChituBox

Description of the bug

When using the PCB exposure for printers without square pixels, the generated image is distorted. For Saturn 3, the generated image should be 79% of the height (squished) when displayed in UVTools. This is expected. However, the generated image seems to weirdly scale the polygons. Look at what is expected and what I got:

The gaps between pads and polygons are smaller than they should be. Also, there are places where the gaps are OK and where they are smaller.

If I manually export SVG from the gerbers, make it 79% of height, rasterize, and import it via UVtools to the print file, I get the correct results.

How to reproduce

1. open the sliced file from ChituBox for Saturn 3
2. run PCB exposure with the gerber file attached
3. observe inconsistent gaps between pads and polygons.

Files

printer_file_and_gerbers.zip

[sn4k3]

ATM I can't open to check, but my guess is that is expected. UVtools take in account the pixel pitch in x and y, however that is not true when it deal with circular command aka arc. The circle function is using center and radius. And the problem is that radius only have one dimension. Same is happening with arcs where an ellipse is used with axis and angle. On those cases UVtools uses the largest pixel side to make the size. I should probably not allow that and trigger an error for printers with odd pixel size. As your pads are curvy I think that is the problem, I will take a look latter.

If you can try to export Gerber with disable all arcs commands and allow only linear movement, that way circles and arcs will turn into lines/dots which will work ok with odd pixels.

[yaqwsx]

This is quite unfortunate. I understand the extra implementation effort. Do you think that a trivial approach with rendering to square pixels and then dumbly rescaling would hurt the quality too much (possibly with a warning this is happening)?

[sn4k3]

I can fix the circles to respect odd pixels, looks like that's the problem in your case:

I review the code and ellipses are also using the pixel pitch, however I can't confirm if they will raise problem or not

[yaqwsx]

That looks great! Thank you very much.

[sn4k3]

Fixed