kaioa.com

9 kinds of vision

This is an extension for Inkscape which simulates 9 different types of vision. Again it's a color effect and therefore it can be found over at Effects->Color->Color Blindness after installation.

Supported modes:

• normal trichromatic color vision
• protanopia red-green blindness (no red cones)
• deutanopia red-green blindness (no green cones)
• tritanopia blue-yellow blindness (no blue cones)
• typical achromatopsia (no cones; rod monochromat)
• protanomaly (anomalous red cones)
• deutanomaly (anomalous green cones)
• tritanomaly (anomalous blue cones)

A low poly spaceship

Without net access there wasn't much to do. However, modeling was one of the few things I actually could do. Fortunately I had some recent version of Wings3D installed. A few futile attempts later I got something that looked alright. Semi-satisfied with my low poly (52 polygons, 104 edges, 54 vertices) spaceship I went ahead texturing it with Inkscape.

Since the intended rendering size is rather small there isn't a need for fine details. I also wanted to try some bold semi-futuristic look with a touch of military blandness. Using vectors seemed like the most natural choice. Hard vector edges also fit the flat shaded rendering a lot better.

Before I could start with the texturing I had to do the UV mapping first. UV mapping is a bit annoying in Wings3D, but it's alright for simple models. If you aren't familiar with the term: it's about which part of the texture goes where on the model.

Inkscape 0.46 is finally out of the door and there are builds for all platforms (well, the important ones) available. Unfortunately I wasn't able to get this little executable into the Win32 builds. If you've read my previous posts you might have an idea what it's all about.

In a nutshell it's a tiny console application, which spawns Inkscape (with the specified arguments) and captures its stdout (default output) and stderr (default error output) streams and redirects it to this console. It also does the same with stdin for good measure. It's sole purpose is direct command line interaction (and determining which actions trigger GTK warnings). If you want to spawn Inkscape from other programs/scripts use inkscape.exe instead.

So, with this little application we get something that behaves like a console build of Inkscape, which means that we actually get some feedback if we're using some command line switches. All that for a mere 21kb. For comparison: a separate Inkscape build would have added another 12.5mb.

Sun's MLVM aka "The Da Vinci Machine" caters for the needs of many compiled and interpreted languages. Since Sun already gathered a lot of expertise with the JVM it's going to be a sure hit. Reliability and performance will be equally excellent without a doubt. And of course it will also run Java.

Yesterday during his keynote at Sun Tech Days James Gosling announced that they hired Ted Leung (a long-time Python developer from OSAF) and Frank Wierzbicki (the lead implementer of the Jython project). Both are going to work full-time on Jython - an implementation of Python written in 100% pure Java.

It can be also done without Python. D'oh. Here is the batch file:

@ECHO OFF
inkscape %* 2>&1>"%TEMP%.\console.txt"
TYPE "%TEMP%.\console.txt"
DEL "%TEMP%.\console.txt"

But it's sorta annoying that it needs a temporary file.

inkscape -e image.png drawing.svg 2>&1|more

For example works fine, but it adds that page feeding stuff. Using sort instead of more kind of works, but the output is of course sorted. Hum. I can't really believe that there isn't something which takes stdin and outputs it to stdout. Neither echo nor redirecting to con work. Did I overlook something obvious?

The best I could come up with is this batch:

@FOR /F "delims=" %%? IN ('inkscape %* 2^>^&1') DO @ECHO.%%?

It works as intended, but eats empty lines.

Update: See inkscapec.exe - A Command Line Wrapper for Win32 for a better solution.

On Windows you won't have much fun with Inkscape's command line options. They do work just fine, but you won't see any feedback messages. While the messages are written to stdout and stderr, these streams aren't connected to anything. And all that eventually useful information is flushed down the virtual toilet.

(If you aren't interested in the details skip over to InkCL.bat usage and the zip package.)

That's just how things are with Windows - either spawn a cmd.exe window or get nothing. Getting some extra cmd window each time you use Inkscape would be a tad annoying, therefore the other option was chosen. Java solves it with two executables: java.exe and javaw.exe (where the former spawns a cmd window and the latter doesn't).

In Java's case they are tiny wrappers. Inkscape is a lot bigger tho, therefore that wouldn't be the smartest thing to do. ~6.7mb just for better command line support? Naaah. However, a tiny separate wrapper program, which just spawns Inkscape.exe as child process would work fine. Ultimately it's the best option and most likely the one we'll pick.

As a temporary solution for the time being you can use the following Python program. It hands the command line arguments over to Inkscape and grabs the stdout and stderr streams and prints 'em on screen.

Introduction

SVGs can be optimized for three different things. File size, rendering speed, and editing. For the most part you want to optimize for editing - especially with complex drawings. Towards the end you may want to lean toward the 2 other goals tho.

Optimizing for rendering speed is very interesting for devices with limited capabilities such as cellphones or PDAs. Things to keep an eye on are node counts, overdraw, clones, clipping, masking, gradients, and even simple stuff such as strokes. Nokia published some pretty decent guide (PDF) on this topic.

Optimizing for size shares a few aspects of the speed optimization. Keep the node count as low as possible, combine paths where possible... that kind of thing. However, you completely ignore overdraw, and you use clones/clipping/masking/stroke/gradients all over the place. It's certainly lot more entertaining than speed optimizations and it also won't affect editing speed that much. That's why I'll experiment with that.

I almost forgot to fix this. There was some silly bug, which caused the evaluated new color values to overwrite the old ones. E.g. if your red function changed the red channel and if you use the red channel in the green or blue function, the calculation was way off.

Well, this is fixed now. Finally you can do stuff like custom grayscale functions. For example if you don't like the NTSC/PAL scheme, which is used by Effects->Color->Grayscale, you can now use a different one. For the ITU-R Recommendation BT.709 conversion you would use the following line for all three channels:

0.2125 * r + 0.7154 * g + 0.0721 * b

For comparison the NTSC/PAL one looks like this:

0.299 * r + 0.587 * g + 0.114 * b

Feel free to try your own weights. You can also try slightly heavier weights in the red channel and a tad heavier weights in the green channel for sepia-ish pseudo grayscale. Or something completely different. Since the calculated values are clamped (0 to 255), there won't be any problems.

Thanks to Johan Engelen's bug fixing kung fu it's now possible to export ridiculous huge PNGs via command line. Thanks heaps mate! :)

I just exported some SVG at 524288x256 pixels. That's 512mb of raw data and it only took 45 seconds! That's really plain awesome.

The main reason why I wanted it so badly (sorry for the nagging Johan) is because wide images are faster to export than tall ones (see my previous post), and because slicing it up in only one direction simplifies the code of my yet to be released multi threaded export extension.

Inkscape 0.46 is going to be so sweet.

People often complained that their PNG export took bloody ages. At high resolutions and with some blur it sometimes took over 10 hours. That's really not nice. However, things improved a lot during the last few months, and whenever the issue arose I pointed people at the unstable SVN builds.

It was apparently noticeable faster, but I wasn't sure how much exactly, and there were no facts to backup my claims. That's why I decided to do some benchmarks on my own. I already had the framework for this from my multi core export extension tests. So, this was pretty easy to do.

The test machine was a AMD 64 X2 4200+ with 2GB of RAM.

With Blur

Used SVG: exp5.svg

Without Blur

Used SVG: exp5nb.svg