• A test framework must not change reusability of the project (i.e. not restrict the MIT license further).
• It should provide ways to unit-test the components of the algorithm.
• It should be freely available cross-platform
• It must integrate well with CMake and play along with openCV

Right now, the output is only updated after successful transformation. This should be changed.

• Make the conversion no longer depend on an output path
• On input image load, perform transformation for the current settings
• Turn "select output path" into a Save As... functionality
• Update output preview on settings change and input image load

Limit selection boundaries to actual image size.
Consider pixel number output to status bar or similar.

Right now, the tool is hard-coded to use two colors. There is, however, the possibility to add a third or fourth color to patterns.

• Create Add/Remove buttons to the color panel
• Make colors scrollable
• use dynamically created colors in the UI and/or pixelator update (GUI mode is enough)

What the conversion algorithms can already do must be testable.

So far, the aspect ratio of the image can not be changed.
Pixel width and height depends on the image's width and height and the desired number of rows and columns.

This does not meet the reality of the prime use case. There, height and width of the pixel are more or less all that can't be influenced. There should be a way to determine width and height of pixels as well as a way to choose the part of the image that should get pixelated (in the correct aspect ratio).

The strategy how to do that without creating conflicting constraints is not yet quite clear.

Right now, the selected frame must be drawn as a new rectangle each time. Instead, it should become a set of four edges that can be moved "independently".
As there is no real independence, there are several ways to cope:

• only allow dragging corners
• distribute equally among the adjacent edges (e.g. when moving the left edge of a square 10px to the left, move top edge up by 5 and bottom edge down by 5).
• distribute accordingly to the corresponding position (e.g. when moving the left edge of a square 10px to the left at 20% from the bottom, move up the top edge by 8px and down the bottom edge by 2px).
• "the winner takes it all": if less than 40% from the top, only move up the top edge by 10px, if less than 40% from the bottom, move down the bottom edge by 10px, otherwise distribute equally.

This should be possible to avoid tedious fixing of small errors when cutting the desired piece of image.

If a large section of an image is single-colored, it is very hard to detect how many stixels there are.

• Draw stixel separators onto the output window
• Select appropriate colors for stixel separators
• Make colors and/or sectioning of stixels configurable (highlight every Nth stixel separator)

Basically, setting up GitHub actions is a lot easier when there's a test server that can be set up with requirements up-front.

This means setting up a host to run the Jenkins instance on, making it listen to the repo, and setting up corresponding Jenkins jobs.

Right now, colors are computed as points in a 3D HSV cone space, and their likeness is computed as the distance between two of those points.
However, as soon as all of them have full saturation, the result is very, very poor. Either it's mainly about the relation between saturation and value, or the curve must not be direct (but rather spiraling or going around edges).
This will likely require further investigation.

Also, this relates to #34, where the image processing functionality should be rendered testable with automatic testing.

It must be possible to give around 20-30 different colors with minimal effort.
The pixelator already receives a vector of colors, therefore the interface should not cause too much trouble.

• Figure out what GitHub Actions actually do
• Figure out how to use GitHub Actions
• Check usage possibilities for testing
• Implement what is possible
• Incorporate that with contribution work flows

What different shapes of stitches are there? How are they documented in patterns? What should the output be for a notation that advanced stitchers will be able to read?

Does this qualify as a reason to introduce a third preview window (or a different output than preview) for cross-stitch mode?

-> should spawn further activity in that direction.

Most probably, the menu should be turned into a ribbon with the three buttons instead.
They could also use some icons.

Either introduce a tab structure with one tab per measurement set or a combination of drop-down mode selection that updates the size panel.

The result size settings should be interesting for all types of needlework, therefore only the other measurements should be variable.
Simple cross-stitching assumes square stitches with configurable mesh size. The stixel separators can stay in place, as the resulting stitch squares are still rectangular.

