How to control DPI for realistic_solder_mask: true in pcb_print output?

[cdwilson]

I'm wondering if it's possible to control the DPI used for the realistic_solder_mask: true in pcb_print output. When I generate a PDF with this option enabled, the resulting PDF looks very pixelated (not sure if I'm doing something wrong):

For comparison, when I generate a PNG with pcbdraw output, I can control the DPI so that the image looks sharp:

[set-soft]

Hi @cdwilson !
Did you try other output formats?
I think this is a problem with the SVG to PDF conversion. Take a look at the edge, it isn't pixelated at all. I noticed some problems, never that pixelated.

[cdwilson]

See attached ModST_Mouse.kicad_pcb.zip (the design will eventually be published open source on GitHub, but I'm just not done with it yet...)

[cdwilson]

Hi @set-soft, just FYI, I did some additional experiments using Inkscape to export SVG soldermask layers to PNG. I was able to get really good results for the realistic soldermask by setting the DPI in Inkscape to a really high value (like 1200).

The PNG output for pcb_print does not currently have a dpi: option, but it does have a png_width: option which I used as a proxy for DPI in my experiments. For example, here's an example PNG generated by KiBot directly with png_width: 13200, which is equivalent to DPI=1200:

Since SVG and PDF are both vector formats, it seems like it should be possible to create the PDF without rasterizing the image in the conversion.

If it is not possible to achieve lossless SVG-to-PDF conversion without an intermediate rasterization step, one alternative option would be to add a dpi: option to the pcb_print output type. This would allow the user to control the tradeoff between the output resolution vs. output file size for any outputs where rasterization is happening (i.e. PDF, PNG, etc). BTW, I think it's helpful to have both dpi: and png_width: options (mutually exclusive)--in some cases, users may want all PNGs to have the same DPI resolution even if the output images have different widths, while other users may want all PNG images to have the same width, irrespective of DPI resolution. What do you think?

[set-soft]

The main problem messing with the DPIs is that you destroy the scales.
The code uses 72 dpi because this is what an SVG point is supposed to represent. If we change it to 300 dpi the page size goes from US Letter to 1164 x 900 mm ... not a good idea.
I'm investigating options.

[set-soft]

3684889 should solve it.

Note that this problem is only relevant for the solder mask. I think RSVG doesn't know a mechanism to map the solder mask into some vectorized object in the PDF, so it generates a rasterized object. Perhaps is too complex and the tool just uses a bitmap.

I changed most of the conversion chain, now is slower, but we have control over the resolution.
SVGs are generated directly, all the other formats are first converted to PDF, then we join the PDF files using internal Python code, during this step I can adjust the page size (broken during the SVG -> PDF conversion because we changed the DPI) and finally we convert the PDF into the output format using Ghostscript (can handle PS, EPS and PNG without problems).
So now a dpi option controls the resolution (defaults to 360, 5 times more than the default).

In addition using png_width: 0 the PNG width is adjusted according to the DPI value.

[cdwilson]

Hi @set-soft, thanks for looking into this.

I'm seeing some issues when trying to generate the realistic soldermask output. For example,

realistic_solder_mask: false:

realistic_solder_mask: true:

Can you checkout this example project? I'm not sure if there is a bug or something I'm doing wrong in the config.

git clone --branch test-soldermask-changes git@github.com:cdwilson/test-kibot.git
cd test-kibot
make
# compare realistic vs. non-realistic soldermask outputs in _build/

[set-soft]

Hi @cdwilson !
I used your test repo and got:

Here is the full output for kibot -d results

result.zip

I got the same using my system and the dev_k6 image, I also tried make release and got the same.

[cdwilson]

Hmm... you are right, different PDF viewers seem to give different results.

Preview on macOS gives:

while Adobe Acrobat on macOS gives this for the same file:

However, on the other design, the PDF viewer still shows some issues, even on evince on Ubuntu:

Are you using the default DPI?

I get the same issue with default or custom DPI (I tried values 72 - 1200).

I know some of the tools limits the used resources.

Which tools? Any ideas for things I can try to change or tweak? Are there any timeouts or things I can try increasing in case some process is not having enough time to complete?

I'll keep experimenting with this to see if I can figure out what is causing this on my side.

[set-soft]

I get the same issue with default or custom DPI (I tried values 72 - 1200).

Did you try using just 1 page?

Which tools? Any ideas for things I can try to change or tweak? Are there any timeouts or things I can try increasing in case some process is not having enough time to complete?

Doesn't look like a time issue, more like a resources issue.

[cdwilson]

Hi @set-soft, I think I am starting to get to the bottom of this. I think there are two separate issues happening here:

Issue No. 1

On the ModST_Mouse.kicad_pcb board that I sent you earlier, I think the SVG generated by pcbdraw is getting clipped incorrectly (not according to the PCB outline). Since the SVG is now used to generate the other outputs, all the downstream outputs (PDF, PNG, etc) are affected.

Here's a screenshot of the SVG opened in Inkscape:

However, pcbdraw has a command line flag -e, --adjust-to-edge which says it will "Adjust size to the board edge". I tried passing this option when KiBot calls the pcbdraw command and it fixed the SVG clipping issue:

+++ b/kibot/out_pcb_print.py
@@ -776,7 +776,7 @@ class PCB_PrintOptions(VariantOptions):
         pcbdraw_command = self.ensure_tool('PcbDraw')
         # Run PcbDraw to make the heavy work (find the Edge.Cuts path and create masks)
         pcbdraw_file = os.path.join(temp_dir, out_file.replace('.svg', '-pcbdraw.svg'))
-        cmd = [pcbdraw_command, '--no-warn-back', '-f', '']
+        cmd = [pcbdraw_command, '--no-warn-back', '-f', '', '-e']
         if id == B_Mask:
             cmd.append('-b')
         cmd.extend([GS.pcb_file, pcbdraw_file])

Here's a screenshot of the same SVG generated with the diff above applied to KiBot:

This also fixes the downstream PNG, PDF, etc.

Issue No. 2

The final PDF generated by pcb_print is not being rendered correctly by the default PDF viewer (Preview) on macOS, but it is rendered correctly by Adobe Acrobat on macOS.

Here's a screenshot showing the PDF in Preview:

Here's a screenshot showing the same PDF in Adobe Acrobat:

However, when I enable keep_temporal_files: true, Preview is able to correctly render the temporary PDF page files generated in the page number (e.g. 01/) temp directories. Here's a screenshot showing Preview correctly rendering the realistic soldermask from the temporary PDF file:

I think the create_pdf_from_pages step is doing something to the final PDF that Preview on macOS can't understand/render:

KiBot/kibot/out_pcb_print.py

Line 920 in 8776953

create_pdf_from_pages(svg_files, output_fn, scale=72.0/self.dpi)

I'm not sure if there is just a bug in Preview, or if the joiner is using some esoteric PDF feature that's not supported, or what... 🤷‍♂️ I'll update if I can figure out what the issue is.

[cdwilson]

Hi @set-soft, just a quick update: I'm not exactly sure what changed on my side since yesterday, but I'm no longer seeing the clipping issue (Issue No. 1). Somehow things just started working today and I have no idea why... (makes me feel like I'm going crazy 🤪) I'll let you know if I see it happen again, but for now, you can assume that one is resolved.

I'm still having the issue with Preview on macOS, but I don't think that's a KiBot-specific issue.

[set-soft]

I'm still having the issue with Preview on macOS, but I don't think that's a KiBot-specific issue.

Vector graphics are too complex, the SVGs generated by KiCad are technically good, but browsers fails to render them.
I don't know enough about SVGs to try solder mask alternatives.