Strange failure loading an SVG embedding bitmaps for a PCB board

[davidperrenoud]

From ydir...@gmail.com on March 06, 2013 17:26:29

The original idea is to use Fritzing to help in reverse engineering an existing circuit. To this end, I have crafted with help from inkscape an SVG that I should would be accepted. I checked that replacing the refs with a gets correctly groked by Fritzing, but the construct always fail, using either embedded data as in attachment, or external href. I'm using code from svn r6907 on Debian/testing/amd64, with q4 package 4:4.8.2+dfsg-11.

When using "load image file" on a PCB board with that file, the only feedback I get is on stdio:

couldn't create image from ""

After adding a couple of traces I gathered that:

• the message comes from QSvgRenderer::load() when called from FSvgRenderer::finalLoad()
• despite complaining, QSvgRenderer::load() returns true
• the "" filename seems linked to processing the SVG layers one at a time (that filename handling could surely be improved), since filenames are passed as "" when dealing with bytearray data, but I'm puzzled by the fact no filename is passed to QSvgRenderer::load() - would there be any other Fritzing code involved, called from ::load() ?
• not doing any of the cleanup in loadAux does not change a thing, so that cleanup is likely not responsible
• OTOH, if I create a new svg from either of the 2 cleanContents I get for the two layers, inkscape does not display anything out of them, making me wonder

Attachment: voltmeter2.svg.gz

Original issue: http://code.google.com/p/fritzing/issues/detail?id=2452

[davidperrenoud]

From ydir...@gmail.com on March 06, 2013 14:45:11

I can also verify that this file is perfectly displayed by QtSVG in another app of mine, which also hints at a problem in the way Fritzing deals with the SVG.

[davidperrenoud]

From irasc...@gmail.com on March 06, 2013 15:14:34

Fritzing is not able to do any intelligent processing on a bitmap file. At most you could use the file as a kind of background image, against which you could place Fritzing parts.

The purpose of "load image file" for a PCB is to create a custom board shape. This must be a pure SVG file so that Fritzing can parse the shape. Fritzing cannot parse the shape of the bitmap embedded into the svg. The bug here is that "load image file" should reject svgs with embedded bitmaps.

Looking at the image, trying to import it as a logo image (for silkscreen) which also has a "load image file" also will not work because the complex coloration of the original image will defy the default threshholding--layer images in pcb view are really just black-and-white and are not intended to deal with raster colors.

You could change the element id in the image to "breadboard" and try to create a new part, using "load view image" in the Parts Editor. The bitmap does appear, but once you save it as a new part and try to display the part in breadboard view, the image is no longer visible. This is a bug--the image should at least display in breadboard view.

Status: Accepted
Owner: irasc...@gmail.com
Labels: -Priority-Medium Priority-Low

[davidperrenoud]

From ydir...@gmail.com on March 07, 2013 11:11:51

The goal really is to use it as a background - I should have elaborated on why I want to do.

As I said I want to reverse engineer an existing circuit. Compared to the usual workflow for which Fritzing is used, it is just the reverse: you start with an existing board existing as a picture, place the components and copper layers using the background images as guides, and when finished, the ratsnest is the starting point for the schematics view.

Indeed I could go the way of turning the bitmaps into vector drawings as some reverse engineering tutorials do, but I don't think it's worth going this way for simple circuits such as the one at hand.

Any idea about what could be preventing the use of the bitmaps here ?

[vanepp]

For completeness I'll repost this from this forum post here:

https://forum.fritzing.org/t/build-instructions-for-linux-and-windows/5528

"Has someone a SVG with embedded bitmaps for Fritzing?

I would like to see if the reported bug here is still present: “try to create a new part, using “load view image” in the Parts Editor. The bitmap does appear, but once you save it as a new part and try to display the part in breadboard view, the image is no longer visible. This is a bug–the image should at least display in breadboard view.” "

The bug in breadboard is still present as of 0.9.6, but the original question can be solved in pcb by creating a svg with a layerId of silkscreen, load and scale to the appropriate real world size (that is the reason for putting the jpg in to a svg, but it also doesn't display correctly when loaded as a jpg!) the bitmap (I used a jpg here.) Then use "silkscreen image" in core parts to load the created svg. It happily loads the image of the voltmeter (in the original case this would presumably be a photo of an existing pcb to be rebuilt) and displays it in Fritzing.

here is a copy of the svg I used to create the above (just remove the trailing .zip, it is only to keep github happy, this is really a svg.)

pcb.svg.zip

Now on to the bug in breadboard which was accepted above (and which appears to still exist!) First here is the base Fritzing part with no imbedded images (again just delete the trailing .zip to get the .fzpz file)

embedded-image-part.fzpz.zip

now the breadboard svg file with the jpg embedded (again just delete the trailing .zip to get the svg)

svg.breadboard.voltammeter_1_breadboard-image.svg.zip

Now load the embedded-image-part.fzpz in to fritzing, edit it in the Parts editor which looks like this:

then File->Load Image for View->svg.breadboard.voltammeter_1_breadboard-image.svg which is here:

svg.breadboard.voltammeter_1_breadboard-image.svg.zip

which produces this in Parts Editor

Then in Parts editor File-> Save as new part, accept the default prefix and load the resulting part. The jpg image has been lost in the exported part which I believe is the accepted bug. The exported part doesn't have the embedded image in it, and a part created outside the parts editor with the embedded image works correctly (Fritzing happily loads the part and displays the image as expected.)