What Functions are Available?

[wwderw]

What functions are supported by the libembroidery-convert module and what is the general syntax that would need to be used to invoke several functions on an individual stitch?

For instance, is Stop, SqOn, TieOff, Drop Sequin, empty etc understood and translated in the conversion from CSV to DST? If they are, what would the syntax need to be for libembroidery to successfully convert it over to a DST file?

Also if I'm going from a THR file to CSV (I go here to insert JUMP functions to invoke trims, since it isn't supported in Thred natively due to when it was written) and I wanted to specify certain colors, say color 2, what would that syntax be? I know where the color changes happen because it shows up as UNKNOWN in the CSV file. In Wilcom, it's Color (2), what would the syntax be that libembroidery would understand and carry over? This I would need for PES, PCS, JEF files etc.

Thanks for this little conversion tool. I didn't realize that it could be compiled and run separately and I'm really enjoying the fact of being able to invoke trims in files created by Thred, I hate those long jump stitches it would generate and sometimes can't distance points greater then .5" to force a trim that way. If we can use other functions that would be great.

Thanks

[JoshVarga]

Embroidermodder supports Jump, Trim, Stop (color change), and End. Recently I have determined what the Sequin commands are but they are not well supported across formats, I will be putting those in soon for the formats that support it.

The easiest way to see what CSV expects is by exporting a file as CSV, you will find the color information included.

You bring up a good point, I may offer a setting in the conversion tool to change jumps over a specified distance be automatically converted to TRIMs

Thanks, Josh Varga

On Sat, Dec 2, 2017 at 6:02 PM, wwderw notifications@github.com wrote:

What functions are supported by the libembroidery-convert module and what is the general syntax that would need to be used to invoke several functions on an individual stitch?

For instance, is Stop, SqOn, TieOff, Drop Sequin, empty etc understood and translated in the conversion from CSV to DST? If they are, what would the syntax need to be for libembroidery to successfully convert it over to a DST file?

Also if I'm going from a THR file to CSV (I go here to insert JUMP functions to invoke trims, since it isn't supported in Thred natively due to when it was written) and I wanted to specify certain colors, say color 2, what would that syntax be? I know where the color changes happen because it shows up as UNKNOWN in the CSV file. In Wilcom, it's Color (2), what would the syntax be that libembroidery would understand and carry over? This I would need for PES, PCS, JEF files etc.

Thanks for this little conversion tool. I didn't realize that it could be compiled and run separately and I'm really enjoying the fact of being able to invoke trims in files created by Thred, I hate those long jump stitches it would generate and sometimes can't distance points greater then .5" to force a trim that way. If we can use other functions that would be great.

Thanks

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Embroidermodder/Embroidermodder/issues/97, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYcnPLFRvSefWNlFsCZiGvkxIVjJiaCks5s8eT9gaJpZM4QzhUR .

[wwderw]

Embroidermodder supports Jump, Trim, Stop (color change), and End. Recently I have determined what the Sequin commands are but they are not well supported across formats, I will be putting those in soon for the formats that support it.

Unfortunately, on multi-needle machines "COLOR" is not a stop code. It would actually need to be an independent stop command for multi-needle machines. Needed for applique work (single needle machines can use color changes for applique work) and for puff digitizing on multi-needle machines.

While you can use color changes and then put stop command at the machine control unit, it becomes rather tedious when the stop command is in the middle of the color block, or really any other point other then the end.

As far as sequins go, I would just have the support in the DST files. Most machines that are going to have sequin dispensers (all of which to my knowledge are bridge style multi-needles) are going to be able to handle the DST format. I do have a Barudan and it does support it in the U?? format, but I would rather have it worked on in the DST format first, before going to the Barudan specific format.

The easiest way to see what CSV expects is by exporting a file as CSV, you will find the color information included.

Unfortunately, when it comes to THR files, it only lists the color values of what one has setup for the 16 color choices, it does not tell you what colors where actually used in the stitch information. Therefore, when convert to a PES, PCS, Jef or any other format that supports color functions, it is lost.

What I'm looking for is something like "COLOR (8)", that lets me know that the 8th color choice is/was used for that color block. This would also help preserve it when converting over to those listed formats that support color functions.

When you try to get the .col version to get the colors used, again it only does the 16 possible colors, not the ones that were actually used.

[tatarize]

Well embroidery files are a kind of CNC head with a sewing needle. The number of functions depends largely on the type of machine you have. There are plenty that have eject for sequins. You could even eject different sized sequins in theory, and there's some other actual embroidery machines with a frickin' laser beam on their heads, largely to cut applique. It's not like CSV is used by any of the formats properly. And there's some formats like .DST which don't even technically have a trim command. It might be better to start from first principles and realize what relates to what.

Since most embroidery machines are descended from single heads they often just have a color-change function and not color change to needle 4 or whatnot, even though that's entirely possible to have. There is clearly a need for a stop command that is not a color change, though in some formats there's no distinction. There's also not just the color issue but further thread issues and metadata. For example, PESv4+ includes metadata for things like author, label, description, keywords, etc within the pes file. Things like .DST have only room for LA: (label). Within the PEC block of a .PES file there's another label unrelated to the name in the PES header.

There's also various metadata for threads within some formats. PESv5+ includes thread metadata for exact colors, as well as brand, chart, number id, and other things. These will also be lost at various points.

.SVG for example can save vector data or line data but the colors are restricted to specific colors and not threads but the format has various extensions to add secondary data to things, and it wouldn't be hard to define these things. But, it's not an embroidery format.

In short, no format is going to capture all the stuff and be future proof without actually making sure you can do that. This was some of the stuff that made me switch to using my own format for my embroidery app rather supposing saving and loading from other formats. The best answer is to work with the robustness principle. https://en.wikipedia.org/wiki/Robustness_principle

"Be conservative in what you do, be liberal in what you accept from others (often reworded as "Be conservative in what you send, be liberal in what you accept")."

There's likely other things one could do with embroidery in future machines that are not currently done. Like what if I want a pattern level command to slow the machine down for a particular part. That seems like it would be easy practical and at points useful, but certainly would be lost as I know of no format that would have such a command. Maybe they come out with one and you'd need to either make the format more lossy or extend the software etc.

[wwderw]

The number of functions depends largely on the type of machine you have.

That is true, but if the converter program doesn't know how to handle codes to translate that to a stitch file, it doesn't do much good.

You could even eject different sized sequins in theory

That's not a theory, my sequin dispenser can handle 3 different sizes and 5 different shapes, although 5mm is the most common.

And there's some formats like .DST which don't even technically have a trim command.

