Knitting Pattern Conversion

conversion_273cdef7c-3747-11e6-8ece-a573d396521917-diag

We can convert knitting patterns to svg (middle) which proves the concept but is still a different from the original (right)

Our goal is to create a knit-work exchange format. This includes the conversion to a scematic view of the knittting pattern as svg – to make it endlessly scalable and allow conversions to png, pdf and paper.

This week we ended the prototype of the SVG conversion. The positions are a bit off and instructions are placed above eachother. Most of the work is done.

We are also able to load and save knitting patterns a png files.

(1)a34e6d2c-372d-11e6-9bbd-71c846ead7f9 (2)f6a6bf82-372e-11e6-9467-8bab0e07c099

(3)39e5a556-380b-11e6-8999-726fea9b6078

We loaded them (1), converted them to a knitting pattern and then saved them again as png (2). This way we path our way towards using the ayab software and actually knitting the pattern. Also we can convert the knitting pattern to an svg consisting all of knit instructions (3). Here is the code for it in version 0.0.8.

>>> import knittingpattern
>>> from knittingpattern.convert.image_to_knittingpattern import *
>>> convert_image_to_knitting_pattern.path("head-band.png").temporary_path(".json")
"head-band.json"
>>> k = knittingpattern.load_from_path("head-band.json")
>>> k.to_svg(10).temporary_path(".svg")
"head-band.svg"

Here you can see a proof of concept video:

 

A look into the knitting pattern format

We are currently working on a format that allows to exchange instructions for knitting independent of how it is going to be knit: by a machine like Brother, Pfaff, or by hand.

For this to be possible we need the format to be as general as possible and have no ties to a specific form of knitting. At some point the transition to a format specifically designed for a certain machine is necessary. However, we believe that it is possible to have a format so general that instructions for all types of machines and for hand knitting could be generated from it.

We have decided to use JSON as the language to describe the format, because it is machine readable and human readable at the same time.
The structure of our format follows the rows in knitting.

Our first thought was about creating a format that would describe how meshes are connected and how the thread travels. This would allow for great flexibility and it should be possible to represent everything like this. However, we have decided against it, because we think this format would be quite complicated (different orientations and twists of meshes possible, different threads for multiple colors…) and would get quite big very quickly, because of all the different properties for each mesh and because of all the meshes. Furthermore, and this point is probably more important, knitters do not think this way. If we had a format like that, it would not be easy to understand what was happening for human beings.

Whenever I knit by hand, I never think about how all the meshes are connected by this single thread I am using. I always think about which operations I am performing when knitting in each row. Instructions for creating patterns in knitting are also written this way. They give the knitter a set of knitting instructions to do and possibly repeat. We have concluded, that most knitters think in knitting operations performed rather than connections between meshes.

17-diag

Knitting instructions from Garnstudio’s Café.

Therefore we have decided to base our format on knitting instructions/operations. The most common instructions probably are: knit, purl, cast on, bind off, knit two together, yarn over. Of course for increases and decreases there are many different operations which work in a similar way but have slight differences (e.g. skp, k2tog).
Since in knitting many things are possible and it is unlikely that we ever manage to create a complete list of all the possible operations you can perform in knitting we have decided to have a very open format, that allows the definition of new instructions.

Instructions are also defined in JSON format. Here is an example, the “k2tog” instruction:

[
    {
        "type" : "k2tog",
        "title" : {
            "en-en" : "Knit 2 Together"
        },
        "number of consumed meshes" : 2,
        "description" : {
            "wikipedia" : {
                "en-en" : "https://en.wikipedia.org/wiki/Knitting_abbreviations#Types_of_knitting_abbreviations"
            },
            "text" : {
                "en-en" : "Knit two stitches together, as if they were one stitch."
            }
        }
    }
]

 

