On Mon, 6 Sep 2010 22:18:18 -0400
DJ Delorie <d...@delorie.com> wrote:

> > How about this: Let footprints contain a file name of an macro image
> > from the top. Then, the photo mode could use the image to render a 
> > populated board. ;-)
> 
> I thought of that, but you need to be able to correctly align the
> photo with the rotated/positioned element footprint.

I like this idea actually.  One way it might work is to take a page from photo 
panorama software - use the idea of "control points" [1].  If I could code, I'd 
implement it as a separate utility, if not as part of of PCB.  Here is how I 
would do it (lots of rambling from a dreamer follows :-) )...

Step 1:  Create the footprint and save it in the usual way - either with a text 
editor, some kind of script or tool, or using PCB.

Step 2: Launch the "control point editor".  The first thing it would do before 
spawning the actual editor window is to pop up a dialog to let you choose the 
footprint file and image file to be loaded, with "Forward" and "Cancel" 
buttons.  Next to the image selector should be an option to rotate the image 
90/180/270 degrees before loading.  Once those are set, "Forward" should bring 
the user to the editor window, which I could see being divided into four parts:

* Upper left:  the footprint as it would be rendered with PCB's "photo" 
exporter, with the image overlaid on top of it and slightly translucent.  A 
slider bar to the left of this part of the window would control the opacity of 
the overlaid image.

* Upper Right:  the footprint as seen in the user's normal PCB environment.  If 
any control points have been set, their marks would be displayed as "+" symbols 
or something similar.

* Lower Right:  the original image, with corresponding control point marks 
displayed, if any.

Footprints and images should default to centered and scaled-to-fit each of 
their respective sections (unless the footprint already has control points, in 
which case the image in the upper left should be scaled and positioned 
accordingly).  All three sections should respond to the user's normal mouse and 
keyboard settings for pan and zoom thereafter.  I'm not sure how this will mesh 
with the processing that is to be done on the overlay image in the upper left - 
maybe pre-render the image according to the control points, and display that.

* Lower left:  The current list of control points followed by buttons marked 
something like "Show/Hide #", "Delete", "Accept", "Preview",  and "Save".

Step 3:  Add and edit new control points.  The user should be able to click in 
either of the two right hand sections to set a mark in each.  Any click in 
either section should move the mark in that section to the new spot.  A 
click-and-drag should also be possible.  Click back and forth between the two 
sections as needed, until both marks are just right.  Click "Accept" to add 
these two marks to the list of control points at the lower left.

If at any point the user sets a new mark in only one of the two right-hand 
sections, and then tries to click and drag on an older mark in either section, 
the new mark should be discarded, and the older mark should be moved per the 
user's request.

If the user has set new marks in *both* sections, the new marks should both be 
automatically added to the control point list, and the older mark should be 
moved per the user's request.

The user should be able to click and drag to move either of the two 
corresponding older marks back and forth as needed, and should click "Accept" 
to commit the changes.  If they don't, their next click other than a 
click-and-drag of these two older marks should cause the changes to be thrown 
out, and a new mark to be set .

When the user is editing an older mark, the corresponding control point should 
be highlighted in the list (and brought into view if it is scrolled off).  When 
the user clicks on a control point in the list, the corresponding marks on the 
right should be highlighted (but without discarding any new marks that may be 
in progress).  If the user was editing an older mark and they click a different 
control point in the list, the change they were making should be discarded.

Depending on the amount of distortion in the image, create maybe 8 to 12 
control points around the periphery of the component.  More is better, to a 
point, but at any rate one needs to account for (ideally small variations in) 
scale, position, rotation, perspective, and lens distortion (e.g. fisheye).

Step 4:  Click the "Preview" button to refresh the footprint/image overlay 
using the current list of control points.  If it needs to be tweaked, to back 
to Step 3.  The "Delete" button would remove whatever control point is 
highlighted in the list.  If the image overlay looks good, click "Save" to 
overwrite the footprint that was loaded, with the new control points (and the 
rotation flag set in the "load files" dialog).  At this point, I guess just 
exit the program.


[1] For those here who don't work with photo software, "control points" are 
pixel-accurate marks set by either the software or the user (or both) that 
indicate identical features between pairs of adjacent, overlapping photos in a 
proposed panorama.  Often numbering into the dozens or hundreds, they're used 
to calculate how to bend and warp each image to match it with its neighbors.  
"Hugin" is one very good open source  program for this purpose, and the above 
outline is very loosely based on that program's control point editor.

-- 
"There are some things in life worth obsessing over.  Most
things aren't, and when you learn that, life improves."
http://starbase.globalpc.net/~ezekowitz
Vanessa Ezekowitz <vanessaezekow...@gmail.com>


_______________________________________________
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Reply via email to