[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-user: Photo mode to the rescue...
On Mon, 6 Sep 2010 22:18:18 -0400
DJ Delorie <dj@xxxxxxxxxxx> 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 <vanessaezekowitz@xxxxxxxxx>
_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user