Knitting patterns consist of multiple rows, which consist of multiple instructions. Furthermore we want to define the connections between rows. This is important, so we can express gaps or slits which are multiple rows long. For example when knitting pants the two legs will be separate. They will be knit separately and their combined width will be increased in comparison to the width of the hip.
Here is an example for a pattern which specifies a cast on in the first row, then a row where all stitches are knit, then the last row is bound off.

{
  "type" : "knitting pattern",
  "version" : "0.1",
  "comment" : {
    "content" : "cast on and bind off",
    "type" : "markdown"
    },
  "patterns" : [
    {
      "id" : "knit",
      "name" : "cobo",
      "rows" : [
        {
          "id" : 1,
          "instructions" : [
            {"id": "1.0", "type": "co"},
            {"id": "1.1", "type": "co"},
            {"id": "1.2", "type": "co"},
            {"id": "1.3", "type": "co"}
          ]
        },
        {
          "id" : 2,
          "instructions" : [
            {"id": "2.0"},
            {"id": "2.1"},
            {"id": "2.2"},
            {"id": "2.3"}
          ]
        },
        {
          "id" : 3,
          "instructions" : [
            {"id": "3.0", "type": "bo"},
            {"id": "3.1", "type": "bo"},
            {"id": "3.2", "type": "bo"},
            {"id": "3.3", "type": "bo"}
          ]
        }
      ],
      "connections" : [
        {
          "from" : {
            "id" : 1
          }, 
          "to" : {
            "id" : 2
          }
        },
        {
          "from" : {
            "id" : 2
          }, 
          "to" : {
            "id" : 3
          }
        }
      ]
    }
  ]
}

Connections are defined “from” one row “to” another.  The ids identify the rows. The optional attribute start defines the mesh where the connection starts. If start is not defined, the first mesh of the row is assumed. When indexing the list of meshes in a row the first index is 1. The optional attribute “meshes” describes how many meshes will be connected, starting from the mesh defined in “start”.

The resulting parsed Python object structure looks like this:

row model

The Python object structure for working with the parsed knitting pattern.

Each row has a list of instructions. Each instruction produces a number of meshes and consumes a number of meshes. These meshes are also the meshes that are consumed/produced by the rows.

 

Towards a unified digital aproach to knitting

Our idea is to create a knitting library for a format that allows conversion of knitting projects, patterns and tutorials. Usually, communities will only focus on the knitting format for their machines. Our approach should be different and be able to support any knitting communities efforts.

Here is our strategy to achieve this:

  • We connect to different communities to get a broader view on what their needs are.
  • Our knitting format is based on knitting instructions like knit, purl, yarn over, skp. We found a comprehensive list on Wikipedia.

Other Communities

From time to time we meet with other people who also knit and could use our software.

First, we met with Viktoria from ETIB Berlin. She taught us a lot about knitting, how she does it, that almost everything could be created from one peace with the machine. Also, that AYAB is used for lace patterns. We saw examples where she let meshes fall so that larger holes were created. Our goal is to support laces in the file format.  Color patterns should be possible across sewing edges.

We are also in touch with Valentina Project. With their software we would be able to connect to yet another community and use their sewing patterns for custom-fit clothes.

We got in touch with Kniterate. They and we share a lot of goals. Because they create a startup, they are very cautious what they release. They focus on their open-source knitting machine first and later on the software. They already created an editor much like we imagined ours to be, but as a web application. A way of collaboration could be that we understand their file format and see how we can support it.

Only talking about our GSoC project is worth it as other people may have seen alike at Maker Faires and other hacky places. We have the chance to bring communities and efforts together.

Knitting Format

A universal knitting format has many concerns:

  • Languages of users differ
  • It should be possible to knit by hand
  • Mesh sizes and wool differ
  • Different knitting machines with different abilities
  • A knitting format for exchange is never complete. A knitting format for machines must be complete.

