PCB Exposure

[grdrgrd]

I'm working with an Anycubic Phonon Mono X 6k to expose PCBs. I created a test pattern (Gerber attached) and imported it using the PCB Exposure tool (UVtools Version 3.5.5 X64). In general this process works much better than any other conversion method I have used, however, when I import my Gerber file I have noticed that all of the features come out about 1-2 mil (25-50 um) too large. With my printer this translated to a 1-2 pixel difference. Obviously it won't be a perfect conversion due to the pixel size, but I was hoping to have the tolerance be one pixel width at most.
After importing I can trim everything using the Morph tool, but that does not help if the features have already grown enough that they are touching each other (especially noticeable in the text and the space widths that are smaller than 4 mil).

I messed around with the source code and determined that I can correct this by subtracting 1 (pixel) from each of the sizes calculated in lines 438-454 of GerberDocument.cs as shown here:

public static Size SizeMmToPx(SizeF sizeMm, SizeF xyPpmm)
    => new((int)Math.Max(1, Math.Round(sizeMm.Width * xyPpmm.Width - 1, MidpointRounding.AwayFromZero)),
        (int)Math.Max(1, Math.Round(sizeMm.Height * xyPpmm.Height - 1, MidpointRounding.AwayFromZero)));

public static Size SizeMmToPx(double sizeXmm, double sizeYmm, SizeF xyPpmm)
    => new((int)Math.Max(1, Math.Round(sizeXmm * xyPpmm.Width - 1, MidpointRounding.AwayFromZero)),
        (int)Math.Max(1, Math.Round(sizeYmm * xyPpmm.Height - 1, MidpointRounding.AwayFromZero)));

public static Size SizeMmToPx(float sizeXmm, float sizeYmm, SizeF xyPpmm)
    => new((int)Math.Max(1, Math.Round(sizeXmm * xyPpmm.Width - 1, MidpointRounding.AwayFromZero)),
        (int)Math.Max(1, Math.Round(sizeYmm * xyPpmm.Height - 1, MidpointRounding.AwayFromZero)));

public static int SizeMmToPx(float sizeMm, float ppmm)
    => (int) Math.Max(1, Math.Round(sizeMm * ppmm - 1, MidpointRounding.AwayFromZero));

public static int SizeMmToPx(double sizeMm, float ppmm)
    => (int)Math.Max(1, Math.Round(sizeMm * ppmm - 1, MidpointRounding.AwayFromZero));

I'm not sure if this is just an issue for my specific Gerber files or if it is more universal. Regardless, it could be handy to include an option in the PCB Exposure tool to add or subtract a custom width from all of the sizes during the import. Unfortunately I only have a basic understanding of C, so I have no idea how to implement this, but if it isn't too difficult I believe it would be a great feature to have.
It could also be useful for exposing soldermasks since that would require the features to be expanded.

Thanks for your consideration, and thank you for this great tool!

DirectWrite_MasterCoupon_REV3.zip

[sn4k3]

Anycubic Photon Mono X 6K have a pixel size of 34.40um meaning 1mm = 29.069 pixels, to be pixel perfect your design should all be in increments of 34.40um.
Since designs are not made with this in mind it will round all sizes and positions. Also i recommend to use mm instead of inch.

Let's say you have a trace width of 1.2mm, translated to pixels is: 1.2 * 29.069 = 34,8828 since there are no half pixels it will round, turn into 35 pixels, give a trace of 1.204mm (Very close). So the difference should at most be 1px only. The problem is worse with tight tolerances and very small sizes.

UVtools can measure distance on the UI, hold Shift and drag over a trace, check the ROI messurement, does it respect the trace width? If you find the diference too large attach the file with pcb generated, indicate the trace, tell-me the original size so i can check from where the difference come.

I can add a option for user to choose where to round up or down.

There's also another rounding problem when doing circles and other features that are in radius, and then dividing diameter per 2 can also add another pixel, eg: circle of 23px is radius of 11.5px, turn into 12px. Those 2 things together may add two pixels as you said

[grdrgrd]

Thanks for telling me about that measurement feature.
I created three Gerber files (attached) to test this. One was created using a pixel sized grid and exported in mm, one was created with a 25 um grid and exported in mm, and the last was created with a 1 mil grid and reported in inches. Each of the Gerber files contains a series of lines and spaces ranging from approximately 1 to 4 pixels wide. Each of their dimensions and their corresponding pixel measurement is written in the Gerber file.
I imported all three of these files as separate layers, and took measurements at your recommendation. The design I made using the pixel sized grid came out a bit better (as expected), however it looks like the larger lines all come out one or two pixels larger than the nominal value (also causing the narrower spaces to be filled in). I also noticed that all of the lines are created using odd numbers of pixels (1, 3, 5, 7, etc.). I wonder if this could be leading to the increase in size.

As you said, this getting very close to the physical limitations of the 3D printer, but if there was a way to decrease the error from 1-2 px to 0-1 px that would be great. It is possible that having the option for the user to choose to round up or down would fix this.

With regards to the features that are in radius, would it be possible to solve this by dividing the diameter before converting to pixels?

UVtoolsTest.zip

[sn4k3]

I have checked, sizes are calculated right, however draw a line with 15px turn into a line of 17px. I have no clue why... I will ask on openCV forum and seek for a anwser why is that. We are talking about a basic line, 15px should be 15px.

Link of the question: https://forum.opencv.org/t/why-draw-a-line-dont-produce-a-line-with-exact-line-thickness/9674

[sn4k3]

Check new version

[grdrgrd]

Thank you!
I just tried the new version and all of the lines and spaces are within the expected tolerance when I used the Round to Zero option.
It does appear that the lines are all still centered on pixels (resulting in the lines all being odd numbers of pixels). It looks like crackwitz mentions this as a current issue with OpenCV in their response to your linked question. If OpenCV managed to improve that to allow lines to be centered on a pixel boundary I think it would further improve the accuracy. That said, I am able to achieve the tolerance I was hoping for as is, so I am happy.
Thanks again for all the work you put into this project!