Open t0mpr1c3 opened 4 years ago
t0mpr1c3
commented
4 years ago The closest thing that I can think of to a universal open source knitting pattern specification is a Japanese chart. That would be my starting point, I think. It seems to me that machine knitting formats are stuck in the 1980s: poorly documented binary formats designed for very low power computing.
t0mpr1c3
commented
4 years ago Perhaps there is something useful here. Looks like a JSON based representation of knitting patterns that can be dumped to PNG for export to AYAB. https://pypi.org/project/knittingpattern/
dl1com
commented
4 years ago Perhaps there is something useful here. Looks like a JSON based representation of knitting patterns that can be dumped to PNG for export to AYAB. https://pypi.org/project/knittingpattern/
This project was developed back in the days when AYAB participated as GSoC project (https://github.com/fossasia/knittingpattern). We started implementation of a successor for the AYAB software and @kirstin and @niccokunzmann spent a lot of effort on specification of a sustainable format for knitting patterns - but unfortunately it did not take off. It would definitely worth to check if the assumptions which where made back then are still applicable and pick up where we left.
(Just to be complete: Here are the other to parts of software which were developed back then: https://github.com/fossasia/kniteditor and https://github.com/fossasia/knitlib)
t0mpr1c3
commented
4 years ago The pattern specification looks to be completely unconstrained. This seems like an overreach -- too hard to implement. I know there is software out there that can convert between line-by-line knitting instructions and Japanese chart. I would have thought that is a good place to start. But perhaps there is something useful that can be salvaged. I will have a closer look.
t0mpr1c3
commented
4 years ago It looks like a good deal of thought has gone into it. There are some examples but the documentation was too brief for me to make sense of them.
t0mpr1c3
commented
4 years ago I had another look at the fossasia project last night. It is sophisticated, but it is not a good fit with AYAB. Basically it is overkill. We don't need something that can represent an arbitrary knitting pattern, because there are lots of things hand knitters might want to do that are completely impracticable on a machine. (For example, entrelac. A large proportion of stitches would involve hand manipulation.)
Conversely, there are things that machine knitters need to know when knitting a pattern that are irrelevant for hand knitters. So it is OK for us to use a "language" that is specific to knitting machines, and does not encompass everything that hand knitters can do.
So we don't want fossasia, but what do we need? First of all, we need to recognize that when we install an AYAB shield we pull out the brain of the knitting machine first. So any kind of knitting project that we want to use AYAB for, we might have to replicate what a knitting machine can usually do. We don't have to recreate every single capability, but we should cover the main use cases.
Secondly, people have existing patterns and design software, so the internal representation needs to be flexible enough to allow conversion from the most common machine knitting pattern formats, most notably Designaknit and Brother. AYAB is not design software, so it must be interoperable with design software.
Third, the language should support the operation of the main electronic accessories that these machines use, such as ribbers, yarn changers, servo motors, garter carriages, and so on, in order to facilitate automation. Even if AYAB does not support all of these peripherals at the moment, we should at least consider which ones are most useful.
Fourth, machine knitting involves plenty of interaction between the user and the machine, and it would be extremely useful for the AYAB to be able to offer prompts to the user to carry out certain tasks. So the language needs to be able to mark important features of the pattern where user input may be required. These might include carriage settings, changes of carriage, yarn changes, hand-manipulated stitches, and so on.
Mostly this is obvious stuff but from a knitting point of view I think these considerations boil down to two main questions:
My suggested answers are: 1. As many as possible. 2. None of them.
For AYAB to properly support knitting lace requires that the pattern specify for each row whether the knit carriage or lace carriage should be used. AYAB should prompt the user, and report an error message if the hall effect sensors show that the wrong carriage was used.
The Silverknit Utility manual shows visually what is required to translate lace patterns into machine instructions. There is also a chapter in Haffenden, V. "Translating between hand and machine knitting." on Google Books or Scribd.
hamsterwoede
commented
4 years ago Hi, I've been a lurker on the Ayab discussions, because I don't use Ayab that much anymore (I usually knit on Passap), but I think the knitout specification might be useful.
It's developed for coding for industrial knitting machines (that can have several carriages moving at the same time and do 'partial knits'). The only problem is that it's quite low level and and only useful for what the needles do, which is obviously not the same as the information sent to the carriage. But I think it could also be very useful for simulation purposes, like calculating possible dropped stitches or when you really have too many tucks (and thus probably too much yarn) on a single needle ;-)
Also it's missing turning the yarn (or purl) in it's specification which isn't possible on industrial machines (which I believe the garter carriage can do). But it might still be interesting.
In Passap e6000 terminology we use the term 'techniques' to describe:
For me that works quite nicely (although it was a pain in the ($*#& to learn all the '90s computer programmer acronyms that are shown on the tiny display :-)
The main disadvantage (especially to experienced knitters) is that some of the "techniques" are very basic, and don't give you insight in to what you're doing. But I see that as the equivalent of 'plugins' or 'filters' being bad. I don't hate them, but everybody should be free not to use them. Although I do admit to having to loop up the most basic cast ons, because it's easier to just follow the computer :-)
But I think 'parsing' through the first two step could be useful to describe 'higher level' abstractions, such as the Heart of Pluto method.
To give an example:
Technique 179 is 2 color jacquard (knit/tuck), but only on the front bed.
Technique 180 is exactly the same on the front bed, but adds user instructions to setup alternating pushers and set the right buttons on the carriage (to describe a mechanical way to do birdseye) for the back bed (or ribber as I believe Brother users call it).
And then there are like 5 more variations on this same theme, all with different names. (knit all stitches on ribber, knit every other, etc. etc.)
I can also recommend looking in to Journal Six which has been open source for about a year now. Although it feels a bit dated and the 'book'-analogy isn't that practical, it has some very well thought out ideas.
https://github.com/bikibird/JournalSixSource
I hope it's of any help/understandable. I've tried to not make this too long a message, so I'm never sure if I'm explaining things that are obvious, or leaving things out that are necessary to understand my way of thinking ;-)
t0mpr1c3
commented
4 years ago Thanks for those insights. It's clear that there are multiple levels at which patterns can be described, corresponding roughly to
For Brother machines, these are respectively the domain of the Knitleader, punchcard/software designs, and hardware.
What I am mostly talking about here is level 2. But really, we need different formats or data classes for these levels of pattern data.
These data classes are needed if we are to vary the granularity of what is displayed. Currently AYAB only displays the pattern, and at a fixed screen size. But there are times when the user needs to know lower level information e.g. when multiple carriage passes are required to knit each row and the user must switch yarn (for colourwork) or carriage (for lace) between passes. And for large pieces, it would be advantageous to be able to zoom out for more of a bird's eye view, or zoom in to see the pattern detail.
These display issues have been raised several times in different ways. To my mind sorting out the data format(s) is a necessary first step towards the solution. https://github.com/AllYarnsAreBeautiful/ayab-desktop/issues/250 https://github.com/AllYarnsAreBeautiful/ayab-desktop/issues/242 https://github.com/AllYarnsAreBeautiful/ayab-desktop/issues/229 https://github.com/AllYarnsAreBeautiful/ayab-desktop/issues/210 https://github.com/AllYarnsAreBeautiful/ayab-desktop/issues/226
hamsterwoede
commented
4 years ago I'm not sure about 1 (since I've never used a knit leader), but if it's close to how the form computer works then you should be able to encode it into a (separate)black and white picture and get instructions per row out of it when to increase/decrease or use short rowing for shaping. Also very practical if you want to control a motor.
On 2 and 3: I would suggest using sideloading metadata (xml, json, or whatever you prefer) for particular 'projects' in which you can add information per 'row' which you can show at the start (or the end) of a row (afaik nobody will ever do anything mid row, but I could be wrong). I really would not suggest using the metadata within an image file. That makes it harder to reuse for other projects.
The problem with images in knitting is that if you're doing 2 color jacquard then the data actually looks a bit like the final knit fabric. That would also be true for a punchcard. But there are lots of patterns that don't resemble the final product. Modern user interfaces being what they are (wysiwig), a lot people who are new to machine knitting might expect the image to be a representation of the knit fabric, but it's not. Although it might be possible to see what the final fabric might look like, it would probably be well outside of the scope of Ayab I assume :-D
Longtime machine knitters however, have grown accustomed to certain 'quirks' and have different expectations. Some of then really dated. So I wouldn't implement #250 as it worked originally, but create a (reusable) format that you can use on different projects. It probably would be wise to add something like repeat every X rows for certain types of instructions (yarn change for instance), or a 'create beep' functionality but I think it would be easier to let the users figure that out for themselves.
There will always be use cases where you're going to rub against the limitations. A good case would be knitting a sock. There is no way to represent in 2D the way you create a heel by doing short rows unless you build a complete sock interface. But I can imagine an 'image' that programs those short rows for you. I don't even need to know what it is (although I'd probably still like to know what I still have to knit / where I am).
Or if somebody wants to do 6 color knitting on a four color machine by changing yarn colors half way. I'd say let the user figure that out for themselves, and make it easy to share.
My personal preference is that for every new project I start I write down the yarn thickness, yarn tension, tension on the carriage(s), measurement of a 20x20 sample, those kind of things, but also how many times I have to move the carriage before I knit one row (especially important with 4 color knitting). Now I'm not saying all of that should be programmed into ayab. But if I could add that as one big text chunk at any row (or before the first row/setup), then I wouldn't be unhappy.
So to be concrete: a few fields come to mind
I have been working in usability for about 18 years, and only been (machine) knitting for about two years now. But I've learnded that machine knitters are one diverse group, with a lot of different attitudes to how a knitting machine should work :-D
Anyway: using metadata would basically only create user feedback, it's not like the machine can tell the difference in most cases ;-)
Again I hope it helps. If you need me to mockup certain interface problems let me know.
t0mpr1c3
commented
4 years ago There are certainly advantages of being able to specify size and shape (level 1) but in my opinion it is not essential and we can leave it as a potential future feature.
XML would be fine as a file format. The main advantage is that it is easy to extend, so you can add features as you code them and retain backwards compatibility.
I believe that SilverKnit Utility, which does pretty much what AYAB aims at doing, uses an internal representation similar to the decoded version of a Designaknit .STP file. .STP files are capable of encoding both fair isle and lace patterns. There is a width, a height, a matrix of bytes each encoding a colour, a vector of colours referenced in the matrix (id, symbol, RGB, name) and an optional matrix of bytes each encoding a stitch type. I don't know how the stitch types are represented. But I would suggest that you don't need a whole lot more than that.
Working from that pattern, and knowing a few additional pieces of information like what equipment you are using, it should be possible to work up a set of machine instructions automatically. It should not be necessary to annotate each row of the pattern. But it might be desirable to be able to annotate certain actions, like picking up a row of stitches, that can't be specified in the usual way.
Adrienne200
commented
4 years ago If you're all agreed that a change of underlying format is a good thing then cool, go for it. I may have a few thoughts to add to the discussion but mostly I'll stay out of the way until after it's coded. But how big of a rewrite are you proposing?
My thoughts for a 1.0 release were more modest; no fundamental design changes, just get what we already have working as intended, and as close as reasonably possible to feature-parity with the original Brother design.
My two must-fix issues:
I could go on, I'm making a list. But I've now brought the discussion outside the scope of this particular issue. Chris, wasn't there a forum page last time for general discussion about the project? Where was that, should we revive it?
t0mpr1c3
commented
4 years ago The data format forms the basis for how the pattern is used and displayed, so the sooner it gets fixed the less work it is. Speaking for myself, I don't think it needs to be a very big change: I favour the simplest format that can get the job done. Actually making the changes won't take very long. The slow part is reaching agreement on what changes to make :)
The discussion is topical because I recently asked Chris what I should take a look at next, and he suggested this issue. I'd be happy to take a look at #161 in the meantime.
dl1com
commented
4 years ago offtopic First of all: I think it's great how people are gathering again to discuss the future development of the project, even after some time of standstill. Thank's a lot for all your contributions! ❤️
My thoughts for a 1.0 release were more modest; no fundamental design changes, just get what we already have working as intended, and as close as reasonably possible to feature-parity with the original Brother design.
I fully agree. The points you mentioned are very basic requirements I personally have for a 1.0, also. But additional requirements from me: to make AYAB future-proof (improve the knitting pattern format) and more accessible for contributors (do code-refactoring and add unit tests). Personally, I have no deadline to release 1.0, it will be "done when it's done", and this means the aforementioned requirements are met. @Adrienne200 feel free to assign issues you want to be handled in 1.0 to the Milestone "1.0.0", you already should have to permissions to do this. /offtopic
On the topic of a knitting pattern format:
As far as I understood correctly, @t0mpr1c3 mentioned that the information about the separate colors and the stitch types are stored in separate matrices inside the STP format. While this is easy to parse, I think it's difficult to create without a dedicated editor. We do not really have any requirement to store the information super-efficient, we can focus on manageability for the user.
I like the idea of a non-binary, human readable/understandable format for the instructions. So we might end up with two separate files: The pattern image (png, ...) containing pattern and color information and a separate file containing general information and instructions. This way, users can still work on their patterns with gimp/paint.net/..., but can also alter the instructions with a simple text editor.
If we supply a pattern image only, the behavior is no different to the current situation (besides some improvements for multi-color handling - different topic) - so we are backwards-compatible and an instructions file is not mandatory. But if the additional instructions file is available, it is used to supply the information about manual interaction, alarms, etc.. We could either look for an instructions file with the same filename (pattern01.xml matches with pattern01.png) or even allow to supply a "container" (e.g. zip file containing pattern and instructions file). Unregularly shaped patterns could also be handled with the instructions file (the image file is rectangular, but the desired line widths can be annotated per line in the instructions file).
To have low barriers for working on the instructions (as we currently have no pattern editor for doing this), we should take care that the file format is easy to edit with a text editor. I don't know if XML is appropriate for manual editing, JSON might be an alternative - we'll have to evaluate that.
So far for the pattern, the colors and the instructions. Still, as far as I understood, we have to find a way to annotate stitch types. Either we can also add this information in the instructions file also (question: is the stitch type information relevant per line or per stitch?) or there could be an additional image file, which describes different stitch types with different pixel colors (pattern image, stitch type image, instructions file).
I'd be happy to take a look at #161 in the meantime.
Would be awesome! 🎉
t0mpr1c3
commented
4 years ago What Chris said -- thanks everybody for getting together for this discussion. There are related topics under consideration here and I think it would be productive to deal with them separately. These are my own personal and highly opinionated summaries of where we are at the moment.
As far as I see it, the most urgent task is to reform the internal representation of the data from a colour image to something that also records the type of stitch at each location. This will not add functionality but is necessary to future-proof the software, especially if we wish to support the garter carriage to produce both knit and purl stitches, and will facilitate lace knitting. Since this is hidden from the user, we can change this as we see fit and adapt or update it as necessary. So it requires less discussion and is also the easiest task.
There is also the question of how to get this information into AYAB. The current method of uploading image files is great for colourwork, and tolerable for lace patterns taken from punchcard designs. The development version can upload the colour information from Designaknit files, but cannot decode the stitch information. It would be useful to be able to upload Brother .BPT or .BPM files. Progress will not be straightforward but could be made in a reasonable time frame by reverse engineering Silverknit or Img2Track software.
It would be also be wonderful to have a properly-documented, open-source, easily-editable knitting file format that is well-adapted to knitting machines. There doesn't seem to be anything suitable out there at the moment. The closest thing is the FOSSASIA project, but AFAIK there is no editing software and development has stalled. This is a difficult problem, a lot of work, and needs buy-in from the wider knitting community to avoid re-inventing the wheel. There is a large risk of wasted effort, because trying and getting halfway there would leave us no better off than where we are now.
I think you can see where I am going with this. :)
hamsterwoede
commented
4 years ago reform the internal representation of the data from a colour image to something that also records the type of stitch at each location.
I honestly am wondering what you mean by this. Could you give an example in what stitch information you would like to add per (pixel) location? To my knowledge the type of stitch the machine will make/do depends solely on the carriage your using and it's settings and that has only one bit of control (solenoid on/off per needle). If you want to know what stitch is produced then that's all the information you need, and that will never change mid-row as far as I know.
As I said, I'm kind of fond of Knitout which as a knitting machine file format ticks almost all my boxes, but as I said before it's quite low level and deals with individual needle manipulations, but it's a basis that could be used to calculate the produced stitches and much more. But that all feels like version 2.0 kinda problems.
t0mpr1c3
commented
4 years ago Could you give an example in what stitch information you would like to add per (pixel) location? To my knowledge the type of stitch the machine will make/do depends solely on the carriage your using and it's settings and that has only one bit of control (solenoid on/off per needle).
So, earlier in the discussion I mentioned that there is more than one level at which the pattern data can be represented. You are talking about the level at which the machine processes instructions where each row corresponds to a pass of the carriage and each unit of information (stitch) corresponds to the binary solenoid status.
In the previous post, I was talking about patterns at the level of the finished article, where each stitch could represent one of several different yarn colours. This is the WYSIWYG level that is currently displayed by the AYAB software for Fair Isle patterns. I am suggesting that this pattern description should also record the type of stitch, meaning knit, purl, yarn over, k2tog, s1k1psso, k3tog, or whatever.
At the moment AYAB conflates these levels somewhat, so that when you are knitting Fair Isle or Jacquard what you see on the screen is what the finished article is supposed to look like, but when you are knitting lace AYAB essentially displays instructions to the lace carriage.
In the Silverknit Utility, these 2 different levels of information are displayed as "Pattern" and "Knit Progress", respectively. I'd encourage you to have a look at the Silverknit Utility manual to see for yourself. I found the lace and Jacquard examples instructive.
hamsterwoede
commented
4 years ago Thank you, the Silverknit Utility examples clear things up a lot!
You are talking about the level at which the machine processes instructions where each row corresponds to a pass of the carriage and each unit of information (stitch) corresponds to the binary solenoid status.
That's not what I completely mean. Yes, it's true on a 'machine level' and practical for building visualisations 'bottom up', but more importantly it describes the stitches a knitting machine can "perform". There is some ambiguity in the way (machine) knitters speak about stitches (to put it mildly), and going from hand knitting to machine knitting isn't always easy.
To elaborate: Most people (hand knitters) will talk about stitches the way you do, using "knitspeak". As an example: K2tog is the instruction for a hand knitter to perform a certain task, in this case knit together. To describe that on the same level as Knitout:
Now most knitters wouldn't even think of that as two instructions. I'm just trying to make the point that there isn't that much of a difference in level.
Knitspeak is also used to talk about the produced stitches. The end result of the action. Now in the case of K2tog you can probably 'read' it in the fabric as a K2tog, but more importantly you can visualize as such. So I get why you would want to use that existing terminology to visualize the wysiwig style of knit simulation. It's everywhere in hand knitting, and describes the end result quite well, and it fits in the knitting culture. https://stitch-maps.com/ uses a very strict dialect of Knitspeak to create (lace) knitting charts to do this for knitting instructions.
But the problem of using hand knitting terminology as the source data is that you can easily create patterns that you just can't reproduce on a machine, or will take a lot of hand manipulation. For instance: If I come back to the example of K2tog: One way to do this is to transfer the yarn from one needle to the neighbouring needle by hand, and then transfer the rest of the yarn to the needle next to it to 'fill in the gap'. (Comparable to take the next two stitches in hand knitting). But you HAVE to do this before you knit the row. There is no way to do this 'mid-row'.
Now how does this work then in Silverknit Utility? Well before you start knitting you have to select a "Knitting Method": Fairisle, 2 color jacquard, 3 color jacquard, Right side facing and Wrong side facing which basically is description of what stitches the carriage produces. Lace patterns seem to be another mode that is closer to a knitting chart which basically show only transfers. But I'm not exactly sure about that.
So yes, Knitout is a little bit lower level compared to knitspeak, but more importantly: it's aimed at performing tasks a knitting machine can do: Transfer(with lace carriage, transfer carriage or by hand), knit, tuck and miss/(aka slip), keep track of bed positions (when knitting with a ribber), and with a G-carriage you can alternate knit and purl stitches.
Now I don't doubt that it could be done the way you say. It even looks like it was done that way in Stitch Designer (probably using a custom font) https://www.knititnow.com/path/images/115/Stitch%20Designer.pdf#page=143.
But if you go that route, then you'll have to work really hard on a way to make it knittable, and check for errors. There isn't anything principally wrong with that. But it seems much easier to me to generate the same 'preview', bottom up. If you select the settings to do 2 color jacquard, then you will always know that 0 is a slip, and 1 is a knit (or the other way around, I don't know by heart). If you're using a lace carriage it's probably something like 0 means do nothing, 1 means transfer to position. Somebody like Alessandrina (who is on the Facebook group) can probably tell exactly what does what in case you don't already know.
Added bonus: you won't have to check for errors (For instance you can't do a knit, a tuck and a slip in one row for instance (afaik I know). And don't get me started on purl stitches). Now it's no guarantee that your fabric will hold up, but at least you're sure that it's machine knittable.
Well that's my two cents. I hope it makes sense. I've tried to keep this relatively short, but apparently that's difficult.
Bit of a side note: If you want to deep dive into translating Knitspeak to knitting machines I can recommend this paper by Lea Albaugh et al. https://make4all.org/wp-content/uploads/2019/09/KnitDown_UIST_2019_access.pdf
t0mpr1c3
commented
4 years ago Thanks for the links and references. They are very helpful, and exactly the sort of thing I was hoping would be out there.
Knitspeak certainly looks well-documented. With a bit of luck there will be some open source software out there somewhere. But without that, I expect Knitspeak involves more abstraction than we can really handle.
Silverknit seems to provide fairly simple point-and-click methods using stitch charts as the input, which is about the level of sophistication I had in mind for AYAB. It does require a validation step because not all charts are knittable. Designaknit is also designed around grids.
In the words of the Knitpick authors, 'Knitting machines use proprietary low-level chart-based design systems that support customization of a few common patterns through a “wizard” interface. However, the user’s options are extremely limited, particularly with regards to texture.'
Fair comment, I suppose, but these limitations seem appropriate for AYAB for the next few years at least!
t0mpr1c3
commented
4 years ago The discussion was useful. Less fundamental issues have taken priority for the 1.0.0 release, but I will try to circle back after that is finished.
hamsterwoede
commented
3 years ago Just wanted to share that there is a ton of information on this subject in the book "translating between hand and machine knitting" by Vikki Haffenden. It's very Brother oriented.
t0mpr1c3
commented
2 years ago Looking at this again, I think it's pretty clear that multiple different levels of representation are needed for a knitting pattern in the general case, corresponding roughly to shape, pattern/texture, and machine instructions.
Knitout could be part of the mix as the last of those three. The Knitpick pipeline provides a road map of how to combine the three levels, and the autoknit code provides some details as to how it could be implemented.
As far as AYAB is concerned, for the time being I think we can ignore shape and stick to rectangles. I am certainly not against using Knitout as an output format, in fact I think this would be a great idea if AYAB is ever going to move beyond Brother machines. (I have been asked if AYAB can do what Silverduino can do, and emulate a PE-1: it can't, but perhaps we should think about that possibility for the future.)
The question still remains of what to use as the intermediate pattern representation. As Martin pointed out, both charts and knitspeak-type instruction sets (in effect, domain specific knitting languages) can produce patterns that can't be knitted on a machine. The solution adopted by the Knitpick pipeline is to translate Knitspeak into a representation called a Knitgraph, which must satisfy several different constraints in order to be knittable. Details are in the Knitpick paper, but it doesn't look like the code has been published: I might drop the authors a line and ask if I could have a look at some of it.
t0mpr1c3
commented
2 years ago I reached out to Jim McCann, and he gave me some pointers:
'The Knitgraph idea was not something my lab ever followed up on, but Megan has done follow-up work on knitting and may have continued to develop it, and you should get in touch with her about it: https://www.megan-hofmann.com/knitpick-compiler'
'We've really focused more on stitch meshes for visual editing:
'And on improving the tooling for knitout:
'Would also perhaps be worth looking at Alexedre Kaspar's work -- he's built on some of the ideas we developed way back in "Compiler for Machine Knitting" to develop a larger set of knitting primitives and some online editors (which output knitout code!) -- http://knitskel.csail.mit.edu/ and http://knitsketching.csail.mit.edu/'
t0mpr1c3
commented
2 years ago Converting knitout to some format usable by AYAB/Brother would require a backend similar to that implemented for Kniterate, in order to introduce the concept of carriage passes:
https://support.kniterate.com/hc/en-us/community/posts/360014765858/comments/360003994818
The backend will need to know what hardware is available because instructions for the same end result will differ, e.g. garter stitch could involve a garter bar; ribber plus transfer by hand; ribber plus transfer carriage; or garter carriage.
t0mpr1c3
commented
2 years ago Megan Hoffman has released the codebase for the knitspeak to knitout compiler.
Knitspeak is irrelevant for our purposes, but the intermediate graph format could be very useful and was not previously documented, as far as I know. https://github.com/mhofmann-uw/599-Knitting-Complete
t0mpr1c3
commented
2 years ago I do have some concerns about the Knitout format. The way that some operations are encoded is not particularly close to how they would be done on a Brother machine.
Transfer lace is a case in point. Using Knitout instructions, the transfer of one stitch to an adjacent needle is accomplished by transferring it to the back bed, adjusting the racking by 1 st, then transferring it back. Arbitrary lace patterns can be accomplished by these means, with certain constraints: see https://textiles-lab.github.io/posts/2018/02/07/lace-transfers/
The following file encodes a few lines of transfer lace. Lines encoding k1, k2tog, yo, k1 alternate with k4. It can be viewed by pasting the code into https://textiles-lab.github.io/knitout-live-visualizer/
;!knitout-2
;;Machine: SWG091N2
;;Gauge: 5
;;Width: 250
;;Carriers: 1 2 3 4 5 6 7 8 9 10
;;Position: Center
inhook 3 ;
tuck - f3 3 ; tuck loop -1,
tuck - f1 3 ; tuck loop -1,
tuck + f2 3 ; tuck loop -1, odd cast-on
tuck + f4 3 ; tuck loop -1,
releasehook 3 ;
knit - f4 3 ; knit loop -1, stabilize cast-on
knit - f3 3 ; knit loop -1,
knit - f2 3 ; knit loop -1,
knit - f1 3 ; knit loop -1,
knit + f1 3 ; knit loop 0, first row loops
knit + f2 3 ; knit loop 1,
knit + f3 3 ; knit loop 2,
knit + f4 3 ; knit loop 3,
xfer f2 b2 ;send loops to decrease to back
xfer f3 b3 ;
rack -1 ;rack to xfer b3 to f2
xfer b3 f2 ;stack decreases with offset -1
rack 0 ;rack to xfer b2 to f2
xfer b2 f2 ;stack decreases with offset 0
knit - f4 3 ; knit loop 4, Knit course 1
knit - f3 3 ; knit loop 5,
knit - f2 3 ; knit loop 6,
knit - f1 3 ; knit loop 7,
knit + f1 3 ; knit loop 8, Knit course 2
knit + f2 3 ; knit loop 9,
knit + f3 3 ; knit loop 10,
knit + f4 3 ; knit loop 11,
xfer f2 b2 ;send loops to decrease to back
xfer f3 b3 ;
rack -1 ;rack to xfer b3 to f2
xfer b3 f2 ;stack decreases with offset -1
rack 0 ;rack to xfer b2 to f2
xfer b2 f2 ;stack decreases with offset 0
knit - f4 3 ; knit loop 12, Knit course 3
knit - f3 3 ; knit loop 13,
knit - f2 3 ; knit loop 14,
knit - f1 3 ; knit loop 15,
outhook 3 ;
drop f1 ; Drop KnitGraph
drop f2 ;
drop f3 ;
drop f4 ;The equivalent knitgraph, however, seems like it could be useful. A graphical representation of a similar pattern looks like this:
The pattern is encoded in two types of objects: yarns and a knitgraph. Each yarn is a list of stitches in order: red arrows in the image indicate the direction of the yarn. Not surprisingly, colorwork requires multiple yarns. The knitgraph records details about loops that are pulled through other loops. Blue arrows on the image indicate that a loop is threaded through a loop in a successive course (row). "BtF" means that the loop is threaded through from back to front, i.e. knitwise.
Other examples can be viewed by executing https://github.com/mhofmann-uw/599-Knitting-Complete/blob/main/tests/test_simple_knitgraphs.py
hamsterwoede
commented
2 years ago I do have some concerns about the Knitout format. The way that some operations are encoded is not particularly close to how they would be done on a Brother machine.
I'm sorry if this is too short, but I thought I'd add my 2 cents. In my view the knitout format is very useful for this. If you want to transfer the 2nd needle on the front bed to the third needle on the front bed you can just write xfer f2 f3 in stead of transferring it to the back, racking the machine then transferring it to the front, and then return the machine to standard racking.
Now I'm not sure if the brother lace carriage can do this, but that would be the easy way to describe it. Now if it can't do it, or you don't have a lace carriage you could create a 'manual' pass where you do hand manipulations describing the needed transfers.
Most of the research done by the textiles lab is based on their industrial knitting machine which has the advantage of automatic transferring (as their machine can only transfer front to back, and back to front). I believe that every other needle is always empty for this purpose.
Sadly most of their knitting research uses an insane amount of these automatic transfers. That's because it's easy and (relatively) fail safe on their machines. The added level of complexity is just the way you need to write knitout code for these knitting machines to work properly. Sadly that means that a lot of their research isn't easy to reproduce on a domestic knitting machine. But that is a whole other subject :-)
The only thing that IS missing in knitout is purl (but I would love to hear if I'm wrong though!). That's because it was assumed that no knitting machine was capable of creating this stitch. But the KG carriages can actually do both knit and purl stitches. But I believe the brother lace carriage and the KG carriage are both kind of unique in this way.
t0mpr1c3
commented
2 years ago It's good to know that the knitout format can encode lace transfers directly. The example code that I saw didn't do that.
I agree that may be possible, in principal, to write a backend to convert knitout code that is designed for industrial machines into something usable by home machines. But I don't see the benefit at the moment.
At the moment I am looking through Megan Hoffman's code examples to see how colourwork is encoded in knitout.
The code examples do not fit into the knitspeak-to-knitout pipeline. Knitspeak does not encode colours, and the Knitgraph-to-Knitout converter does not allow for multiple yarns.
t0mpr1c3
commented
2 years ago I just had a look back at the fossasia knittingpattern project, and can confirm that it compares very unfavourably to Megan's pipeline.
Having identified a good candidate for the format, the next steps could involve forking the relevant bits of Megan's code -- it helps that it is also written in Python -- and creating new output methods for AYAB patterns that generate Knitgraph output instead of machine instructions.
The eventual goal would be to be able to load and knit from the Knitgraph format itself. It's still just an object model at the moment, but I don't think it would be difficult to make it into a useable exchange format. Just add a few header fields and JSONify.
Clearly this would be a big reorganization of the software, so what are the payoffs?
One advantage would be that Megan's software can already generate lace patterns directly from Knitspeak.
More generally, it would help separate the pattern-editing functions of the software from the knit-along functions which I hope would make it easier when adding new capabilities (like being able to use the garter carriage).
I don't think any of this necessarily needs to be done for v1.0, but I do think it's useful to have a sense of where things might need to go next, and I think Megan's Knitgraph format gets us quite close to where we might like to be.
t0mpr1c3
commented
2 years ago I just ran across another knitting language: Sintral, a proprietary syntax from Stoll that seems designed for their flat bed knitting machines. It's potentially another output format like Knitout.
Commands: (from https://nfc.stoll.com/faq/223788_01_train_learner_en.pdf)
| Sintral command | Meaning |
|---|---|
| << | Carriage direction to the left |
| >> | Carriage direction to the right |
| <> | Carriage direction optional |
| S:...-...; | Knitting specification |
| R | All needles knit a stitch |
| F | All needles knit a tuck |
| 0 | No knitting |
| FR | High butt needles knit stitch, low butt needles knit tuck |
| RH | High butt needles knit stitch, low butt needles do not knit |
| FH | High butt needles knit tuck, low butt needles do not knit |
| - | Symbol for splitting the specification between front and rear needle bed |
| ; | Symbol for ending a Sintral command |
| Y:...; | Yarn Carrier Setting |
| RBEG | Cycle start |
| REND | Cycle end |
| REP x n | Repetition start with repetition factor |
| REPEND | Repetition end |
| C | Comment |
Free demo IDE: https://sites.google.com/site/odanchuk/home
Commercial IDE: https://nfc.stoll.com/faq/232067_10_bedan_gb.pdf
t0mpr1c3
commented
1 year ago Knitscheme is a prototype knitting language that could help fill the absence of a good open knitting pattern format: https://github.com/t0mpr1c3/knitscheme
It's a human-friendly structured format influenced by Knitspeak. You can write patterns in a script, and import PNG and STP files. Knitscheme can output knitting charts, hand knitting instructions, and STP files.
I have also just added functions to save and load patterns as JSON, but the moment this functionality is no more than a placeholder. JSON is usable, and good for exporting to webapps, but as far as I can tell YAML is equally expressive and more readable to humans, and neither is as flexible or extensible as XML.
I favour the more heavyweight capabilities of XML for this, so I'm going to go ahead and write an XML schema, and code import/export methods for Knitscheme.
t0mpr1c3
commented
1 year ago https://github.com/t0mpr1c3/knitscheme/blob/main/xml/knitscheme.xsd
Suggestions welcome.
t0mpr1c3
commented
1 year ago Changed the name to Knotty. There's an executable that can import PNG, STP, and XML files and output STP, XML, and HTML knitting instructions and charts. https://github.com/t0mpr1c3/knotty/releases
t0mpr1c3
commented
1 year ago Megan Hofmann has a revised iteration of the Knit Graph object: https://github.com/mhofmann-Khoury/knit_script
t0mpr1c3
commented
6 months ago I had another look at using Knitout as an input format. Recent developments have made this more feasible (https://textiles-lab.github.io/publications/2023-knitout-semantics/).
I don't know the answer to this question. Is there a good open source knitting pattern format which AYAB could use as an internal or intermediate representation?
A related question: should AYAB have a sort of "precompiler" that translates knitting patterns to this open format, before outputting the knitting instructions in "compiled" form? By analogy, it seems to me that greater abstraction in the design of AYAB would allow it to more easily be extended to different knitting machine "languages".