Scratching that itch
Image created from .jef file
When I wrote my last blog, “When you have an itch to scratch….” (http://lydgate.org/blogs/?p=17) it was with a forlorn hope. It seemed to me that my need was not a common one, so it was unlikely that anyone would be interested, particularly since I could give little or no information to help a project get started. I should have had more faith in the world of FOSS.
Two people initially showed particular interest. Purple-bobby did some interesting work to start off (http://purple-bobby.co.uk/JEFView/), but has not developed it further. Maybe he didn’t have time or lost interest, or maybe I was just too slow in responding to him. The other person was David Boddie, who started a python project that seems to have good potential.
Identifying the part of a .jef file that contains the stitch-out was the quick bit. Once that was done, scaled display followed, using jef2png.py. For that to be really useful, it was necessary to identify the colours used. Between us, we have examined hundreds of patterns, and have identified almost every shade used in patterns. Hopefully the last handful will be found in the next week or so. You can see the changelog at http://bitbucket.org/dboddie/python-showjef/overview/ . David uses Mercurial, so it’s easy to keep up with his changes, and by downloading free JEF patterns from the web you can see his progress. One caveat – we have found a few patterns that don’t use the colour-definitions that seem to be otherwise standard. Until we find a common denominator it’s hard to do much about that. The good news is that of my hundreds of stored patterns only three or four have this problem.
After all David’s work, it would be really nice if we could find a collaborator to turn this into a KDE-Other project. Maybe now purple-bobby knows that we haven’t lost interest he might join us? Maybe it’s just pricked your interest enough to talk about how this can be done.
We don’t have much in the way of hobby applications. I’d like to see that addressed. Wendy van Craen says she’d like to see someone working on a crochet pattern creator. I know we have knitters among KDE contributors, and while the language of knitting varies enormously between countries, it’s not that hard to represent stitches in a kind of ascii art. Something that could create and store modules for stitch patterns and combine them would be great. KrossWordPuzzle 0.7.4 has just been announced, and how about creating some KrossNumberPuzzles? What about koffice templates for gardeners? Keeping track of plant collections, or tracking sowing, planting out, harvesting? I can see possibilities for databases and for spreadsheet templates. What other hobbies could we benefit?
So – hobbyist KDE section? I think it is more than possible.
11 Comments
RSS feed for comments on this post.
Sorry, the comment form is closed at this time.
There is a stitch editor out there: http://kxstitch.sourceforge.net/
It looks like it’s getting the KDE4 treatment now. Was KDE3 for the longest time.
@Ben Boeckel: It seemed to have little love for quite a long time, but looks as though it’s coming back nicely. I’ve already downloaded it and hope to learn about it this week. I hadn’t considered it for userbase until I saw the recent developments.
Like it. I’ve been thinking about the planting / garden planner / diary idea but have no serious programming experience. It’s a hobbyist thing itself…
Maybe I should put my idea up on the forum, see if it flies.
@stantontas: I’d like to kick that idea around with you first. Maybe we don’t need programming skills for this. Again, the first thing would be to define the aims. It could be a reasonably simple spreadsheet template, or a complex database, depending on what we want to achieve. Let’s get some ideas together before we toss it into the wild 🙂 (BTW, my email address seems to have gathered an extraneous final ‘k’. Take that out if you contact me.)
I start college on the 5th October, I’m not sure how much spare time I will have. I saw the original file decoding as a puzzle, like a useful Sudoku.
I assume David has given you the Preview you initially asked for. And David has given a lot more to those that follow.
I would need a stronger/clearer vision of what you want. Without which the tool would turn into an useless monster with too many options and too much configuration. Having said that, it is useful to have some sort of open universe object that can be mashed up in new ways.
Ideally, there would be a bunch of widgets/services that translate a file into an open format (i.e. give you a preview of the file). This open format could be viewed in another format/representation to be used elsewhere. The danger is your open/universal format becomes a monster. There is a skill (that I’m not sure I have) of choosing whether to develop a closed or open universe object/model – the closed universe object typically does one thing well, has few options/parameters, has fixed input/output formats – the open universe object is more general. There are kind of wrappers/adaptors that let you use one type of object in the others universe. A typical analogy, is a car: engine bay at the front, boot/trunk at the back – only a limited range of engines can go in the engine bay, but with the right wrapping many engines and other things can go in the boot/trunk. I’ve mentally wandered off…
What I was thinking, take (Dolphin) file-manager, you have an embroidery pattern (file/folder), with meta data available (such as preview, title, author, copyright, thread colours used…) for inspection/searching, then somehow you can copy/use it as a SVG, PNG, JEF, other embroidery format, etc. without thinking about it – the different representations are available by hidden services and the destination indicates the acceptable representation(s), as you use the file the correct representation is used. There is the problem of information loss – you can represent the same music as a score or as a recording of a performance. On my KDE system, when I pop in a music CD, I can copy the tracks in various formats – there is an Ogg folder, a WAV folder, a FLAC folder, an MP3 folder, etc. – but they do not exist on the CD, when you use the FLAC track it is converted on the fly.
@purple-bobby: Some really interesting thoughts there. To avoid your ‘monster’ being created, I think we need a roadmap – and I can offer little help there as I don’t have the practical programming skills to break the ideas into discreet tasks – and the determination to tackle a single idea at a time. But in the end, I’m not the one doing the major work, so it’s not my decision.
My main interest was also the challenge of figuring out the file format. Unlike the formats I’ve looked at before, I didn’t have any files to start with or tools to manipulate them, so that added an interesting twist to the exercise.
Right now, I’m trying not to think about the other embroidery formats (though it’s tempting to look at those), and instead just concentrate on understanding this one to get a decent representation of it – ideally one that describes everything in any given file.
At some point, I think it’s possible to start doing interesting things with the data, like write thumbnail generators for Dolphin or a tool for generating SVGs, or build some kind of conversion framework around it.
It’s certainly interesting to ask what people would do with the data and how they want to access it. Are thumbnails good enough or do people want to edit the data. Can we understand the format well enough to be able to write files correctly as well as read them?
@David Boddie: To be able to edit them would be wonderful, but probably a longer-term project.
As a discussion point/example of the monster appearing…
Say a application was developed to create embroidery from bitmap images – area filling, between fill area thread hiding, etc. algorithms were developed.
Most bitmap images have the potential to have as many different colours as pixels – a 2″ (50.8 mm) square image at 96 dpi could have 36,864 different colours.
So, a dozen different algorithms are created to compress the colour space, and some compression parameters control more or less compression. Now when the user loads the image, then number of different colours is counted, there is a setting that allows the user to choose the maximum number of thread changes, when the number of counted colours exceeds the maximum thread changes setting, a wizard pops up and asks the user which colour space algorithm they wish to use, what compression parameters they want to use, when the number of colours in the compressed colour space is less than the number of thread changes, they are allowed to finish the wizard.
The wizard proves hard to use, the users do not understand colour spaces, so great work is done providing graphical tools to explain the colour space algorithms, showing how the parameters affect it. The users are not happy, but can cope with the wizard.
Then is discovered that sometimes there are more thread changes than colours (the same colour is used twice), and the wizard is not reducing the number of colours enough. Also, the embroidery looks terrible. Out comes the metaphoric sticky tape again.
This hypothetical example, is intended to show, that it very easy to solve the wrong problems, and provide complex user interfaces to those solutions. The developers mind explodes with possible goals and solutions to those goals, and the need to allow the user to control it all.
There is also this problem, an application may give the user some work to do, and the user feels they are working and making progress (steps of the wizard being completed), but in actual fact the application could guess all (the wizard) inputs and be right 99% of the time, the user just have to wait a short while, now the user feels that they are not doing any work and being held up by the application. You (sometimes) find when a Windows person tries to do a task on KDE/Linux, they are looking to enter all those next clicks on a wizard, when KDE/Linux has already done it for them, they then mess it up in the geeky settings manager, trying to get that fulfilment the wizard gave them.
@purple-bobby: I don’t think we should be aiming at re-creating what the commercial embroidery packages do. When we buy the machines (and heaven knows they cost enough) they come with both software to edit the patterns, and software embedded to translate them into machine-readable instructions. Of course it would be nice of the editing software was native linux, but some of it at least runs under wine. In the case of the Janome patterns, though, the Gallery view, along with some more complex design tools, is protected by a USB dongle. The user in the end may have to decide to stick with windows if he/she wants to use the complex design software. Viewing, though, should not have to depend on windows.
The ideal, in my opinion, would be a plugin to dolphin, so that previews could be seen just as image previews are. Next best is to be able to run a script that takes every .jef file in a directory and creates a thumbnail for it, viewable in dolphin. That alone would make using the patterns so much easier. If then a simple gui could be designed to collect the source directory and offer a run button, that would be great. Assuming all that could be done, could it be extended to other machine pattern formats? Of course making it cross-platform would then make it extremely useful, and at that point we need to contact needlework and craft magazines to publicise it. Ambitious?
KrossWordPuzzle 0.14 now supports Number Puzzles And Crossnumbers 🙂 Also possible are swedish and american crosswords.