Chroma keying is back

And you didn’t even notice it was gone. Tsk.  I didn’t either.

So anyway, you can now choose a colour from the image (click choose mask colour and then click on the image) and any samples that have that exact same colour will be studiously ignored.

I first put this is for making duotone type effects in conjunction with the shade solid pixel type and a few different colours of pens.

Use PNGs instead of jpegs, because jpegs often have lots of artefacts in them that are not the exact colour you want.  Also bear in mind that it is the underlying colour that is checked for a match with the mask colour, not the averaged out brightness that appears in the density preview.  Oh, and the mask colour is saved to the properties file too, and can be checked by looking at the info screen (press i).

1.1.4 from the downloads section or the code repository.

Have a nice weekend!

State of the art tangle

In case anyone’s interested, here’s my current brain.

Polargraph machine - DFRduino Mega with Adafruit motorshield and micro-sd breakout.

It’s a DFRduino Mega (1280) (ebay) with an adafruit motorshield (oomlout) on top, and an adafruit micro sd breakout (also oomlout) on the side.

This is the jalopy currently running my standalone drawings. The circuit is shown a little better here:

Connections for arduino mega to adafruit micro SD breakout board.

Running commands off the SD card eliminates the pause in between commands completely, it’s brilliant. Currently no way to interrupt it once it’s started, but I plan to add a rudimentary physical interface, a pause/run button at least. Will will be testing various endstop / limit detectors at some point.

I also have a sanguino and a couple of stepstick drivers to test out this weekend.  I think that hardware combo is likely to be the basis of future polargraph machines – the chip in the mega is awful expensive.

-EDIT – Firmware
I realised I didn’t mention anything about the firmware I’m using in the MEGA. It’s available from this branch of the repository. It broadcasts its version in it’s READY statement, saying READY_100 instead, and the controller will spot that and the new buttons will appear:

  • Signal store… This pops up a window that lets you input a filename that any new commands issued will go into instead of being executed.  This will create a file on the sd card on the machine, and fill it command-by-command.  This is still pretty slow.  It puts the machine into store mode.
  • Signal play This signals the machine that it should go back into play mode, and start executing commands again, instead of storing them.
  • Exec from store… This pops up a window to input the name of a file that contains your commands and when you hit submit it starts executing all the commands from that file.

A better way to do it is to hit export queue and save your queue to the card directly using a usb card reader – same result, and much faster, then swap the card back into the machine once you’re done.

So I still need to use the controller.

  1. I layout my artwork, then make sure I have an empty, paused queue before generating all my drawing commands.
  2. Then plug my sd card into the pc so it appears as a drive.  Now export queue to a text file on the sd card.
  3. Take the card out and put it into the polargraph machine and reset it.  It needs to be reset to initialise the card.
  4. Connect the controller and start the queue.
  5. Set home and move the gondola to the home point.
  6. Queue->Exec from store and enter the name of the file I just saved onto the sd card.
  7. The machine gets that message and starts drawing.  Now I can just close the controller and turn the computer off if I want to.

Remember that the machine still needs power, and depending on how you have your machine set up, part of it might be being powered by USB.  So if you turn the pc off, it might lose that power.  It might not! Because you might have a powered hub or something.  But If you have a power supply that plugs into your arduino board rather than your motorshield you will be ok to remove the usb entirely.

This works great for vector graphics where there’s thousands of little lines. Not such an issue for bitmap stuff, but still might be useful for bigger things.

Resizing vectors, saving config.

It’s like that film, with those flying dudes.

Ok, two exciting new functions in the latest controller release (v1.1.3).

  1. Vector scaling and moving.  Loaded SVGs can now be moved and resized using the same kind of controls as bitmaps, one to move, one to resize, so that’s nice and easy.  Still no way to “select” a particular area beyond changing the page size, and that’s not really what page size is for, so I need to do something about that.
    There is a slightly related issue about what happens to the lines that go off the edge of the page.  At the moment, if a path goes off the edge of the page and then comes back onto it then there’s a slightly unpredictable line between the exit and the reentry point.  That’s marked for fixing. 
    Another slightly related issue is that the machine will only draw a line segment if both ends are on the page.  This is ok for drawings that have lots of little lines, but if there is a long line that only a tiny bit hangs off the page, then the whole line will be missing.  Fixing that kind of issue is a little more than I was hoping to get into, but it’s a bit of a stinker so I probably will.
  2. Multiple config files.  The main config file is now called default.properties.txt.  This is intended to be used as an empty “untitled” document that will always be automatically loaded when the controller starts.  But when you start laying out your images and making modifications, you can now “save as” a new config file, that can be worked with from that point, and be reloaded at a later date.
    I haven’t had a very thorough test of this stuff, and I know that something a little odd happens when you change mmPerRev or stepsPerRev.  I still think it’s easiest to modify those settings by changing them directly in the txt file.

A word about testing and releasing.

When I’m putting in new features, or fixing issues, I do try to do some testing, but it’s often fairly rudimentary.  For issues like the multiple config files (above), while I know there are some things in it that don’t quite work, I’m still releasing that, because it doesn’t change the old behaviour.  You can still use the app like you always could.  If it required you to change lots of things, then I’d be a bit circumspect about letting it out.

For something like moving and resizing vectors, this is such a useful thing that it’s better that it’s out there and not working properly than it’s not available at all, at least, that’s my reasoning.  (And I think it is working properly, anyway!)  It might not be very proper development practice, in fact I know it isn’t, but I think the elite band of folk who choose to use this software would prefer to have something you can muddle through with rather than something that’s absolutely perfect but can’t do anything.  At least that’s what I’m looking for, ha!

As ever, new precompiled version available from the code downloads page and the source available from the head of the controller trunk.

Safer vectors

Have just been working on making vector drawing a bit safer, thanks to prompting from Matt.  Still no resize or zoom, but this drawing with 14,000 commands has just finished successfully.

Map drawing

This SVG was one that used to send the machine into a mad spinning fit, off searching for a coordinate it could never reach.  Well, now the machine will only attempt to draw to points that it believes fall within its own machine space, and it superstitiously avoids any 0 coordinate.  There are a couple of changes to the embedded (server, firmware, whatever you like to call it) software to support that, and there is a slightly new acceleration behaviour for C17 (draw straight line) commands.  This essentially turns off acceleration for C17.  Because the line is chopped into such small pieces with C17, it doesn’t work anyway, so doing without makes for a much faster line, at the expense of noise, maybe a bit of wobble.  It’s a slightly harsher process.

Ok, so those are the updates to the machine code, not completely essential, but it can be found, as usual in the repository.

The controller has a couple of minor changes to support vector drawing, mainly that only vertices that fall on the page are sent to be drawn.  I know it makes sense to have the select area tool able to select the lines to draw, but that’s all a bit tied up with bitmaps and regenerating the density maps to do that easily at the moment.  In future though, definitely, along with svg resizing and moving.

The controller now has a separate window to select the pixel rendering options, and choose which corner you want the drawing to start from.

The other change in the controller is that it now supports the new Arduino MEGA firmware, and the few new features that are available in that (namely saving to / drawing from SD cards).  It recognises what kind of board you have plugged in because the mega version broadcasts its nature in its READY shoutout.  Shouldn’t make any difference to anyone because standard behaviour is the same.  I’ve noticed an oddity with the way the control panel wraps when it detects the machine has changed to a different type, but nothing problematic.

Available from the repo, or the downloads section, v1.1.2.