That's right, it's a series of jump commands in a row (typically 3, although some formats like PES need more, I believe it's 5) and I'm able to implement a trim function that way.

Since most embroidery machines are descended from single heads they often just have a color-change function and not color change to needle 4 or whatnot, even though that's entirely possible to have.

It's more the just possible, it's a reality in the EMB format from Wilcom. If you do a direct connect from Wilcom and you have your colors setup on the palette that matches what you have on the machine, it will use those same palette numbers to correspond with the same number needle. Granted I don't use that direct connect function and that isn't the point of what I'm trying to do.

If you look at the top information from a THR file to CSV file, you'll see that it lists 16 colors with their respective RGB values. The point of having say "COLOR (8)" versus just "COLOR" is so the correct color information from the top is translated to file formats that due retain color functions such as PES, PCS, Jef etc. If that information is not passed on to the end user to be displayed on their software or their machine, that's no bueno for a freelance digitizing like myself. That's not expected, that's not standard.

I can't send files out that can't handle multi-needles. Multi-needles have more requirements, single needles do not. If it's setup for a multi-needle, it has no adverse affect on a single needle users, however the reverse is not true.

For a DST file, that's irrelevant, you can just write out the colors in gedit, notepad whatever and it doesn't matter, but part of the reason of using formats that retain colors is because that information is passed along, which it isn't not going through libconvert either directly or going through CSV as an interim step (which I do to insert trim (3 jump commands) in certain spots and Thred does not do that at all).

Like what if I want a pattern level command to slow the machine down for a particular part.

You do realize that that has been able to be done for for more then a decade? Wilcom has had that ability to insert those codes since ES65, which is from early 2000s. I have a 2009 Barudan bridge style machine (that also has the sequin dispenser mentioned above) that you can insert slow/fast commands to speed up or slow down As of now, those slow/fast commands are only recognized in the Barudan U?? format, which isn't supported in libembroidery-convert.

Functionality in embroidery machines, especially commercial machines as they have been out longer is far more along then what is available in open source variants for software. It seems like it's just further on back in this very niche production environment compared to say other more commonly used software packages (GIMP and Inkscape are far more robust and more competitive open source variants for their particular application then what is going on in embroidery, maybe because there is also a fairly costly hardware component as well, I dunno).

What makes it tougher is the perhaps what one could call the more universal file format (DST) doesn't support everything that say PES, U?? ART file would. However, there is far more functionality already out there then one would think.

[wwderw]

From the Stitch list of E3 (2013 was it's release date) setup to the Barudan FDR Lockstitch II type machine (which is mine).

[JoshVarga]

I have been looking for a file that I can determine other commands like Slow, Fast, and Tieoff. What application is that? Could you send me a file that has these commands in it?

[tatarize]

With my android app, Touch Embroidery, I added a some flags to trigger commands and gave it enough room to trigger a pretty large command set, which would be nice but it only supports "STOP". For applique purposes because a lot of my users are hobbyist types who do some applique work.

Clearly the way to do this is to read any valid data from the files that one can read then write that same data, if the format supports it, which requires having an intermediate internal format that logs all the information and throws away the information that can't be dealt with in that format. Cutting one's losses with formats like PES containing shapes which might be better off lost. Another exception might be the jump layers. In theory the machine can trim and jump to the new location in a variety of ways doing loop-de-loops for no reason at all if so desired. Should these worthless loops be saved between formats? If for some reason a format wants a machine to move only in X then in Y should that be saved, or just throw out that data and draw a straight line itself?

But, there's a lot of different proprietary formats with their own format sets. So reading a format that might have a command like fire laser cutter, and then converting it into other formats will, by necessity, lose that function. Most software packages have their own expected format for particular machines and unlike CNC with mostly standardized G Code (the only main non-tool related commands are change coordinate system (exact, relative, inches, mm)). This and the various metadata info should all be saved, more or less, and it's actually a pretty tall order given that there's dozens of formats with none of them properly capturing everything. It's really a project in its own right. Though example files that include such commands would go a long way in those regards.

I have heard rumors of .DST files with color information in the header but never actually seen any of them. Further complicating things there's no clear understanding of which machines have which functionality. If I had a .DST file with color information, would any machine ever read it?

My brother's work has a four head machine that switches not just colors but different heads. And I do work in PhotoEmbroidery ( https://www.photoembroidery.com/ ) and have strongly considered the prospect of doing a giant mural, between different heads of the same hooping. But, this would require a DST with stop commands to turn the heads on and off, and maybe there's a format with that ability (it's certainly possible to turn them on and off). Not that I have a strong need for a 5 foot long photo realistic embroidery outside of demonstration purposes.

[tatarize]

wave.zip

Some of my files don't even have a color change or a trim. In a somewhat weirdly mindblowing single-black-thread kind of way.

Most of the trouble is likely never coming across these types of commands. They are often built for one specific type of machine and don't trickle down to folks who'd parse the data. If some command is lacking, provide a few files with that type of command in whatever formats might have it, and that'd go a long way towards fixing it as the dozens of proprietary formats have a delightfully limited explanation and only ever get reverse engineered.

[wwderw]

But, there's a lot of different proprietary formats with their own format sets. So reading a format that might have a command like fire laser cutter, and then converting it into other formats will, by necessity, lose that function.

That is why I would suggest at first only focusing on what DST can handle and it can handle far far more, then what it is presently capable of based on other mature software.

I only mentioned things like slow/fast commands as you had mentioned it as part of a future set, when future has been here for some machines for quite a while. That was it. While I use that functionality a lot, the vast majority of my customers do not have that capability.

Should these worthless loops be saved between formats?

Please expand upon this. If you are talking about the tie in and tie offs, they aren't worthless at all. If you don't have them, your stitches have a high probability of coming out. Unless you are talking about something else

I have been looking for a file that I can determine other commands like Slow, Fast, and Tieoff. What application is that? Could you send me a file that has these commands in it?

Tie off can be supported by every format out there. Slow and Fast is only supported on U?? files. Stop commands (the true stop, not a color change that only invokes a stop on single needles) can be supported by every format out there. Some are different in how they handle the command, that's why at least getting it on the DST format as that is the more important one.

Now, if an application can put those commands in there is something else. Wilcom (pictured above) is the only one that I know that can do slow/fast for the U?? commands. Although you can force a needle to go slower at the machine itself, that applies all the time until you change it back. Slow/fast commands is far more efficient and far more useful then one might think.

I have heard rumors of .DST files with color information in the header but never actually seen any of them.

Color information is there, it's just not the same color info that it was originally digitized using. It'll know that a new color is going for these stitches, but that's it. That's why if you have a 2 color designs that goes color 1, color 2, color 1, it could export as a 3 color design, but it does retain some color.

Now, if you are talking about what is referred to in the industry as "true color", in my 23.5 yrs in this trade, I haven't heard of anyone working on that. Not to say that it isn't possible, but I've heard no rumors on it.

Further complicating things there's no clear understanding of which machines have which functionality. If I had a .DST file with color information, would any machine ever read it

Depends on how old the machine is or how it was setup.

Some machines that are old that didn't have the "understanding" of trim, just won't do a trim. They'll skip over the code. They'll still run the file, but skip the code.

Now on PR machines and certain stop commands, it could cause the screen to crash and reboot or it just won't read the file period. Won't even show up. What reaction you get depends on if its a DST or their native PES file format.

[tatarize]

That is why I would suggest at first only focusing on what DST can handle and it can handle far far more, then what it is presently capable of based on other mature software.

I know the dst files can be expanded a bit, they certainly didn't exhaust the entire code base there though it loses a lot with duplicate numbers because the code is based on punching and allows an undo to a punch by doing the ± version of that same number. I'm pretty sure fast/slow aren't part of the dsts but maybe. I haven't even checked for the eject commands yet.

Please expand upon this.

Embroidery machines work a bit like CNC machines they do exactly what you tell them to do. I used to, in an older version of a program, do a movement to the next stitch location by going +X+Y max, until an axis was exhausted then going +X or +Y for the remainder. The effect caused it to go exactly diagonal and then in a straight line to the correct position. And the machine did this operation as I had coded it. -- In theory this is information that can be preserved between formats rather easily. You can save the jump stitches and how they are ordered between formats. Which would in theory save a dst trim of jumping around a bit at the trim site the (+2+2), (-4,-4), (+2+2) was the common version of this, or my strange coding there of a movement to the next location. In theory if we care about max preservation we should keep the same path between jump stitches. Maybe even their distance because we still have things like .dst files being limited to a max of 12.6 (I think) and other formats able to make the entire jump in one (both after trims). This could also be preserved in some cases with interpolated stitches in others.

Tie off can be supported by every format out there. Slow and Fast is only supported on U?? files. Stop commands (the true stop, not a color change that only invokes a stop on single needles) can be supported by every format out there.

So by tie off do you mean like lock stitches? I know I have this done as just stitching forward and back a bit at the end segment to make sure the stitches don't come out. Or at the start to make sure it doesn't quickly pull away losing the stitch. Unless there's something else attached to an embroidery machine outside of a supply of needles that stitch and an arm thing that cuts the thread and some sequin stuff and a laser cutter and a few other specialized things the tie off is just more stitches?

Slow/fast commands is far more efficient and far more useful then one might think.

Nah, it seems like it would be crazy useful. You need it to sew as fast as it can and parts will have a bunch of thread breaks if they go too fast. So rather than slowing down the entire machine for the entire sewout you could certainly find utility in that.

Color information is there, it's just not the same color info that it was originally digitized using. It'll know that a new color is going for these stitches, but that's it.

True, but the DST files are a header of 512 bytes with mostly junk data that can be interpolated from the sewing bits anyway but are there and used by the embroidery machines to know how big the sewout should be (I know, I've gotten this wrong and had it sew beyond 100%). But, I hear that some DST files use some of that blank space to store the original thread colors the design was digitized in. It is just a bunch of blank space that isn't otherwise being used by anything. I've never come across one of these DST files but it's not hard to see how such an extension to the format would work. I've written the whole pull random numbers out of a hat code enough to know the color info isn't there beyond the understanding that it is changed rather than the same.

DSTs don't have any other flag information there. PEC/PES files do though and they do actually have a number in there that insists on color switching from 1 to 2 and back over and over again. But, they use the PEC specific colors in the header rather than anything about needle number at least as far as I could tell in my research of the topic.

I haven't heard of anyone working on that. Not to say that it isn't possible, but I've heard no rumors on it.

They wouldn't be standard and maybe even just a hack on top of DSTs rather than padding the header like is typically done. I've not actually seen any of these files and at most read the label information, as it's the only header information that isn't worthless. But, if we're trying to save and load as much info as you can, shouldn't those be checked for and used if available and perhaps even output because it could be done?

Some machines that are old that didn't have the "understanding" of trim, just won't do a trim. They'll skip over the code. They'll still run the file, but skip the code.

There's no encoding for trim in dst that I'm at all aware of. Instead these are triggered with a series of jump commands.

Now on PR machines and certain stop commands, it could cause the screen to crash and reboot or it just won't read the file period. Won't even show up. What reaction you get depends on if its a DST or their native PES file format.

This is one of the reasons why it's best to stick to things known to generally work and do nothing else. For example it's entirely possible to write a PES file without the PES block, by simply hacking the pre-PEC header as

23 50 45 53 30 30 30 31 16 00 00 00 00 00 00 00 00 00 00 00 00 00
# P E S 0 0 0 1 . . . . . . . . . . . . . .

Which should in theory work and load the file in all software that isn't Brother's own software (which reads it as blank). As they all read the PEC block that does the embroidery machine control stuff which is more understandable and standard though some of the control codes are not well understood. And I wouldn't go altering the graphics sizes even though that is generally understood because maybe older machines would be unable to see them or crash or whatnot. I'm pretty sure the lock stitches are entirely just stitches and in dsts the trims are done in jump stitches. But, there's some haziness to this.

The formats themselves are generally kind of lossy. Things like lock stitches add stitches and would need to be detected somehow to not have loading and saving with lock stitches not add additional lock stitches. And I recently altered the way my outputs of PES files work to not reuse the same color code twice even if two different colors were the closest to the that color. Largely because it turns out that PESv5+ in Brother Software treated the true color thread listed in their more modern headers as a unique list while Wilcom treated them as individual entries that should be used in a 1:1 method (somewhat erroneously). See the Panda attached. I wrote Wilcom and they said it works e4.1 update (though it wasn't clear if they patched it before or after or if they output proper files now or not).

panda.zip

In the end, it seems like the only way to do such a thing is to write your own lossless format that doesn't lose any information and then loses what it must when the files are exported to a different format. Which means storing all metadata available anywhere, for the pattern as well as the threads, and all the commands that any format has. Which currently is losing some forms of stop, sequin eject, laser cutter, color #, or whatever else might exist somewhere. The DST files in lib-embroidery are really bad about calling sequences of jumps a trim, so that's lost (unless a bit of code is uncommented out). It might be kind of impossible to capture lock stitches and tie offs if those are just a quick pattern of stitches. And, adding to that, any vector shapes in all of these formats that generally don't include vector shapes but only worker information.

I'm going to be adding vector shapes to my own software rather soon, as such I'll be using much the same format for stitches as the vector points so it won't be hard to flag things as smooth control points for bezier curves, but could certainly allow me to toss in commands like slow/fast without much of an issue.

These issues are one of the reasons I had, for a long time, only implemented .dst and used .svg as my core format (which I now regard as an error). And likely Touch Embroidery wouldn't have any other format types save for the work on Mobile Viewer, and LibEmbroidery, etc.

[wwderw]

There's no encoding for trim in dst that I'm at all aware of. Instead these are triggered with a series of jump commands.

By saying "trim" in regard to DST files, I'm talking about 3 "jump" commands in quick succession, that's what gets a "trim" in DST and even PES files. ART is the only one that I'm aware of that actually uses trim in of itself as a trim. Good luck getting documentation on that from Bernina.

Older machines don't translate the 3 jumps in quick succession as trims.

In the end, it seems like the only way to do such a thing is to write your own lossless format that doesn't lose any information and then loses what it must when the files are exported to a different format. Which means storing all metadata available anywhere, for the pattern as well as the threads, and all the commands that any format has.

And that is what we freelance digitizers are used to with Wilcom's EMB format (and formats along those lines). They do retain that info for all supported formats. Now Wilcom is the only one that has implement slow/fast commands in Barudan U?? files that I'm aware of due to their close association with Barudan. That may have changed though.

These issues are one of the reasons I had, for a long time, only implemented .dst

That's fine if that's the only file format that you (or in my case customers) would use. And for most modern mid range home to full commercial machines can handle, but not everyone wants to deal with that and if they are doing things beyond straight embroidery (cutworks (home) or boring(commercial), sequins etc) that becomes a problem.

[tatarize]

The point is well taken. And I'll be sure to consider such commands. I'm pretty sure Josh just hasn't added those because no format that's been reverse engineered thus far has had very many of them. I posted a few sequin dsts because of a comment in a review on the android Mobile Viewer.

PES files do very much seem to have a trim flag on a jump. You can flag a stitch as jump and trim, in the extra bits. These seem to have an effect.

I'm currently reviewing some of the data on the Mobile Viewer for the various changes. And this conversation seems to lend me towards the correctness of flagging data attached to points as particular commands. And using that data for reading and writing the files. Especially considering that some of these would be harder to do on a per layer basis. And while I'm not sure where the project tends to be going, it's been getting a lot of libembroidery stuff so it wouldn't be that hard to transcode a lot of the lib-embroidery stuff to android for those purposes, especially if the internal datastructures are similar and able to easily be expanded with additional commands.

[wwderw]

The point is well taken. And I'll be sure to consider such commands. I'm pretty sure Josh just hasn't added those because no format that's been reverse engineered thus far has had very many of them. I posted a few sequin dsts because of a comment in a review on the android Mobile Viewer.

I could export some using the program that I have. Only consideration that one would have is that it's how that particular program implements those commands. It tends to implement them in the form that the commercial variants recognize and not the consumer versions (a BE versus a PR etc).

PES files do very much seem to have a trim flag on a jump. You can flag a stitch as jump and trim, in the extra bits. These seem to have an effect.

Some programs do put both on the stitch. I haven't noticed that at the PES level, but I haven't gone further then v.6 as that's what my machines handle (7 yrs old) and anything newer can handle that format as well.

And while I'm not sure where the project tends to be going, it's been getting a lot of libembroidery stuff

I would like it if the main program actually was to be getting further along, but it's way way too alpha for my uses. libembroidery seems to be fairly stable and usable, even if it doesn't have all the formats and what formats it does have listed as "U", at least the version of it that I use, it's still fairly usable.

I also like the fact that it's portable. Compile, build, make once and can use it on a lot of other desktops.

Haven't quite made it to the transition to ARM, I'll probably be one of those holdouts that uses Qemu to get to my x86 apps.

[tatarize]

The one purpose I used lib-embroidery for I had to disable because it failed at the trims in the DST files. I haven't gotten around to editing it and moving that data back. Plus most of my work is for Java. Both the back end of my automatic photo digitizing (better than anything else that exists period) and my nice Android-based embroidery editor (Touch Embroidery), so I'm inclined towards those in Java.

The PES files though are divided into PES sections and the PEC blocks for the machines itself. PES for Brother's embroidery editing and PEC for the machine to sew out (it literally can and does often have the stitches twice) and the PEC stuff does seem to encode for a trim. Which makes it true regardless of the PES version. The version of the file is mostly entirely PES, though the header with truetype colors is fairly nice.

bear.v6.pes.zip

So I can manage to have embroidery software (that loads the colors) fully visualize the images in the correct colors.

Largely because a lot of other formats are totally lossy with regard to colors. But, it's certainly something to strongly consider. Though without formats that contain things like "color change to needle 4" or "slow" or "fast" they likely won't get recognized due to simple impossibility. But, it's enough to convince me to transcode this stuff in the more typical Lib-Embroidery way. The flags can certainly be expanded to include a lot of other functions and data on a per-stitch basis. So the lack is in formats that possess such abilities.

[JoshVarga]

I was trying to put together a list of embroidery formats and what they are capable of. It sounds like U?? is the only format to support slow/fast? Do you know which formats support boring? Sequin? Any others? I can start a page in the Embroidermodder Wiki to cover known formats and have yes/no or other info about each format if that would help

[wwderw]

I'm not really a fan of Java, it pained me to install a program for my wireless access point that was in Java, but I digress as that is a personal prejudice.

Largely because a lot of other formats are totally lossy with regard to colors.

Unfortunately, this is irrelevant. If you care about it being used for people that digitize freelance to other shops/people. They do have to have access to those formats and expect that behavior. If they don't get it, their customers go with someone that can provide it.

I'm not an auto conversion fan at all. Period. If I don't have manual input tools, I just go right on by. I don't mind if it's in the package as well, a lot of people do like, but if I don't have my manual input tools with the ability to manipulate settings, I'm a pragmatist, I'll use Wilcom. I prefer to support Open Source, it just isn't there for embroidery. EmbroideryModder was one that I really like the looks of, but I don't think the main part of the program is getting anywhere as it is very much alpha.

An extension for Inkscape is showing promise though.

was trying to put together a list of embroidery formats and what they are capable of. It sounds like U?? is the only format to support slow/fast? Do you know which formats support boring? Sequin? Any others?

It depends on if you are going to approach this from a commercial or consumer line up.

DST supports most everything except slow and fast.

Brother PR machines have what they call "Cut Work" which is akin to the boring function, but I'm sure how they would implement that is different then how a DST would.

For me, functions that I would like to see are:

Stop

Frame In/Frame Out (killer for applique, but with support of stop and trim it can be manually done without it)

Tie In / Tie Off

Sequin On/Off/Drop

Trim

These are supported in DSTs.

Personally, I would like slow and fast because I do have a Barudan machine and I use the snot out of that, especially for small detail/lettering

[tatarize]

I'm not really a fan of Java, it pained me to install a program for my wireless access point that was in Java, but I digress as that is a personal prejudice.

No. That's an entirely valid criticism. In fact, it's starting to die off largely for reasons akin to that. Android compiles completely into a different result and the other tool I use very much works in the back end.

I'm not an auto conversion fan at all. Period.

Generally because they overwhelmingly suck. And as a digitizer, if they worked, would require no skill. My program on that end has had the better part of a decade of work and notably does not suck. I can sew embroidery indistinguishable from a photograph at 5 feet. Make sewouts better than the typical embroidery that win the Impressions contests in an couple hours instead of a week. On top of that though, I wrote my own android embroidery editor and put it up on the play store. Though, it isn't open source it does have a totally free version. While wildly off topic I'd love your opinion(assuming you have an android device) ( https://play.google.com/store/apps/details?id=com.photoembroidery.tat.touchembroideryfree ).

but I don't think the main part of the program is getting anywhere as it is very much alpha.

I don't really think it is either, but, the lib-embroidery parts are quite useful. And I think there's a lot problems with the way embroidery is typically done. While obviously there's a need for quickly laying down stitches there's a weird fetisization for vectors which are cetainly less needed than one would think. But, I guess that's my own hobby horse. It's odd though to do blending that you need some shapes and other shapes and middleground shapes etc, when really it should be pretty automatic.

Frame In/Frame Out (killer for applique, but with support of stop and trim it can be manually done without it)

I'm not really even sure what this is. I'd assume it's a higher level command that in DST just turns into a stop and trim. Does any embroidery machines actually do something else for this? And is there a format that has a custom command for it?

[wwderw]

Make sewouts better than the typical embroidery that win the Impressions contests in an couple hours instead of a week.

How big are these designs? Most of my requests are for an LC size. Which take me about a full day to do on average. Jacket backs take me about 2-3 days. Depending on a few variables that could change between one project from the next. That's also being able to work on it straight through. Now this is more of traditional blending then anything else.

What appears to be in the pictures that you have posted are more like what's called Photo Flash and I actually haven't gotten any requests for that type of output. Now, to be honest, I don't do it and I don't advertise for it. So they (customers) might just come to me for the more traditional blending.

The biggest thing that I've noticed and this applies to programs in the $600 range all the way up to the $15k programs. There is no creativity*. It has a narrow focus of tools (at most I've ever seen is 3 tools used, when I did the digitizing on the same pattern, I was using 7 tools and there were reasons for those tools being used, I wasn't using tools to get a higher count compared to the auto conversion) that it tries to force into use for every situation.

*A big thing that I don't like about auto conversion, is that anybody that runs the same program with the same auto conversion, there is very little distinction in output, because it's all using the same programming. Professional digitizers that have been doing this for years, that knowledge of knowing what fits production and what doesn't or how to manipulate it to fit production, is a big thing that auto conversion tools haven't accomplished (yet anyway). And just about everyone of them would have their own spin on it. Very few times are the same techniques used in the same way.

And I think there's a lot problems with the way embroidery is typically done.

Be careful about trying to reinvent thinking on this. Going too much against an established grain with programs that have had 30 yrs as industry "standards" is a tall order.

Now, for full disclosure, I like the vector method of doing things (among other things). So I do have a biased towards that.

I don't know if you are a digitizer or not as well as a programmer (and not just hobby during your own patterns, but for the public as well), but I would see about trying to do a variety of requests for 3rd parties. Some of the stuff that you might not think are beneficial are very, very beneficial. Now if your customers are just those that do their own things in house, that's something else entirely.

I'm not really even sure what this is. I'd assume it's a higher level command that in DST just turns into a stop and trim.

I'm speculating here, I just believe the option of Frame In/Out is just a input field name that people see as a descriptor for something that is essentially jumps and a stop.

The goal of the function is to move the hoop away from the needles and pressure feet (mainly for commercial machines) to allow easy access for the placement of applique fabric.

I get around this in a program like Thred by doing 3 manual stitches at the end of an object that I want to be jump stitches going in the direction that helps move the hoop out to me, then I do a color change (this allows me to enter in a stop command at the machine itself).

When I'm done with the THR file and ready for production, I'll convert to CSV, change those 3 manual stitches to jump stitches, so the machine will know to do a trim and move in the direction I'm wanting. Convert CSV to format of choice (typically DST). Load it up to the machine, tell the machine that those certain color changes are stop codes (it doesn't matter, if digitized correctly, if those underlay stitches for the applique are one color or not, as a properly digitized cover stitch will cover that up, but there is a way around that as well at the machine) and away the machine goes.

It's far easier in commercial software as a lot of the stuff I'm doing manually is done on the fly as I'm digitizing, but it does work this way.

[tatarize]

How big are these designs? Most of my requests are for an LC size. Which take me about a full day to do on average. Jacket backs take me about 2-3 days.

We've run them in every size our machine can manage. So like 25cm at the top end. They still are very obviously the faces of people we totally know even at the small end.

What appears to be in the pictures that you have posted are more like what's called Photo Flash and I actually haven't gotten any requests for that type of output.

Generally because it sucks. I could code that technology in an afternoon. It's not very good. It basically does dot matrix stuff going across the screen and filling in density where those colors exist. You might get some reasonable results if you go much larger in size, but it's pretty bad.

Now, to be honest, I don't do it and I don't advertise for it. So they (customers) might just come to me for the more traditional blending.

As well they should. There's a reason that kind of digitization hasn't taken off, generally it's not very good; mine actually is. But, consequently takes a few hours to run a piece. And each one turns out differently.

*A big thing that I don't like about auto conversion, is that anybody that runs the same program with the same auto conversion, there is very little distinction in output, because it's all using the same programming.

My version is a radical departure. Usually the sort of cross stitch dot-matrix crap that comes out of those programs could be outdone by a professional digitizer at a tenth the size. Those line-density algorithms just actually aren't that good.

Professional digitizers that have been doing this for years, that knowledge of knowing what fits production and what doesn't or how to manipulate it to fit production, is a big thing that auto conversion tools haven't accomplished (yet anyway).

There's a lot to that, it's the reason I sew them out. It allows me to compare the various expectations with the results. Since my results are pretty light and not repeating the same angle over and over again, I can get away without pull comp or some of the other tricks. Though, there's a lot to cut time and quite often I can get a lot of cuts. Also, it does blending fantastically but sometimes uses a single color for like 500 stitches of something weird and you needed to load a spool for that. Sometimes it's needed to get an eyeball exactly spot on, but sometimes it seems like I could have coaxed that into doing something else. Also, they are square like the photographs unless you clip out the background with transparency.

Be careful about trying to reinvent thinking on this. Going too much against an established grain with programs that have had 30 yrs as industry "standards" is a tall order. Now, for full disclosure, I like the vector method of doing things (among other things). So I do have a biased towards that.

This is actually one of the reasons for my reinventing the wheel sort of idea. It's less reinvent rather than break down into the most basic parts. You should be able to have the wheel, but you should also be able to have a few spokes or the rim if that's what you need. There's little reason why when you do a flat fill in one program, you should have to run it, realize it's terrible, delete it, break the shape into more and different parts that are monotonic and then fit these into the right orders. My brother's done some very impressive embroidery that took hundreds of vector shapes to get right.

It seems to me, and correct me if I'm wrong, a lot of the skill in digitizing is coaxing the vectors and such into doing what you want, to get the blending correct, and making it fill that particular shape in the correct way or correct order. My objection isn't to the vectors per se, but that the vectors and fills are tightly coupled. That when you want to digitize something, a lot of how you would describe it is fill the outline of this shape with a zig-zag, go through this shape with some very light underfill from bottom to top, then go from the top of this shape until here, then go up here, fill in this shape, then fill in the rest of the shape ending here, then cutting and going to the next shape. -- And sometimes if you wanted to do that, you'd need more than one shape, break off a piece of it to coax it into working the way it sort of should. That the auto-digitizing stuff for some of these parts seems to pick one way, and if that's wrong enough, you do it another way. And understanding the side effects of the various tools you're given.

My reinventing the wheel bit is, understanding how to rebuild those higher level tools in progressively lower level tools. At the most basic, you could do everything with a running stitch, so what are the parts both stitch-wise and math wise that build up the higher level objects, and giving users access to those. And understanding that a lot of these fills use vectors as bounds and areas not but really as objects that own the fill, and that requirement is actually quite restrictive and isn't needed. There's also a bunch of other ways things can be filled that are not easily done but mathematically possible.

I don't know if you are a digitizer or not as well as a programmer (and not just hobby during your own patterns, but for the public as well), but I would see about trying to do a variety of requests for 3rd parties. Some of the stuff that you might not think are beneficial are very, very beneficial. Now if your customers are just those that do their own things in house, that's something else entirely.

My brother's a digitizer. But, your advice is obviously very sound. For the photoembroidery stuff we have a website to upload photos and have it return the designs. We would be more than happy to give you a some digitizations for free ( https://www.photoembroidery.com ) just send an email and we'll mark them purchased for you.

The goal of the function is to move the hoop away from the needles and pressure feet (mainly for commercial machines) to allow easy access for the placement of applique fabric.

Hm. You could certainly, trim, jump to above the pattern (or any predefined spot), and stop, then jump back to the next element. But, the predefined spot would be predefined in the embroidery itself, when really the command would likely be most useful if the spot to move to would be defined by the machine rather than the embroidery, which would need its own command to accomplish. I could only assume the machine can go to the top of the pattern, I'm not sure how far it could go beyond that. With that consideration, I could see a machine having that as an overt command. Or breaking that command into proper sub-commands.

Though, more likely it means I should give MobileViewer the ability to add in commands and break them into subcommands when they convert to a different format. Seems to be the direction of that app and I'm working on it presently and sort of needed another view other than just layer colors the drawerview widget thing.

I get around this in a program like Thred by doing 3 manual stitches at the end of an object that I want to be jump stitches going in the direction that helps move the hoop out to me, then I do a color change (this allows me to enter in a stop command at the machine itself). ... but there is a way around that as well at the machine) and away the machine goes.

That's a lot of hoops to jump through for a hoop. But certainly something that could be properly automated. But, more pressingly, might be stripped out if one doesn't preserve the stops without color change or the jumps.

[wwderw]

There's little reason why when you do a flat fill in one program, you should have to run it, realize it's terrible, delete it, break the shape into more and different parts that are monotonic and then fit these into the right orders.

Are we talking regular logo embroidery or the realistic embroidery? Regular embroidery that is very much not the case. Now if you are talking about realistic embroidery, then yes, areas to have to be broken down more to get different angles and then digitize the blends on top of those different angles etc.

That's the kind of realism that I like to see. That's maybe 4 hrs of my time. 2.5" tall.

Hm. You could certainly, trim, jump to above the pattern (or any predefined spot), and stop, then jump back to the next element. But, the predefined spot would be predefined in the embroidery itself, when really the command would likely be most useful if the spot to move to would be defined by the machine rather than the embroidery, which would need its own command to accomplish. I could only assume the machine can go to the top of the pattern, I'm not sure how far it could go beyond that. With that consideration, I could see a machine having that as an overt command. Or breaking that command into proper sub-commands.

No, you would want it pre-defined by the pattern, not machine. Each pattern would be different and depending on where you have the orientation of the design, if I'm doing a onesie, I'm going have to hoop and rotate the design differently then if I'm doing a regular shirt etc.

That's a lot of hoops to jump through for a hoop. But certainly something that could be properly automated. But, more pressingly, might be stripped out if one doesn't preserve the stops without color change or the jumps.

That's a lot to jump through, because a program like Thred isn't designed to do it. It's for home users, not commercial users, different needs for different folks.

Now, Wilcom definitely has automated it and made it much easier to adjust it on the fly. My original commit was doing it for programs that don't do it themselves. Just like Thred doesn't do trims and I have to manually go in and do the respective amount of jump codes to get trims (if they fall within the .5" maximum before a machine will force a trim (if a newer machine and if that option is left on, it's typically on by default).

[tatarize]

Are we talking regular logo embroidery or the realistic embroidery? Regular embroidery that is very much not the case. Now if you are talking about realistic embroidery, then yes, areas to have to be broken down more to get different angles and then digitize the blends on top of those different angles etc.

Yeah, a lot of the blending and such, if you can have hard then it's a bit more conducive to just filling shapes. But, compared to some of the best embroidery there's a lot of tricks that can be applied above and beyond that give it a much better look and feel. It's hard to beat the sort of paint by numbers approach on things that are just going to have sharp edges, so things like logos would be hard to beat just trace out the areas and fill them with a single color at a single angle and have them start and end at the correct places. At the higher ends with a bunch of different blends trying to create sort of gradients the tricks get progressively harder, I sort of feel they shouldn't need to. Rather than having closed vector shapes you could define areas simply by drawing the bones of the embroidery and defining how those areas should be filled without the close relationship between objects and fills, with multiple interacting fills pumped through something a bit akin to a 2d physics engine. Such a plan would include all the standard fill types rather easily as smaller predefined parts. But, also be able to fiddle with parts of it in non-traditional ways.

The goal would be to get the best of all worlds. Being able to control the how of the fill as needed. While still having the higher level functions that are used to make those things, but also breaking those into various sub-parts.

That's the kind of realism that I like to see. That's maybe 4 hrs of my time. 2.5" tall.

Currently PhotoEmbroidery would render that, given a photo, as a basically perfect recreation of the dog in the photo, blanking out the background with transparency for better effect. Whereas Touch Embroidery could let you draw a dog in basically running stitches if you were insanely skilled. My sister in law can do such things, but I haven't really gotten around to the advancing the app to do more with higher level tools as it's a lot of math.

embroidery files

-- Embroidery files to check that it's totally a 2.5 inch design.

No, you would want it pre-defined by the pattern, not machine. Each pattern would be different and depending on where you have the orientation of the design, if I'm doing a onesie, I'm going have to hoop and rotate the design differently then if I'm doing a regular shirt etc.

Then breaking a frame command would be pretty doable. Though why are they two commands? Why isn't it just a bunch of jumps and a stop? Why not just move to the top of the pattern, throw in a stop command, then head back to the rest?

Now, Wilcom definitely has automated it and made it much easier to adjust it on the fly. My original commit was doing it for programs that don't do it themselves. Just like Thred doesn't do trims and I have to manually go in and do the respective amount of jump codes to get trims (if they fall within the .5" maximum before a machine will force a trim (if a newer machine and if that option is left on, it's typically on by default).

Hm. That seems to be the basic sort of editing that Embroidery Viewer should be setup to do. If it's going more in the transcoding direction. I'll keep that in mind when I finish my couple days worth of work on it every few months, in a couple days.

[wwderw]

so things like logos would be hard to beat just trace out the areas and fill them with a single color at a single angle and have them start and end at the correct places.

What type of stitch are you talking about (using the 4 types that embroiderers would understand: manual, run, satin, fill)? On logos, on average, most are satin stitches and quite a few of those are "not" going to be a single angle. That would look bad. Particularly if you are talking about lettering (which makes up more then 90% of the logos that I would handle) that isn't simple letters and not san serif fonts.

If you were to do a font that had serifs or had spurs, how would the program know when to make those serifs and/or spurs apart of the neighboring object or their own separate section of the letter? Depending on the situation, determines which one is the best.

Even in blending, you might have one angle for this one section over here, but the section right next to it is a different angle and so on. Some may share the exact same angle, just not be right next to each other.

If you don't do that, things look flat.

While an auto conversion module may pick different angles for different sections, it's rare that they get the best angle for that particular section.

Rather than having closed vector shapes you could define areas simply by drawing the bones of the embroidery

Not always dealing with closed vector shapes. Run stitches are not going to be closed shapes (which if I didn't want to do the blending of the dog manually, that's the tool that I would use), if you are familiar with Wilcom Input/Tool C is directly related to the same type of digitizing as a run stitch (why you can convert between the 2) and that's open vector shape, but it creates satin stitches.

could let you draw a dog in basically running stitches if you were insanely skilled

When I first started this we learned to do it 1 stitch at a time (back in the early days, that would be single stitch input for even the main color blocks that the blending is on top of). We were the "stitch engine" if you will. Which I still do in part. The main blocks of the dog that I did are using the semi auto tools of Wilcom (Complex Fill), but everything on top, all that stitch work is placed 1 needle penetration at the same time. Wilcom's stitch engine isn't doing those blends, I am.

Then breaking a frame command would be pretty doable. Though why are they two commands? Why isn't it just a bunch of jumps and a stop? Why not just move to the top of the pattern, throw in a stop command, then head back to the rest?

Sometimes you don't do exactly to the top of the design or you may go well beyond then just "the top" of the design. The biggest component of that is the size/shape/location of the appliqué piece(s) in question.

See, this also highlights a big problem that I personally have with auto conversion of anything (and that's not even getting into how it sequences objects on it's own, which I've never seen one do correctly). It's trying to program doing a few things globally to apply to every situation and that just isn't the case.

Until someone is able to get AI into the program to learn, to adapt, auto conversion still isn't going to beat a digitizer with a good solid knowledge base of what to do.

That's why I won't touch programs that only have auto conversion abilities.

I've dealt with programs that cost $500 and I've dealt with programs that cost $15k (I've got a small fortune in digitizing programs). I've beta tested quite a few of them for those vendors. Some, their auto conversion was decent, some really really sucked (and what price one shelled out didn't have any bearing on it). Some did really good lettering (some depended on auto converting lettering, but had manual tools for everything else), but sucked at everything else auto converted.

Post auto conversion cleanup is also very messy and for me, takes far longer then just having done it the way I wanted it done in the first place.

I, personally, would be just fine if a program just had the manual/semi manual input tools. No lettering module, no auto conversion. Most people that get into the game today, wouldn't, because they didn't learn 23.5 yrs ago (or more) when that was all that we had. They want the quick and easy way.

The methods that I use also translate to other programs, not just Wilcom. When one deals with auto conversion, those toolset tend to change (naming scheme always changes between programs, I hate that), options that it has etc.

One reason why I still keep a copy of Thred around to help teach people how to digitize. It has manual and semi manual tools (not just closed vector objects (they call them forms in Thred), but also open ones as well), but it isn't cluttered with a lot of options to either worry about or to use as a crutch. It's got a few, but since it's very keyboard centric, it's a little harder to invoke those options and they are out of the way from main viewing, so that helps. Nice thing to is that it's portable. Even though it was written in the Win 98 days, it still works all the way up to Win 10 and it will work really well in Linux using WINE.

[tatarize]

First off, two things. I do work on the extreme ends of both auto-conversion. Both, with a wild disdain for auto-conversion of vector shapes. I do photoembroidery, namely I wrote a program that can auto-digitize an image better than any human could into pure running stitches. You can download my dog there (try viewing the v6.pes file it'll have the correct colors) and it will be absolutely spot on as a recreation dog from the image at a size comparable to yours. This isn't making shapes out of the dog and making stitches out of the shapes at all. It's also not match the color in some kind of dot matrix scan line horror show. It's far superior to anything on the market for that one task. You give it a photo and it'll make an embroidery that will look like it's printed.

Doing such thing gave me a certain disdain for some aspects of embroidery programs and the underlying paradigms. And from tradeshows (ISS etc) and my brother's work, I strongly disliked a lot of the underlying theory that built up the methodologies for how the embroidery programs worked. It's really sort of clipart like, and paint by numbers, but at the artistic end, fantastic digitizers can absolutely do amazing things with it. A genuine and wonderful artform that deserves admiration and respect. And, my photoembroidery work, didn't need any part of like none at all. It can boot up a cloud computer, tick away some clock cycles and do an embroidery superior to the best embroiderers trying to match that image, in a few hours rather than days for a larger project. --- This kicked off the other extreme. I've spent a couple years working on Touch Embroidery my android app which went towards the other end, making purely artistic embroidery with what I saw as missing elements with some simple tools for modifying running stitches, and some not so simple ones. And a series of research topics on not only embroidery, but the math theory behind the linear geometric reasons those things are the way they are rather than a different way. So anything you can do with simple graph theory you could do with embroidery. So various fractals, Victorian drawing machines, galloche, anything that could be done with embroidery and all the different ways to fill objects and why they are filled like that rather than another way.

Then I thought a long time about how I could capture all of that in a system powerful enough to make such things doable without falling down to a running stitch. After all everything you can do with embroidery can be done with a running. You could do a fill stitch with running stitches if you were so inclined. There's only one type of stitch. The question becomes can we do everything possible, with the most helpful methodologies that can build the more complex tools from more basic building blocks.

Take for example that flat fill or tatsumi. Different software implement this in different ways. And sometimes it need to be coaxed into doing things the correct way or the way needed by breaking the object up into more objects and tweaking them in certain ways. Or filling in underlay in the desired way as a different sequence. The problems here are plentiful but it shows the point really well. Tatsumi is not a fill, it's an algorithm. The things it does can be broken down. If we are sewing at a particular angle (that we chose because the program's angle was stupid) it will put down some underlay of a very light fill pattern in some direction, it will then go to the top of the object, (in graph theory such things are called monotone polygons subdivisions according to their split and merge nodes) it splits these parts into subparts that are monotone for that angle by connecting that offending split or merge node to the wall dividing the shape into a bunch of monotone shapes (shapes that can be filled with a single scanline in a single direction that does not change), it underlays to the connecting merge node or split node within that are and stacks the objects together so it fills some area then underpaths to the top of this new area then continues down then does some more underpathing, then more filling until it fills up the shape (start and end positions in shapes do slight modifications of extra splits as such. -- And on top of this, it often gets it wrong.

But the parts that it does are completely doable. You have fill lines that fill from particular positions and underpath to the bottom. You have underlay fills etc. The important thing here isn't the flat fill, it's the sequence and trying to automate that is always going to be wrong. What you want to do is take a guess at a reasonable way of doing it, then allow the user to choose the sequence and even draw the sequence such that they could do clever things like fill in parts of it at a different angle or ignore some parts of it, or do the underpathing a different way. There's every reason why that fill should be broken into a sequence of tasks that can be simply tossed out the window by the user or done by hand by the user without defining anything else. If you let them have the fill this part of the shape commands in a coherent way, they can do a better job than the computer ever could. And if you had those tools you could do whatever. It's those various things it's doing in that sequence that matter. Moreover it can allow you to define things that are not done trivially in embroidery like doing signwaves between various different other shapes in a guilloche, or blend one of those patterns into another, and these basically happen on the cheap because they are just part of the same system.

When you need the higher level objects, you get them so satin stitches, flat fills, shapes with fills in them, etc. But, they are taken and broken down into their relevant parts, much like you can manually edit the resulting stitches, you could manually edit the parts that make up a complex thing.

What type of stitch are you talking about (using the 4 types that embroiderers would understand: manual, run, satin, fill)?

In reality these are all variations of run. They are just that some math underpinning how things get filled namely due to the properties of sweepability and monotone nature of areas. Namely can you fill that area with a sweep line (with rotation of the line, or not) or can you not fill that area? But, these properties need not be attached to the objects being filled. They can instead be attempted and either work or not, or be coaxed in through methods unknown into working.

On logos, on average, most are satin stitches and quite a few of those are "not" going to be a single angle.

Yes, but the angle of the sweep is not a single size fits all prospect. While clearly smoothly filling the area with a sweep (satin stitch) is typical and my methodologies would obviously allow you to do a satin stitch in the traditional manner. The actual trick would be, because I do the shape as a moving scanline bound by an area you can tweak that change the fill line in whatever ways you want. -- At the core my methodologies would be able to do the same work but break them down into simpler forms with more power than the larger more complex forms, that are what satin stitches, are. So it wouldn't prevent you from doing satin stitches. The problem is the satin stitch fill-object methodology is preventing you from doing other forms that might be reasonable things to do.

After all the math is simply whether a shape can be filled by a scan line that turns. And if it can't be filled in, it would just not fill in the parts that don't fill in properly. There are improper geometry of some closed shape objects being filled, but in my system they would be filled, just in strange ways. Basically the most simple structure here is a shape that bounds the edges, a turning scan-line, and the center line that defines where the satin stitch is. If you want a satin stitch it would give you a satin stitch. But it would define it, not as a satin stitch object, but as an object-bounds object, and relevant line of insideness to the satin stitch, and a the angle of the scanline being used to do the fill. Using ray tracing to find the point where the line intersects the shapes (and itself at some points), it's entirely possible to define how a satin stitch works. The user making a satin stitch would get a shape and a line going through it. But, if you needed, you could change the shape without altering the other values. You could move the line through various different shapes or anything you want, or change the angle of the sweep line anywhere along that path. -- Most of the time you'll want the shape and the line with rays perpendicular to the direction of the angle. But, maybe you want to make part of the edge of the satin stitch with random ends lengths, or change direction at a certain point for a different artistic effect. There's literally endless possibilities and when you treat it like a 2d raytraced physics engine you can get all of those, whereas if you treat them like satin-stitch objects you're going to lose a lot.

If you were to do a font that had serifs or had spurs, how would the program know when to make those serifs and/or spurs apart of the neighboring object or their own separate section of the letter? Depending on the situation, determines which one is the best.

It would take a guess or pick one way to fit all, and let you easily redefine it, or let you fill in those satin stitches in any way you want. There's a lot of conditions where a good digitizer is going to do something the program wouldn't consider, or have a trick for how they want it to happen. There's an amazing amount of skill there, and even for basic glyphs there's a countless number of ways to fill in even a single layer. And rather than fully pre-digitized fonts or whatnot, it would take a guess at the higher level stuff but it would build it with lower level sequenced objects. So given the glyph you could fill the shapes in yourself, in any of these manners. You would have the ability to define the path you take, and you would be using a satin line but the shape you're actually filling doesn't matter to the line you're using, it just draws itself perpendicular to the line/curve. Clearly any font would need to take a solid guess of how it should be filled, but if you have the underlying physics of how embroidery works, and you can define the mathematically properties of a sweep line, regardless whether that is actually a sweepable polygon or not.

Even in blending, you might have one angle for this one section over here, but the section right next to it is a different angle and so on. Some may share the exact same angle, just not be right next to each other.

There's a number of other solutions. Like bending the angle so that they match as a progressive thing. You could at one edge bend the stitches to conform to the correct angle for blending, and could look pretty interesting. But, since my "reinventing the wheel" stuff wouldn't be giving you 80 zillion different properties of different objects and fills, it would rather be defined in terms of 2d physics. I'm raytracing to find where individual scan lines intersects with a boundary (rather than using a predefined closed vector shape) the code to simply bend the angle would trivial, namely, if I am in this area, I should increment my angle.

While an auto conversion module may pick different angles for different sections, it's rare that they get the best angle for that particular section.

Yes. It's so rare that I don't even care to try to nail every edge case. Far better is to just give you an angle but let you change it quickly and progressively and at different places, and different ways. That's one of the major advantages of ray tracing. It's typically used in some high end graphics which rather than do vectors and define objects and views and figure that stuff out. It defines a scene and shoots off a ray in a particular direction until something happens to that ray. With 3d graphics it sends off a ray for every pixel of the screen to see what it sees. In the embroidery it will send off the ray to find out where that bit of stitching goes from the defined path that is doing the satin stitch (or flat fill). So the angle it goes at is just an initial guess and can be changed in literally every way possible.

There's a nearly endless number of ways to fill an object with stitches or to just laydown stitches in general. But, these seem to need to be coaxed or helped along into something that works. And I worry that it limits the art and skill of digitizers.

Not always dealing with closed vector shapes. Run stitches are not going to be closed shapes (which if I didn't want to do the blending of the dog manually, that's the tool that I would use), if you are familiar with Wilcom Input/Tool C is directly related to the same type of digitizing as a run stitch (why you can convert between the 2) and that's open vector shape, but it creates satin stitches.

My problem with that is that they are all just stitches. If you define the bigger more algorithm heavy objects in simplest terms in both power and flexibility they should all be the same thing. I believe mathematically they are and you can define a few things less complex than a satin-stitch filled shape or tatsumi filled object and more complex than a run stitch so as to break those objects down, but not down so far as to make them uneditable.

See, this also highlights a big problem that I personally have with auto conversion of anything (and that's not even getting into how it sequences objects on it's own, which I've never seen one do correctly). It's trying to program doing a few things globally to apply to every situation and that just isn't the case.

Which is my objection as well. And when it does it wrong, you either have to do a bunch of work to do it right, or you need to coax it into doing it right, or go in and do those blends by hand or whatnot.

Until someone is able to get AI into the program to learn, to adapt, auto conversion still isn't going to beat a digitizer with a good solid knowledge base of what to do.

Even AI would be hard pressed to do that with the modern incarnations. But, if the point were to get it to nail a photo, I'm done with that problem. A good digitizer is what the program should expect, and it shouldn't limit the possibilities with the tools on offer. Embroidery can do an amazing amount of stuff that embroidery doesn't do.

I, personally, would be just fine if a program just had the manual/semi manual input tools. No lettering module, no auto conversion. Most people that get into the game today, wouldn't, because they didn't learn 23.5 yrs ago (or more) when that was all that we had. They want the quick and easy way.

Touch Embroidery has that now. Though the truth is if you're not an artist, you would be very hard pressed to make something that good. Though, you can do amazing line art with a shape like a cyclocycloid and smudging and rotating various parts. It's pretty far off the beaten path.

The methods that I use also translate to other programs, not just Wilcom. When one deals with auto conversion, those toolset tend to change (naming scheme always changes between programs, I hate that), options that it has etc.

Yeah, but consider the parts that don't change. And what do you suppose is the smallest most usable elements of the embroidery in general. Putting aside all the names etc, What elements of embroidery couldn't be built out of other aspects. Assuming you could do a flawless running stitch to do all the different types of fill, and time was not an issue. What units of embroidery would be useful to you? Do these elements of embroidery need a shape? What is the actual purposes of embroidery shapes for the embroidery. And does the use of shapes embroidery programs actually conform well to these purposes. If you were describing what you wanted the embroidery to do, and how the machine should sew the embroidery out, would you define what you want in similar terms to how you would produce those results? -- These questions lead me to a somewhat radical answer, but maybe you'd even have another answer I missed or better grasp of the issues at hand.

[wwderw]

In reality these are all variations of run.

I was pretty sure that you would respond the way that you did, that's why I tried to phrase my question as I did. I'm needing different info to see where you are going with this, which you didn't give.

Which is my objection as well. And when it does it wrong, you either have to do a bunch of work to do it right, or you need to coax it into doing it right, or go in and do those blends by hand or whatnot.

Which is why I don't mess with it at all. Period, the end. It is far easier (and quicker) for me to do it my way from the get go, then to give this a try. Even doing one stitch at a time.

Assuming you could do a flawless running stitch to do all the different types of fill, and time was not an issue. What units of embroidery would be useful to you?

If time wasn't the issue. I would just need 1 tool. Manual input. 1 mouse click equal 1 needle insertion. More precise then even the run tool. That's it. Nothing else. I can do everything else with that 1 tool.

That would be all that I need. Now when you factor in time constraints, as a freelancer, there are other things that I would like to have to help become more efficient, but still are tools that only deal with direct user input.

Now, if it was a perfect world and I could get the software (and this is in terms of Wilcom just to make things easier, I'm using one standard, other programs may/may not have the same thing, just named differently):

1. Object based digitizing (and since it would be object based, be able to reshape after the form was created as well and change various properties on the fly (start/end points being one).

2. Portable (in every sense of the term), prefer be able to use on mult-arch (x86, ARM) (Not a fan of cloud based at all).

3. Manual Tools (1 Pass, 3 Pass)

4. Semi-Manual Tools (Input/Tool A, C, Fusion Fill, Complex Fill)

5. Stitch List to apply functions at very specific stitch points (of course, that would mean support for functions for various machines (freelancer, I have to be able to support and export to various formats), sequin functionality would be one of those functions that I would need to have, but boring etc, I wouldn't, but that's very specific to me)

6. Object Properties (including but not limited to, density, pull comp, underlay etc)

Now, that's all the same ole, same ole. I'm sure that's a paradigm that you don't care for. I've been doing this for 23.5 yrs, ever since I was 14 and working in my mom's shop just digitizing text. I'm beyond hope in changing. I don't do photo digitizing at all. It's not something that fits how I do things. That functionality is wasted on me.

Now if that extra functionality is in the program, that's fine, that doesn't bother me, but if that's the only functionality that it is, then that's where I go on to something else. It might get to the point where I would dabble in it, if I felt more confident in it's results, but again, if I also had those manual/semi-manual tools, I'm able to do it myself if I need to.

I doubt I'll ever be able to get the above. I wish I could code, but I can't and embroidery software is very much a niche market, so not a lot of projects for it. The fact that it also require hardware that isn't consistent among the different brands doesn't help either.

I often wondered what has stalled the Embroiderymodder portion of this project. Like I said, I can't code, but I could help with testing (if that is/has been a hurdle for the project). I don't know if Josh would want to comment one way or the other on that, but I wouldn't mind knowing if he is willing to say and if there is something that I could help with that project, I would do my best to. I really would like to see something come into fruition that is stable and usable.

[tatarize]

Portable (in every sense of the term), prefer be able to use on mult-arch (x86, ARM) (Not a fan of cloud based at all).

My code is largely Android these days. So without open sourcing it, the multi-arch bit is basically a non-starter.

Manual Tools (1 Pass, 3 Pass)

By 3 pass you mean bean stitch when you jump back to the previous needle penetration and back with the current needle penetration? I mostly have those, but I could make them more overt, and add a tool to add points in that even more basic manner.

Semi-Manual Tools (Input/Tool A, C, Fusion Fill, Complex Fill)

Totally doable.

Stitch List to apply functions at very specific stitch points (of course, that would mean support for functions for various machines (freelancer, I have to be able to support and export to various formats), sequin functionality would be one of those functions that I would need to have, but boring etc, I wouldn't, but that's very specific to me)

Based on your suggestions I've added a lot of that to MobileViewer. It wouldn't be that hard to edit individual stitches in the list. I have it currently just listing all the stitches and what they are called.

Object based digitizing (and since it would be object based, be able to reshape after the form was created as well and change various properties on the fly (start/end points being one).

This I am planning on adding this, though I still want to make it slightly different under the hood. And build it out of smaller building blocks that are more mathematically sound.

Object Properties (including but not limited to, density, pull comp, underlay etc)

Density is an explicit property of a fill, underlay though is usually just a different type of low density fill that goes on first. These would all in programmatically but you'd still be able to adjust them at the more basic level. Like move the underlay you added to the object to underlay several objects first then the primary fill. A lot of these object property things lead to sequences of lower level events. Like the ordering and subdivision of the monotone polygons for a flat fill or the underlay, and which objects get underlay and when.

You can't really beat it for laying down stitches quickly, but I daresay you could easily beat it for knowing correctly how you should do those things.

The only thing I figured for pull comp would be to actually calculate the supposed location and the pulled locations and move the stitch when the pulled location goes over a specific threshold. If I am not actually treating objects like objects it's a bit hard to progressively change the lengths of the fill. But, you can simulate the entire embroidery and do the pull comp holistically. If you know the first stitch is exactly where you put it, but the second stitch is ever so slightly tugs the first stitch, and the third stitch etc. And it depends on fabric and sometimes the direction of the fabric, but that'd actually be easier and more accurate if you solved the fabric physics for the general case rather than on a per-object basis with progressively adding more pull comp for the later elements etc. You could certainly calculate where a location is if it's moved ever so slightly by all the hard angle pulls around it. Oddly enough it relates a bit to some problems in particle dynamics and perturbation theory. But, it would more properly account for pull when two different objects are near each other rather than just pull within objects and progressively through the embroidery.

There might be more to this though that I haven't thought of, but it seems like if you know how your fabric will react to being pulled you can solve this globally rather than tweaking objects. I don't really know if there's some secondary problems this would solve or create, tho.

[wwderw]

My code is largely Android these days. So without open sourcing it, the multi-arch bit is basically a non-starter.

To me, especially being in what appears to be to be a transitional phase between archs, I would like to have something that behaves the same way on 2 different platforms in case one does eventually usurp the other, there isn't a learning curve and hopefully they have parity with functionality as well.

It seems to me (and this is just my experience) that ARM versions are more stripped down versions (not all the time, but if they have an x86 version, they tend to be).

Worse comes to worse, it'll be Qemu for me, but ARM would have to get more resources then what I've currently seen to handle that smoothly.

By 3 pass you mean bean stitch when you jump back to the previous needle penetration and back with the current needle penetration?

No, beanstitch/backstitch (depending on software) is a different type of run stitch. 3 pass would just be like a regular single pass, but instead of just doing 1, it would do 3. More of a time saving function.

There might be more to this though that I haven't thought of, but it seems like if you know how your fabric will react to being pulled you can solve this globally rather than tweaking objects.

To me, I would rather tweak individually then globally. Depending on the sequence and where the object is in that sequence, it's density values etc, pull comp would vary on an individual bases. Trying to apply it globally may lead to some inconsistencies.

Although, with the manual and semi manual tools fully flushed out, pull comp can be adjusted for during the digitizing process, so there may not actually be a need for that explicit functionality except for those that expect it to be there.

[tatarize]

It seems to me (and this is just my experience) that ARM versions are more stripped down versions (not all the time, but if they have an x86 version, they tend to be).

The differences are more pronounced because android has touch screen stuff, so you can do some input modes with it that are simply not a thing elsewhere, especially multi-touch features.

They are likely similar code bases which means they aren't optimized for it. There's also some limitations to the speed of drawing, as well as the memory present in most android devices. But, embroidery software has been around for ages so you'd be dealing with the x86 power you would have had back in like 2002.

I've done some things like attract point tools, that required solving things like a nearest neighbor algorithm for a lot of points and had to custom write new algorithms to be able to solve them in real time, when any reasonable device would have had any reasonable algorithm out of the box solve things.

No, beanstitch/backstitch (depending on software) is a different type of run stitch. 3 pass would just be like a regular single pass, but instead of just doing 1, it would do 3. More of a time saving function.

Why not a 2 pass. Just start from the end, go back to the beginning and back to the end again? I guess endpoints matter, for how you arrange things. In graph theory terms if you doubled every pass every line would be a loop and you could draw anything off anything without any regard for end points because you could always transverse the graph because it's purely Eulerian. It might make for an interesting tool for no-cut drawing. I guess I'll add it to my pile of interesting but generally worthless tool ideas like non-crossing running stitches via 2-opt swapping.

To me, I would rather tweak individually then globally. Depending on the sequence and where the object is in that sequence, it's density values etc, pull comp would vary on an individual bases. Trying to apply it globally may lead to some inconsistencies.

In theory you shouldn't have to do anything. If how the fabric reacts is a knowable thing, and generally it is, you can simply have the real position and pulled position accounted for. Imagine if you laid out a grid of points, mapped the pulling of the fabric over time as the embroidery goes forward, then you tugged those points according to the typical pull of the fabric by the thread. You could very much figure out, as the embroidery is applied how it would move expected positions of those points. It would by the very nature of the calculation apply more pull for the density value and where it is in the sequence and everything else. You could simply map out where you want the points on the idealized non-pulled fabric, and have what basically amounts to a physics simulation figure out where those points will end up and correct for that. Or rather, solve it backwards and figure out where you need to put that needle in the first place to have it end up at that particular location by the end. You could then easily have the algorithm solve for a different fabric using the same initial design.

[wwderw]

The differences are more pronounced because android has touch screen stuff, so you can do some input modes with it that are simply not a thing elsewhere, especially multi-touch features.

There are multi-touch "stuff" for x86 versions of embroidery software as well. Main reason why I scrimped for the touch version of my cintiq to take advantage of those.

Why not a 2 pass. Just start from the end, go back to the beginning and back to the end again? I guess endpoints matter, for how you arrange things.

Yes, end points very much do matter for sequencing and making sure a pattern is production ready. There are very different needs from someone doing 1 item of something versus someone that is doing 20, 40, 80 etc of something.

It has to look good, but it can't cost them time on the production room floor. The amount of trims and the time that it takes to get back up to speed add up really quickly. Especially if the machine is on the higher end of that time it takes to "recover". Now some patterns production would take a back seat, but you still want it to be as production friendly for the type of design that you are doing.

In theory you shouldn't have to do anything. If how the fabric reacts is a knowable thing, and generally it is, you can simply have the real position and pulled position accounted for.

"In theory", maybe, unfortunately what is theory and what is real world don't always coincide.

Fabric in general terms, is somewhat knowable. Unfortunately, something as simple as one company's twill isn't the same as another's twill (this isn't even taken into account how some people want one file to work on a variety of substrates, so there are "compromise settings" that need to be used to help it work for both). That's not even going into needle sizes, thread weights, specialty thread etc that might change from one section to another.

Now, some production shops don't change anything at all. It's 75/11, 40# all day long. Some do.

Some of this may not be quite as necessary, if the end user is dealing with their own stuff. Once it's being used by a freelancer (which is what I am), that's when a lot of things are up for grabs and I firmly believe "better to have it and not need it then to need it and not have it."

[tatarize]

"In theory", maybe, unfortunately what is theory and what is real world don't always coincide

In theory, theory and practice are the same. In practice, they aren't.

I still think that idea as a stand-alone has a lot of potential, though it's oddly pretty low on my list of things to implement.

[tatarize]

Fabric in general terms, is somewhat knowable. Unfortunately, something as simple as one company's twill isn't the same as another's twill (this isn't even taken into account how some people want one file to work on a variety of substrates, so there are "compromise settings" that need to be used to help it work for both). That's not even going into needle sizes, thread weights, specialty thread etc that might change from one section to another.

You should, in theory, be able to account for all of these one time and just change the output to counteract the pulling of the fabric, and even change that when you change fabric or or backing or substrate or thread weight so long as you know what that would do to the fabric more or less. You could just adjust the pull as a global thing regardless of the underlying embroidery pattern.

[tatarize]

Pull comps the most iffy in my method because it's typically built into the fills. I could allow an adjustment of of it by fill, since the fills and the shapes are going to be completely independent. It wouldn't be hard to tweak the fill to be a bit longer or shorter than the edge as a static thing. But, I could certainly get the rest of those things done in a version or two.