Der von mit bereits erwähnte Ami, edr z.Zt fast täglich neue Videos zu Inkstitch produziert nutzt eine semiprofessionelle Maschine mit 8 Nadeln und DST Format...irgendwie müssen die Farbwechsel ja mitgeteilt werden.
Farbwechsel schon, aber DST beinhaltet keine Info über die verwendete Garnfarbe ... wie im professionellen Bereich üblich muss man für das Setup der Maschine eben andere Quellen nutzen (z. B. ein Farb-Sheet des Erstellers). Gilt so auch für EXP, KSM...
Mattes
Es ist immer das gleiche mit dem Vorführeffekt, im entscheidenen Moment funzt et net so wie gewünscht 
zum "A":
Alle 4 Segmente wurden mit dem Knotenwerkzeug/Bezier) im Modus "Erstelle Spiro-Pfad" (2. icon von links) automatisch der Vorlage folgend erstellt. Die Pfade ließen sich kombinieren und satinieren. Da mir das Stichbild vom 3. Segment (A-Bogen oben lnks) nicht gefiel, habe ich einige "Sprossen" eingefügt. Sobald ich diese combine, verändert sich der Pfad und zwischen den obersten zwei Knoten wird ein Schlenker eingefügt (oberes rechtes Bild).
zum "J":
unteres linkes Bild, im SVG ist es das RECHTE..
Hier habe ich die Pfade herkömmlich erstellt, also einige Knoten entlang der Außenlinie verteilt und mittels Anfassern und Linienklicks geformt. Alles supi, lässt sich combinen, prima Stichbild.
unteres rechtes Bild, im SVG das LINKE "J"
Spiro-Pfad, combine, PLUMPS.
CTRL-Z, das gleiche nochmal, combine klappt plötzlich, dafür aber kein satin.
Ungleiche Anzahl Knoten auf Außenlinie oder ungerade Anzahl Knoten oder, oder...
Farbwechsel schon, aber DST beinhaltet keine Info über die verwendete Garnfarbe ...
Wozu? Es ist doch letztlich eine Sache der/s Bedienerin/s welche Farbe wo eingespannt wird. Wenn's beliebt halt mokkabraun anstelle von grasgrün.
Zwischenbericht:
Ich habe mittlerweile ausprobiert eine .pes zu speichern und diese habe ich dann mit dem gelieferten Programm von Pfaff in eine .v3 umgewandelt.
Die Fadentrennung wird jetzt erkannt. Automatisch macht es aber nur bei einem Gruppenwechsel. Sind die Objekte nicht in einer neuen Gruppe, dann fordert zumindest das Gerät auf den Faden manuell zu trennen.
Damit kann ich erst mal leben 
@bianchifan
Achso ja, Spiro kenne ich. Du könntest versuchen, deine Spiro-Pfade nach Fertigstellung mit Strg+Umschalt+C (oder Pfad > Objekt zu Pfad) in "echte" Pfade umzuwandeln. Ich denke, dann sind sie nicht mehr so widerspenstig. Wenn du einen "Nicht-Spiropfad" mit einem Spiropfad kombinierst, dann weiß Inkscape nicht mehr, ob er den Effekt anwenden soll oder nicht. Deshalb nimmt er den Effekt raus und du erhälst die "Ursprungslinie" ohne Spiro-Effekt. Aber wenn du das vorher in einen Pfad umwandelst, sollte es klappen.
Ja genau, Farbwechsel sind natürlich in jedem Dateiformat enthalten. Manche Maschinen zeigen dir ja an, welche Farbe als nächstes kommt. Natürlich kannst du trotzdem nehmen was du willst. Aber manchmal hilft die richtige Farbanzeige den Überbblick zu behalten. dst können die meisten Maschinen verstehen.
Toll, danke für die Rückmeldung!!
Du könntest versuchen, deine Spiro-Pfade nach Fertigstellung mit Strg+Umschalt+C (oder Pfad > Objekt zu Pfad) in "echte" Pfade umzuwandeln.
Keine "echten" Pfade..., hmm auf die Idee hätte ich vielleicht auch kommen können..
Wenn du einen "Nicht-Spiropfad" mit einem Spiropfad kombinierst, dann weiß Inkscape nicht mehr, ob er den Effekt anwenden soll oder nicht. Deshalb nimmt er den Effekt raus und du erhälst die "Ursprungslinie" ohne Spiro-Effekt.
Jedenfalls weiß ich nun wieder, wieso mir die Existenz dieser "Pfade" entfallen war..
mein Plotter versteht zum Glück svg-Dateien direkt.
???
Was ist das denn für ein tolles Gerät?
Neben HPGL und GPGL ist mir eigentlich nur der Roland Propri Kram bekannt.
Am WE bin ich dazu gekommen, meine erstes "echtes" Stick-SVG zu erstellen. Hat länger gedauert es erwartet, da ich bei der einzigen Füllfläche wohl ingendwie unbemerkt die Konturfarbe aktiviert hatte und die unterschiedlichen Fehlermeldungen komplett anders interpretiert hatte.
Apropos Fehlermeldungen, bei einigen eklatanten Problemen wird dafür eine eigene Ebene oben drauf geschaufelt mit wahrhaft riesigen roten Pfeilspitzen, Pointers oder was auch immer. Leider ist auch die Schrift ziemlich groß und offenbar werden mehrere Zeilen in einander geschoben. Für mich ist der Inhalt dann unleserlich.
Eine zweite Auffälligkeit ist die Konvertierung von Linien in Satinstichbahnen. Da gab es immer eine deutliche Verbreiterung. Die Ursprungslinien waren allerdings recht schmal, 1mm (Schrift) und 1,3mm (Umrandung).
Was ist das denn für ein tolles Gerät?
Ein Brother ScanNCut. Die können das alle. Der kostet zwar ein wenig mehr als die Silhouette Geräte, aber mir war das mit den svg-Dateien schon wichtig.
die unterschiedlichen Fehlermeldungen komplett anders interpretiert hatte
Gibt es da in Ink/Stitch Verbesserungsbedarf in dieser Richtung? Kann man da besser zum Ergebnis leiten?
Hast du ein Screenshot von dieser fiesen, großen Troubleshoot-Darstellung? Das hört sich ja schrecklich an. Seltsam, bisher habe ich noch nie Beschwerden in diese Richtung gehört.
Linie zu Satin... meinst du, die Satinkolumne die am Ende rauskommt ist bei dir deutlich breiter als die Urspungslinie?
Ein Brother ScanNCut.
Die Teile hatte ich niemals ernsthaft auf dem Schirm, da sie in Technikforen praktisch nicht vorkamen und der Sihouette (1. Modell) der einzige mit einem Linuxtreiber (inkscape silhouette bzw. robocraft) war.
Hast du ein Screenshot von dieser fiesen, großen Troubleshoot-Darstellung?
Hatte ich, dann aber versehentlich gelöscht. Ich werde schauen, ob ich da was reproduzieren kann.
Linie zu Satin... meinst du, die Satinkolumne die am Ende rauskommt ist bei dir deutlich breiter als die Urspungslinie?
Genau!
Wie bereits erwähnt, die Ausgangslinien waren bereits recht schmal und an der unteren dessen, was lt. Doku bzw. aktuellen Videos praktisch gestickt werden kann.
Meine Vorgehensweise bei der Schrift:
Ausgangspunkt ist ein verblasstes Foto.
Auf einer übergeordneten Ebene wurde ein Text erstellt, danach das Foto ausgeblendet und der Text verblasst.
Der Text wurde mittig per Bezier nach empfunden, geglättet und die entstandene Kurve auf eine Breite von 1mm gestellt und in eine Satinkurve konvertiert, das Ergebnis dann manuell bearbeitet.
Bei der Umrandung wurden über dem Foto Bezierkurven in 1,3mm Breite erstellt, zwei davon liefen "paralell" zu zwei anderen ohne sich jedoch zu berühren. Im konvertierten Produkt lagen die benachbarten Außenlinien übereinander und überschneiden sich teilweise. In der Simulation werden die Linien dann ineinander gestickt , ist im Original übrigens genauso.
Wenn ich die parallelen Satinkolumnen zurück in eine Linie verwandel und die Konturbreite dann auf 1,3mm setze, erhalte ich genau deine Satinkolumnen wieder. Die Breite passt genau. Ich glaube, ich verstehe noch nicht so ganz was da passiert ist. Eine vorher-Datei hast du wahrscheinlich nicht mehr oder?
Beim Sticken legt man ja meist die Stickbereiche mit leichten Überschneidungen an. Sonst entstehen ja nachher Lücken, wenn der Stoff gezogen und gedrückt wird während des Stickens.
Beim Sticken legt man ja meist die Stickbereiche mit leichten Überschneidungen an. Sonst entstehen ja nachher Lücken, wenn der Stoff gezogen und gedrückt wird während des Stickens.
Deswegen ja auch meine Frage, ich war halt verwundert, dass diese Korrektur bereits von inkstitch sozusagen vorausschauend erledigt wurde.
Um bei diesem Beispiel "Sports-Logo" zu bleiben, bei dem P-Bogen dreht die Stichrichtung in einem 90° Winkel, im Ergebnis sind die Stiche auf der Innenseite zu eng gesetzt (in Relation zu einer geraden Strecke) und auf der Außenseite zu licht. Gibt es da eine Möglichkeit zur automatischen Korrektur?
Wenn nicht, manuelle Stichsetzung ist kein Problem 
Hast du ein Screenshot von dieser fiesen, großen Troubleshoot-Darstellung? Das hört sich ja schrecklich an. Seltsam, bisher habe ich noch nie Beschwerden in diese Richtung gehört.
Leider nein, ich war zu sehr mit der Ursachenforschung beschäftigt.
Allerdings konnte ich eine Teilmenge davon anhand der ältestesten noch vorhandenen automatischen Inkscape Sicherungsdatei reproduzieren. Ursächlich war in dem Fall eine Füllfarbe für eine Kontur der Breite "0". Wurde wahrscheinlich versehentlich gesetzt und fällt in inkscape nicht auf, da die Kontur für inkscape nicht vorhanden ist.
Bildschirmfoto vom 2022-01-16 01-13-20.png
Ich habe aber ähnliche Konstellationen in einigen Videos gesehen, erinnern konnte ich mich noch an ein offizielles inkstitch Video zur Schrifterstellung, wo neben mehreren gleichartigen und gegeneinander verschobenen Meldungen eine weitere vorhanden ist, welche ich nicht identifizieren kann.
Bildschirmfoto vom 2022-01-16 00-26-05.jpg
------
Wie ich soeben festgestellt habe, muss ich aber auch mal ein großes Lob loswerden.
Irgendwo hatte ich was von von inkstitch Import-Formaten gelesen und zufällig bin ich bei einer Ordner Reorganisation auf eine fertige Stickdatei gestoßen, genauer gesagt eine zip Datei unbekannter Herkunft, Dragon.zip. Diese Datei enthält 3 unterschiedliche Formate... ALLE drei konnten von inkscape direkt eingelesen und angezeigt werden, das Bild entspricht in etwa der Parameter Vorschau ergänzt um Trimmpunkte e.t.c. Die einzelnen Objekte lassen sich anwählen und nachträglich bearbeiten, großartig!
Ich habe noch ein wenig weiter gegraben und einige "Freebies" gefunden, sogenannte "Heftrahmen".
Eine 10x10 Zip enthält 10 unterschiedliche Formate, von denen 8 von inkscape direkt von Systemebene (Fileselektor, Commander, Terminal...) aus eingelesen können.
Ein Format kann nicht gelesen werden: HUS
Ein Format kann nur gelesen werden, wenn die Datei von Inkscape aus über den "Öffnen"-Dialog angesprochen wird: XXX
Dann aber auch korrekt icl. Trimmpunkt
Apropos Trimmpunkte...
Bei meinen Spielereien mit der Schriftkonvertierung konnte ich über die Inkstitch "Befehls" Erweiterung die Trimmpunkte punkt- bzw. knotengenau setzen, ebenso wie die Startpunkte von z.B. Füllflächen.
Bei der Produktanzeige hingegen wandert die Schere dagegen irgendwo ans bezogene Objekt, oft an den "höchsten" Punkt, manchmal in die Mitte und manchmal einfach irgendwo hin.
Bei importierten Stickformaten auch manchmal irgendwo in die Landschaft.
Der tatsächliche "Trimmpunkt" ist dann nur in der Simulation ersichtlich.
Für den oben bereits erwächten Drachen habe ich mal Bildschirmfotos erstellt, da alle 3 vorhandenen Formate ein unterschiedliches Aussehen zeigen, Bilder sind angehängt.
Aufgefallen ist mir, dass selbst bei dem exsessiv getrimmten "PES" immer noch unnötige Sprungstiche vorhanden sind. Im Foto habe ich das "Objekt 26" angewählt und die zugehörigen Knoten sichtbar gemacht.
Bildschirmfoto vom 2022-01-16 13-18-58.jpg
Der besseren Übersichtlichkeit wegen habe ich zur Demonstration der Bearbeitungsmöglichkeit den hintersten Zahn aus dem "EXP" Format gewählt.
Original
Bildschirmfoto vom 2022-01-16 13-33-30.jpg
Abänderung
Bildschirmfoto vom 2022-01-16 13-46-15.jpg
Wie man sieht, hat man u.U zwar ein wenig Arbeit, man kann dank Inkstitch aber alles gerade rücken, was einem da so an "Unschärfen" unter gejubelt wird.
Und noch etwas, bei den betrachteten Videos ist bei dem "Parameter"-Aufruf praktisch immer unmittelbar ein Bild zu sehen, bei der Simulation dauert es einen Augenblick.
Die Simulation verhält sich bei mir exakt gleich, ein Parameter Aufruf schickt meine Anzeige jedoch für exakt 30sekunden in den Tiefschlaf. Tatsächlich rödelt während dieser Zeit ein CPU-Kern zu 100%, gelegentlich wechseln sich die Kerne auch mal ab oder tanzen miteinander
Bildschirmfoto vom 2022-01-15 17-16-10.jpg
Bildschirmfoto vom 2022-01-15 17-05-13.jpg
Und noch etwas zur Simulation, beim Beenden gibt es praktisch immer eine Fehlermeldung, dass irgendeine inkex-Funktion/Methode veraltet ist. Meistens inkex.etree, meistens deutsch, manchmal englisch.
Letzten Sonntag habe ich eine neue Version entdeckt und gestern installiert. Ein wenig blauäugig hatte ich mich für die deb entschieden.
Anschließend hatte ich etwas Kuddelmuddel, die neue extension hatte sich nach /opt verkrochen, die alte in der .config im ~dir war noch da.
Es wäre wünschenswert, wenn bei einer automatisierten Installation das eventuelle Vorhandensein einer älteren geprüft und die vorherige Beseitigung dieser angeraten würde. Ich kann mir vorstellen, dass der ein oder andere unbefangene Benutzer da evtl. ein weing ratlos sein könnte.
Da ich ja fertige Stickdateien offenbar problemlos einlesen und bearbeiten kann habe ich meine "Sports" SVG einfach mal ins dst-Format konvertiert und erneut wieder eingelesen.
Dabei sind mir leichte Abweichungen zwischen der Simulation und der eingelesenen dst aufgefallen. Signifikant sind sie scharfen Kurfen bzw. Winkeln. Genauer gesagt, überall dort, wo die Stiche auf einer Seite komprimiert und auf der Gegenseite expandiert werden.
Nicht sonderlich gravierend, aber sichtbar, das Stichbild erscheint unruhiger.Mit der neuen Version (2.12) sind die Schwankungen etwas nivelliert und weniger auffällig.
Was genau macht eigentlich die Stichplan-Vorschau?
Meine CPU rödelt ein paar Sekunden, dann erscheint eine neue Ebene mit einigen Objekten, Color 1, Color 2, ... oder so ähnlich und sehen tue ich: Nichts!
ZitatDeswegen ja auch meine Frage, ich war halt verwundert, dass diese Korrektur bereits von inkstitch sozusagen vorausschauend erledigt wurde.
Das tut Ink/Stitch ja auch nicht. Da muss irgendetwas anderes passiert sein. Jedenfalls kann ich das so nicht nachstellen.
ZitatGibt es da eine Möglichkeit zur automatischen Korrektur?
Nein, da müssen dann die Richtungslinien entsprechend von Hand angepasst werden.
ZitatEin Format kann nicht gelesen werden: HUS [...]
Hier ist eine Liste von Formaten, die Ink/Stitch lesen und schreiben kann: https://inkstitch.org/docs/file-formats/
ZitatApropos Trimmpunkte...
Die Schneidpunkte sind eigentlich keine Punkte, sondern Objekte. Sie sagen Ink/Stitch, dass nach dem markierten Objekt der Faden geschnitten werden soll. Wenn du also einen bestimmten Punkt festlegen willst, solltest du das Objekt an dieser Stelle auftrennen.
Die Dateiformate gehen selbst sehr unterschiedlich mit den Trim-Befehlen um. Es wird uns nicht ganz möglich sein, alle Schneidbefehle genauso wie sie gesetzt waren (oder halt auch nicht gesetzt waren) auch wieder einzulesen. An manchen Dateiformaten könnte aber auch noch nachgearbeitet werden.
ZitatUnd noch etwas zur Simulation, beim Beenden gibt es praktisch immer eine Fehlermeldung, dass irgendeine inkex-Funktion/Methode veraltet ist.
Hach ja Zeit für ein Update? Versuche es mal mit Version 2.1.2 ... aber auch da sollten wir bald ein Update hinterherschieben. Es haben sich noch ein paar Fehler eingeschlichen.
Oh, ok. Schon geschehen. Naja, da war ich wohl zu spät
ZitatWas genau macht eigentlich die Stichplan-Vorschau?
Sie gibt das Stickbild aus. Je nach Einstellung auch seitlich der Bildfläche. Vielleicht hilft es nach rechts zu scrollen?
Danke dir für die vielen Screenshots un Anregungen.
Die Dateiformate gehen selbst sehr unterschiedlich mit den Trim-Befehlen um. Es wird uns nicht ganz möglich sein, alle Schneidbefehle genauso wie sie gesetzt waren (oder halt auch nicht gesetzt waren) auch wieder einzulesen.
Okay, vielleicht habe ich das zu blauäugig betrachtst, von den diversen Stickformaten habe ich keine Ahnung.
Es war halt einfach nur eine Feststellung, genau wie die mit dem HUS.
Nein, da müssen dann die Richtungslinien entsprechend von Hand angepasst werden.
Ist für mich auch kein Problem. Hatte ich nur erwähnt, weil es mit ein Grund ist, warum einige Inkstitch nicht nutzen oder sogar abwertend beurteilen.
Manch eine/r möchte ein System auf Knopfdruck, jpg rein und fertige Stickdatei ist nach 20 sec fertig auf dem Stick bzw. via Blauzahn im Stickaggregat.
HUS wird irgendwann kommen. Dauert aber noch ein wenig.
Ja, bei Ink/Stitch ist halt vieles manuell. Das muss man mögen 
Andererseits lernt man so wirklich die Basics der Digitalisierung und weiß dann auch bei weniger manueller Digitalisierung, wo man anschließend nachbessern muss. Die Qualität von Ein-Knopfdruck-Stickdateien ist ja meistens nicht besonders gut, auch wenn man den Wunsch nachvollziehen kann. Aber dafür gibt es ja genug andere Programme, die das können.
Allerdings sieht man auch häufig schlechte Stickergebnisse die aus Ink/Stitch kommen, weil automatisch vektorisierte Randlinien dann nicht als Satinstich, sondern mit Füllung gestickt werden. Satinstiche machen halt doch schon ein wenig mehr Arbeit... aber für ein schöneres Stickergebnis lohnt sich das schon.
Allerdings sieht man auch häufig schlechte Stickergebnisse die aus Ink/Stitch kommen, weil automatisch vektorisierte Randlinien dann nicht als Satinstich, sondern mit Füllung gestickt werden. Satinstiche machen halt doch schon ein wenig mehr Arbeit... aber für ein schöneres Stickergebnis lohnt sich das schon.
Schlechte bzw. ungünstige Stickergebnisse len gelegentlich aber auch bei professionellen Programmen raus, aus welchen Gründen auch immer... sogar bei P&C habe ic schon reduzierte Sweatshirts gesichtet, wo bei der Stickerei nict alles so aussah, wie es hätte sollen
Stichpunkt automatisierte Randlinien..
Zwei Vorschläge für die Version 4.xx, sofern die Entwickler nicht doch irgendwann die Lust verlieren..
1. unterschiedliche Füllmuster, z.B. gegenläufige Satinbänder.
Ich habe in diesem Jahr so einige Blogs gesichtet, da wurden u.a. größere Füllbereiche in Bänder aufgeteilt, welche mit unteschiedlich gerichtetem Satin bestickt waren, das Ergebnis ist ein Fischgrätmuster.
2. ab einer bestimmten Größe automatisch generierte Satinränder
Gestern habe ich mal wieder Eurem Git einen Besuch abgestattet und festgestellt, dass Du externe Videos aufgenommen hast wie Project Anonymus.
Den absoluten Enthusiasten des letzten Jahres hast Du aber leider übersehen: Low Tech Linux
Wirklich tolle Erklärungen gerade zu Satin und den verschiedenen Steuerungsmöglichkeiten, IMHO prädestiniert für Anfänger.
Vergessen...
Offensichtlich bekommt ihr im Laufe dieses Jahres eventuell Konkurrenz: Die Entwicklung vom Embroidermodde wurde wieder aufgenommen und posaunt die Version 2.0 zur Jahresmitte
2. ab einer bestimmten Größe automatisch generierte Satinränder
Kannst du das noch mal genauer beschreiben, was du damit meinst?
Den absoluten Enthusiasten des letzten Jahres hast Du aber leider übersehen: Low Tech Linux
Oh du meine Güte, wie konnte das passieren. Eigentlich war ich der festen Überzeugung, dass dieser Link auch in der Liste war. Danke für die aufmerksame Rückmeldung!
Offensichtlich bekommt ihr im Laufe dieses Jahres eventuell Konkurrenz: Die Entwicklung vom Embroidermodde wurde wieder aufgenommen und posaunt die Version 2.0 zur Jahresmitte
Wow, das ist ja schön. Das hatte ich noch gar nicht mitbekommen. Danke für die Info!!
Kannst du das noch mal genauer beschreiben, was du damit meinst?
Ich hoffe, ich komme im Laufe der Woche oder am nächsten WE dazu, ein Bildchen zu zeichnen.
Hallo ich klinke mich mal ein mit einer etwas anderen Frage. Ich arbeite seit 2 Tagen (!) mit inkstitch und bisher klappt es ganz gut. Ich habe aber ein Problem mit Satinstichen, für dass ich nach einer besseren Lösung suche. Ich sticke mit .jef auf einer elna Stickmaschine. Wenn ich eine in inkscape problemlos erstellte Datei als .jef speichere schmeißt es automatisch alle Satinstiche raus, die länger als 12mm ca sind. Ich frage mich, ob man irgendwo in Inkscape/inkstitch einstellen kann, dass es dafür eine maximale Länge gibt? Jedes mal die Datei zu speichern, dann im anderen Programm (Digitizer junior) zu öffnen um zu gucken, ob irgendwelche Stiche rausgeflogen sind, dann in Inkstitch nachtzubearbeiten usw. bis es dann irgendwann alles passt erscheint mir etwas umständlich. Ich hoffe, mein Problem wurde verständlich.
Falls jemand eine Idee hat, freue ich mich!
PS: die Stichlänge zu Begrenzen geht zwar, dann ist aber alles voller Linien, die so nicht gedacht waren und auch deutlich mehr, als was es für die gewählte Maximallänge bräuchte - ist mein Eindruck.
Sticksoftwares begrenzen Satinstiche - die maximale Stichlänge ist bei den meisten 10mm, alles was drüber ist, bekommt Zwischenstiche. Was z.T. nicht besonders gut aussieht, oft auch Möglichkeit bietet, in den Stichen hängen zu bleiben und die einzelnen Stiche hochzuziehen und evtl. zu zerreißen.
Satinstiche sind also eher dazu, kleinere Flächen zu füllen oder für Randstiche.
Grüßle
Liane