In contrast to a knitting format for a automatic machine, it is possible, to have machines operate in semi-automatic modes or just to knit by hand. In both cases, meshes could be changed in a way that was never foreseen. This is why we did not base it on meshes and mesh types but rather on instructions – closer to the mental model of the knitters who perform instructions with their hand.

Some of the instructions are understood by the machines, some could be adapted a bit so the machine can do it automatically or faster and some are still necessary to be done by hand. We created a Python module for that, “knittingpattern“. We work on it in a test-driven way.

 

Functionality of KnitWeb Application

Hi Everyone,

In this blog post I will show what are the functionalities implemented in KnitWeb application. First of all let us look into why there is a web application to get a knitting job done. It’s simple. Going for a web application is the best way to acheive platform independence among all the knit app firmware. So the if the hardware level functionality can be abstracted out to a separate library then the web application can use that and provide a common interface to all different knitting application platforms. This is what we have been doing in this GSoC, to provide a common platform and interface for all open source knit app solutions.

So let’s look at the KnitWeb Functionality. KnitWeb consists of two major components, KnitWeb front end and KnitWeb back end logic. KnitWeb front end consists of a pattern editor for edit loaded patterns to workspace, Simulator for show knitting progress and a drawing tool for draw a pattern from scratch. Therefore Pattern editor component is used for easily edit the pattern before send for knitting.

Knitting Simulator is used for render knitting progress to the user with a enhanced user experience. It also consists of main controls for knitting job which user can start/pause/stop a job while knitting.

KnitWeb Drawing tool is used to generate a pattern from a scratch. It provides basic drawing tools including pencil, line, basic shapes and color palette. It also used for replicate a pattern from a existing pattern or a image. Then user can export it to the workspace to continue knitting job.

Pattern Editor Usage

Pattern editor gives following functionality to the users

  • Loads the pattern according to number of rows and columns(stitches) to the editor. Pattern is pixelated as the defined number of rows and columns.

Screenshot from 2015-08-25 08:42:41

  • Select pattern area using square/free hand tools. Then edit colour values of selected area.

Screenshot from 2015-08-25 08:57:28Screenshot from 2015-08-25 08:59:53

  • Show colour regions of selected area/whole pattern and easily edit their colour values.

Screenshot from 2015-08-25 09:08:03

  • Configure machine type and Available ports before creating a knit job. In this step knit web client is communicating with the knit lib server to get those information. After that user can click proceed knitting button to create a knit job.

Knitting Simulator Usage

Screenshot from 2015-08-25 12:14:40

  • Knitting simulator provides knitting progress to the user with enhanced user experience. Current knitting progress is shown to the user as above and also with a progress bar.
  • Knitting simulator window consists of other meta data input needed for configure knitting pattern(knitpat) file such as Start Line, Start Needle, Stop Needle, Number of colours used etc.

Screenshot from 2015-08-25 12:19:33

Drawing Tool

Screenshot from 2015-08-25 12:25:19

  • Drawing tool is used to generate a pattern from scratch or design patterns by replicating image or a texture.
  • After editing finished pattern can be exported to the workspace.

Apart from the above mentioned components edited patterns at the pattern editor can be downloaded as a image file. Also multi-language translation is added by @shiluka to the knit web interface. following is the translation for german language

.Screenshot from 2015-08-25 09:36:08

This sums up the most critical functionalities of knitweb application. I would like to continuously contribute to FashionTec as this inspired me to research and do things that I have not done before. :).

Also here is a little demo on the functionality of knit web. demo link

Thank You 🙂

Knitapps at the 7th Central American Free Software Congress ECSL 2015

On August, 9th, in San Pedro Sula, Honduras, I presented at the seventh Central American Free Software Congress a talk on Knitting Machines, Knitapps, Free Software and Free Manufacture.

DSCF5303

I had the opportunity to present on the main auditorium of Unitec, a private, technical university. The audience of the congress was compromised mostly of professionals and students from Central America. Local and National media also covered the event.

Continue reading Knitapps at the 7th Central American Free Software Congress ECSL 2015