If the to_pixels method gets divided into invocations of helper functions, it is possible to generate unit tests checking the results of each. Therefore, the unit tests become less black boxed, and the method becomes more reliable.

Right now, it is virtually impossible to tell anything about the internal processes within the LogStream class.

Therefore, the unit tests aren't capable of detecting anything that could go right or wrong within the class.

Possible ideas:

• use virtual callbacks with a trivial default that should get invoked if the class logic is OK
• make the output stream configurable through inheritance, this could also be a nice way to make file logging easier to implement.
• add protected getters to the class members to monitor the goings-on.

... and test on a child class.

Right now, doctest is a mandatory requirement without which the code won't build.

Users of the code need to have both Qt and doctest installed. This makes very little sense, given that they won't necessarily want to run unit tests.

Also, the required macro is not documented in the readme yet. This should be fixed, potentially together with further configuration made necessary by the implementation of this issue.

Make sure that the UI has controls that allow setting all parameters that should be set by simple input.
Also make sure they work...

implementation only logs to stdout. There should be something in the program window to use.

• Add a status bar and update it to log output
• Add a log panel and insert entries
• Add error pop-ups on failures

UI-based stuff relies heavily on the UI framework being used. Constraints:

• Mustn't infringe MIT license. The resulting project should still be free to use.
• Can be integrated with CMake. There is a "find" file for this.
• Plays nice with openCV. If doesn't, then the app needs two different image buffers: one to operate on with openCV, one to display picture settings and/or intermediate picture data.
• Provides the required UI elements. Required elements are:
  • PushButtons to trigger image processing or opening color choosers
  • Color Choosers to figure out what colors to pixelate to
  • Spinner, Slider or similar to set "pixel" height and width, potentially also pixel count along both axes
  • image-displaying canvas/panel
  • File chooser to determine where the output should go to

The current program only runs silently in a shell.
There should be a way to display the files before and after conversion.
For that purpose, a rudimentary IO is missing.

First layout: Three rows with three (or two, resp.) entries each

• file chooser launcher, row input, column input (order not fixed)
• before and after canvas panels
• "convert" and "store" buttons

GUI framework not set yet.

Right now, the wireframe colors are chosen the same way that yarn colors are.
The whole tool is based on determination of distances between colors.
Therefore, it should not be too hard to determine the maximum contrast colors to use.

in ShrinkPixelator, the shrunk image is stored inside a temporary buffer at the time that binarize selects the colors to use based on pictureBuffer. Also, the function returns false; the image is never being stored.

Currently, logging uses std::ostream instances. That's conveniently well tested, and very little formatting/string concatenation work. Unfortunately, conditionally obtaining the logger stream for log output is REALLY lengthy.

• Come up with something of high performance that is easier to use
• Implement throughout

When loading an image that is much longer than it is wide, it is possible that the viewport extends past the window's bottom coordinate.
There should be a scroll bar instead.
Also, the image width doesn't cleanly adapt to what is maximally possible with the current window size.

Preview tends to grow obscenely.
There are no scroll bars on the image views.
In general, they look odd.

Should the Shell mode be left in or not?

If yes:

• Create an issue to add helper line implementation (and configurability) and options (and extend usage documentation)
• Create an issue to fix the architecture so it's more extensible
• Create an issue to make OpenCV optional (such that it is also valid to build the project without OpenCV if Qt5 is present).
• Create an issue to specify colors in shell mode (and extend usage documentation)

If no:

• Reject issue #32
• Remove shell mode completely (including the dependency on OpenCV, making Qt5 mandatory).

Once there is a UI (#2):

There should be an additional panel in the window layout that allows selection of two, or a list of, colors from a graphical color chooser. Those are meant to be used as target colors for the pixelation algorithms.

Currently, only using the program and asking oneself whether the result looks good is available to test the algorithm overall.

There should be input/desired output pairs available for testing.

Most likely, this will spawn rethinking of the distance algorithm.