Internal colour representation

[t0mpr1c3]

As Chris mentioned (#297) the internal concept of colour, as implemented in ayab.plugins.ayab_plugin.ayab_image, is represented as bands of greyscale brightness.

I haven't tested it, but presumably this would not distinguish between e.g. cyan 0xFFFF00, magenta 0xFF00FF, and yellow 0x00FFFF,

It probably works fine most of the time but it does look like the type of kludge that we should probably get away from before releasing a 1.0.0 version.

Chris's suggestion of a hard limit of 4 or 6 colours seems sensible, and these few colours could be represented by integer values just as they are now, with a simple lookup table for the RGB values.

More generally, I am concerned that the reliance on a one-byte-per-stitch matrix (plus a few knitting modes) as a representation of the knitting pattern essentially restricts AYAB to rectangles of stocking stitch, in contrast to more flexible formats discussed elsewhere e.g. #299. Changing the internal representation wholesale would clearly be a massive refactoring, but as I mentioned in that thread, a more abstract representation would offer considerable advantages.

[dl1com]

I am open for a versatile concept for this. The AYABImage class has to be refactored anyway, so we can use this as a chance to make it future-proof as well.

[t0mpr1c3]

What's the most useful way I can contribute at the moment? I've been adding little features, just because that is fairly easy to do, but I would be happy to attempt some of the heavier tasks.

[dl1com]

What's the most useful way I can contribute at the moment? I've been adding little features, just because that is fairly easy to do, but I would be happy to attempt some of the heavier tasks.

Probably we should handle #299 first, so we have a consolidated set of requirements for a holistic pattern representation, i.e. which properties of a pattern have to be handled inside the software (colors, shape, carriage, instructions, ...). Then we can dive into re-implementation of AYABImage (perhaps AYABPattern by then).
As you are definitely closer to the topic of knitting and you already made up your mind a bit about a knitting pattern format, I propose that you document some of your thoughts and (high level) requirements into #299. What do you think?

[t0mpr1c3]

Yes, I think that's a good suggestion.

[t0mpr1c3]

Following up, it looks like AYAB currently knits the palest colour first and the darkest colour last. So, if you are designing a multicolour pattern, you can choose the order in which colours are knit by changing the colours to greyscale. White will be knit first, and black last. To me it seems like a kludge, but it is potentially useful.

If we were to switch to using real colours for the internal representation, the user would not have this option. Should the user be have an option to choose the background colour by some other means?

[dl1com]

If we were to switch to using real colours for the internal representation, the user would not have this option. Should the user be have an option to choose the background colour by some other means?

If we would identify the amount of colors in the image and classify them into "quantified" colors (amount of quantified colors = amount of colors we want to knit with), we could show these colors to the user and let them choose which is the background color.

(What I mean by quantification: We would expect a coloured image to have only a certain amount of colors (as many colours as we want to knit with). But we could allow to load images with an arbitrary amount of colours. Rather, we do a quantification of the colors used in the image to boil down the amount of colors in the image to the amount specified by the user to knit with. e.g. this would handle colour deviation due to image compression.)

[t0mpr1c3]

I think simple median smoothing would be sufficient to get rid of compression artifacts. Pillow.histogram() afterwards should show thresholding.

…

On Sun, 7 Jun 2020, 06:02 chris007de, ***@***.***> wrote: If we were to switch to using real colours for the internal representation, the user would not have this option. Should the user be have an option to choose the background colour by some other means? If we would identify the amount of colors in the image and classify them into "quantified" colors (amount of quantified colors = amount of colors we want to knit with), we could show these colors to the user and let them choose which is the background color. (What I mean by quantification: We would expect a coloured image to have only a certain amount of colors (as many colours as we want to knit with). But we could allow to load images with an arbitrary amount of colours. Rather, we do a quantification of the colors used in the image to boil down the amount of colors in the image to the amount specified by the user to knit with. e.g. this would handle colour deviation due to image compression.) — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#308 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAM63QTVD73IF2MTVXXAAD3RVNQSLANCNFSM4NRAL2EA> .

[t0mpr1c3]

Pull request #313

Uses Image.quantize() to restrict the number of colours, Image.mode 'P' to represent colours, and frequency instead of lightness to determine the background colour.