first API

[9il]

prev. discussion https://github.com/libmir/mir/issues/343

[9il]

@TurkeyMan we can just starts with things people can use for work

[TurkeyMan]

What should I do about the colour module?

[9il]

What should I do about the colour module?

It is welcome as mir repo into this repository or in a new one repository as well as into a repository in other organisation. You have owner access at @libmir. Organisations are preferable because they allow people to make fixes and minor release faster. Plus it is looks better for users.

More important that if it will be moved to Phobos then it may slowdown development process. std.experimental.color -> mir.color or color or other name you would like

[TurkeyMan]

It's too hard to do anything with phobos. I'll go mir.color, I'll leave it as a self-contained repo and move it here...

[9il]

Btw, would you mind me to include normalizedint to mir-algorithm? Almost all mir- repositories depend on mir-algorithm, it is kind of generic standard library that does not need to be compiled at betterC mode because everything is a template.

[TurkeyMan]

Yeah sure. Is it right for algorithm? I think of 'algorithm' as a way to traverse data... this is more of a data conversion. The implementation is complete/correct, but it's not efficient for a lot of conversions. Many of the small conversions that are more than ~2 operations would probably benefit from instantiating lookup tables.

[TurkeyMan]

I can wrangle the repo. What would you like the module to be called?

[TurkeyMan]

I guess an issue is that if norm-int goes in mir-algorithm, then colour has a dependency on a foreign repository, which feels a little bit awkward. In any non-dub workflow, there's no great way for handling that.

[9il]

Yeah sure. Is it right for algorithm? I think of 'algorithm' as a way to traverse data... this is more of a data conversion.

Yes, mir-algorithm is a lightweight generic part of mir that aimed to build more specialised algorithms.

What would you like the module to be called?

Up to you.

I guess an issue is that if norm-int goes in mir-algorithm, then colour has a dependency on a foreign repository, which feels a little bit awkward. In any non-dub workflow, there's no great way for handling that.

mir-algorithm has meson configuration (was added recently), and it used in production to build a huge D&C++ library.

[9il]

D + meson work well on linux only for now. Adding well support for Windows is not a big issue because meson has quite clear Python source code

[9il]

BTW, are color structs generic? Maybe add color package to mir-algorithm then?

[TurkeyMan]

color is generic to the extent reasonable. Colour formats are prescriptive (XYZ/RGB/YUV/Lab/etc), but data type, precision are generic. Some formats are more free-form; ie RGB can express RGB, RGBA, BGRA, R, RG, LA, GBRX, etc. PackedRGB can nominate how to encode each channel; but it's low-perf for operations, so PackedRGB just supplies pack/unpack functions, and they should be unpacked into a working format to operate on.

So... yeah, I guess it's generic. It's definitely not an 'algorithm' though ;)

[TurkeyMan]

Perhaps mir should be positioned as a 'runtime library', and from that perspective, algorithm fits into the context of a runtime lib, alongside other useful tools like color/image, etc...

[TurkeyMan]

It would be awesome for the mir project to provide an alternative @nogc druntime/stdlib implementation.

[9il]

Other alternative is to split mir-algorithm into two packages. The second one can be called mir-std

[9il]

Hi Manu, I just understood that mir-algorithm is going to be complitely reworked / moved / split at the end of this year. Please keep mir.color as standalone for this year at least.

[TurkeyMan]

Okay, no problem. We should make sure colour and also the NormInt stuff fits into the new organisation when it is designed.

[9il]

Hi @TurkeyMan, https://github.com/libmir/mir-core has been initiated. mir-core looks like a good place for NormInt.

mir-color then can be a separate package that depends only on mir-core. mir-image is proposed to depend on mir-color, and other required mir packages. I am reworking mir and mir-algorithm now, so they would solve the issue with 'algorithm' word.

[TurkeyMan]

I'm not sure how to model package dependency in the D ecosystem. We have no general package management solution... so how do you make some code dependent on other code in a separate repo?

The 'algorithm' box is an interesting box. Does it include range operations? Does it include iteration and search logic? When working on DMD where phobos is banned, it's very strange that the most primitive and fundamental tools are missing; like empty(), or some basic string tools, like finding a sub-string, and there's no way to join strings...

Have you considered a mir-runtime? Something to compete with druntime, but tuned for @nogc, possibly embedded use? And also to maintain modern and sensible API's?

druntime-proper is missing heaps of really basic tools.

[9il]

I'm not sure how to model package dependency in the D ecosystem. We have no general package management solution... so how do you make some code dependent on other code in a separate repo?

1. dub - for simple packages
2. meson - need to work on Windows support and unity builds. Meson has a quite clear Python source code. The current D integration should be cut off in favor of new C++ like DCompilerarchitecture.
3. version(Have_mir_somerepo) - general week dependency solution.

The 'algorithm' box is an interesting box. Does it include range operations?

Array range primitives like popFront are part of mir.primitives at mir-core. Common primitive precompiled (nongeneric) string and allocation utilities and probably allocators are proposed to place in mir-runtime. Note: string in Mir is a range of chars. If Unicode forward ranges are required we can add generic asUnicode range adapter in mir-core.

mir.ndslice.slice and mir.ndslice.topogy, mir.container, mir.range are proposed to be placed in mir.

Does it include iteration and search logic?

All main algorithms (including iteration, set operations, interpolation, and graphs) are proposed for mir-algorithm. Currently, we have mir.algorithm.iteration, most if its API work with input ranges. Also, we have mir.algorithm.setops.

Have you considered a mir-runtime? Something to compete with druntime, but tuned for @nogc, possibly embedded use? And also to maintain modern and sensible API's?

Yes, I have the same thought. Proposed below Mir's architecture has 100% generic mir-core. And almost precompiled mir-runtime (TODO). Mir core brings some alternatives to std.*, while mir-runtime is an alternative to DRuntime. libmir still use std.traits, but we can do our own alternative if required and place it in mir-core with copyright from std.traits. While std.* depends on DRuntime, Mir has other architecture, where mir-runtime is depend on generic mir-core.

We can place all basic tools in mir-core and mir-runtime.

mir-image dependencies are selected.

[kyleingraham]

I came across this issue while learning about chromatic adaptation (working on it here: https://github.com/kyleingraham/photog) and being curious about past image processing efforts in D. I would like to offer my help here wherever needed. mir-algorithm and lubeck are great libraries to use and I can see the importance of color as a first-class citizen after trying to write algorithms centred on it.

I've got some domain knowledge and lots more interest and enthusiasm. Hopefully I can be of assistance to you all.

[9il]

I don't work on image processing now. @TurkeyMan?