Knitting machine abstractions for Knitlib

Hello, during the last weeks we have been working on Knitlib and Knitpat, a knitting machine control library and a standardized format that allows for exchange and storage of patterns.

In order to achieve a common platform for knitting machine development we have the need to abstract away implementation details that can difficult the generic usage of the lib, while keeping extensible and powerful control features. Among the most important abstractions developed for Knitlib is the Knitting Machine Finite State Machine, an abstract representation of the procedures needed to operate a knitting machine.

BaseKnittingPlugin
BaseKnittingPlugin, the basis of knitlib’s machine knitting controller plugins.

The architecture of Knitlib allows for easy integration of different knitting machine plugins for varied use cases, hardware, and software protocols. All functions of the plugin are non blocking except for .knit(), which is blocking due to the physical interaction needed in order to execute this command. To ease usage and to enable more versatile behaviour from the .knit() function, without limiting the interaction facilities needed for operation, the callback infrastructure allows for blocking and non-blocking callbacks from the Plugin to the machine operator (the Knitlib client), such as Information, Warnings, Error Notifications or Mechanical Required Actions (moving spools, switches, needles, etc). Callbacks abstract away the notification and interaction paradigms from the plugin, allowing for simpler behaviour, a more elegant design and ease of testing. Callbacks also allow for future plugins to not take care into implementing user interfaces, but to focus on functionality.

The pending remaining challenge is to standardize configuration options, flags and settings in order to allow for UI that respond to each plugin requirements and options, and to specify which features are supported on each machine plugin. Insofar, most of the standardization has been done on Knitpat, but some specifications such as physical resource assignation (Serial Ports, input streams, etc) are still to be implemented soon.

Thank you, and I hope this article helps you to understand the software architecture and design patterns of the implementation of Knitlib.

Regards,

Sebastian

Knitting Library to support numerous Knitting Machines

Hi everyone, I’m Shiluka Dharmasena, Computer Science and Engineering undergraduate from University of Moratuwa, Sri Lanka. Thanks very much for this great opportunity to get involves in FOSSASIA open source project and I’m keen to give my fullest contribution to the FOSSASIA.  For GSoC 2015, I am developing a library to support knitting machines. It’s great to work with FOSSASIA team under awesome mentors Mario Behling and Christian Obersteiner. This is the Initial suggestions for the project.

Library to support knitting machines

Basic abstraction of the library to create library as separate layers

  • Serial communication : open, configure, read and write to serial port
  • Machine definitions : machine initialization, load to machine, save from machine
  • Image handling functions : memory allocation, read image file, setter and getter for image pixels
  • File handling functions : read / write access
  • Common utility functions

Add dependencies for the library

There are several dependency libraries which ayab has such as pillow, pyserial, wsgiref, fysom and yapsy with relevant versions. These dependencies should be added to the library.

Functions for the library

For access hardware directly
* Identify existing libraries to interface with hardware
* Use libraries to deal with serial ports
* Ability to get all the functions via library (for an example functions in ayabControl.py and add more functions to support in more machines)
* Ability to send QT signals

Emulate file formats

* Create functions to emulate file format

Add Arduino support

Installation

Installation should be well documented in step by step. Additionally I suggest to add GUI based installation with usability improvements with standard installation procedures.

* Installation on Linux (32bit, 64bit)
* Prerequisites
* Setup
* Installation on Windows (32bit, 64bit)
* Prerequisites
* Setup

Tests on the library

Use a python test framework like unittest to test the python library. It supports test automation and aggregation of the tests into collection.

Documentation of the library

Documenting Class definitions, methods definitions and links to the given source codes.

Knitting Web App FrontEnd with Pattern Editor Knitting Simulator

Hi everyone, I am Sameera Gunarathne and I am a computer science undergraduate of University of Moratuwa, Sri Lanka. This is the first time I have applied for the GSoC and FossAsia and I am quite excited to  give my contribution to FashionTec as it’s a whole nice new experience that programming is applied with real world applications in fashion and technology paradigm. I have selected for developing a Graphical User Interface which runs as a web application which is intended to provide a common platform to give input for the knitting machine firmware.

As the first step I had to research on the existing knitting applications that are available online commercially and what they provide as features that still need to be included in open source knitting applications. I have looked into both knitting pattern design softwares and knitting machine embedded softwares including knitbird, EnvisioKnit ,Stoll knitting software, ShimaSeiki SDS One Knit. The most significant feature I have noticed is the feature rich pattern editor provided with the software. They provide features like loading patterns from different formats(jpeg, png,gif,pdf), transform patterns(crop,replicate etc) to create new patterns, drawing tools to create a pattern from scratch, Provide colour palette with available yarn carrier colours, Saving and loading the work done by the user in the application storage etc.

Therefore in this GSoC period I am developing the assigned Web User Interface with consisting of following components.

Web App FrontEnd

  • Work Space + Pattern Editor
  • Knitting Simulator
  • Project Manager

Web App Back End

  • Web Client Server component(REST Api to communicate with knitlib interface)
  • Request Handler for back end logic
Screenshot from 2015-06-02 09:37:09
Logical Architecture Diagram

Knitting Simulator is used to simulate the knitting process through the user interface while the knitting is going on. It will display the carriage details, current knitting progress and a graphical simulation of the current knitting position of the pattern with row details. Project Manager component is to save knitting works as projects and load them later as the user preference.

The selected technologies for the project implementations are mainly JavaScript(node js for back end and angular js for front end implementations), HTML & CSS (render static content). REST Api for communicating with knit lib interface will be implemented in node js. The offline usage of the app will be implemented using Electron Framework.

This project consists of 4 milestones and under the first milestone I am working on the pattern editor features. Currently I have implemented loading different types of patterns into the workspace and pixelate them according to the number of rows and stitches allowed for the knitting. Following tasks will completed end of this week.

  • Identifying individual pixel in the grid as a stitch and add operations such as change colour, size etc.
  • Adding pattern editor tools for selecting pattern area, colour picker, crop-cut-paste tools for pattern replicating.
Screenshot from 2015-06-05 11:41:15
Current Implementation of Pattern Editor

I hope this GSoC will be a fruitful one to spend with a successful implementation of the knit web app and looking forward to provide a competitive open source knitting software at the end of the development :).

 

 

 

Simpler Control of Knitting Machines with knitting machine abstraction library and JSON based knitting file format

Hello everyone, my name is Sebastian Oliva. I am a developer from Guatemala and part of the team of students currently in Google Summer of Code ’15 working on Fashiontec. During last year’s GSoC I built a GUI interface for the AYAB project, allowing for easier control for knitting machines supported by AYAB (Brother KH-930, KH-910).

When I started getting involved with Fashiontec and FOSSASIA last year I was not aware of the large community related to textile and open fabrication projects. Since then, I have found many projects that have focused on different techniques and have had different approaches to fabrication and in particular the operation of knitting machines. Such as projects that emulate existing functionality of an existing machine, projects that entirely replace or enhance the machine’s inner workings, and projects that build machines from scratch.

Currently I am working on developing a knitting machine abstraction library and JSON based knitting file format that can enable the use of a single API to control a varied number of knitting machines. A knitting machine library allows us to create even more advanced software to control and operate machines, while a standardized and open format for knitting patterns allows us to create pattern collections such as the common pattern books usually shared by knitting communities, as well as enabling pattern editors and ecosystem.

Currently I am:

  • Working on designing and implementing Knitlib’s API design.
  • Writing tests for Knitlib’s desired behaviour.
  • Starting work on defining Knitpat, the open knitting file format.

I hope that this year’s GSoC brings a lot of advances to the machine knitting community, and I am happy to be a part of it.