Dependency on Images.jl directly

[Evizero]

I realize this may be an odd question.

It came up in JuliaImages/Images.jl#682 (comment) that ImageFeatures.jl depends on Images.jl, and I found this quite surprising because my mental image for Images.jl so far was as a convenient meta package for importing the whole ecosystem.

So I just felt like double checking this wouldn't hurt. Is there a reason that this package needs to depend on Images.jl directly, instead of the individual backend packages? I quickly browsed through the source files and didn't see any obvious reason like extending a function.

[timholy]

A worthy discussion point, though one that seems unlikely to have a unique answer.

The JuliaImages ecosystem could be organized in a variety of ways:

• (minimalist) as a collection of focused packages, without any kind of umbrella (the role of our current Images): a user imports or usings exactly what s/he needs
• (maximalist) using Images gets you everything
• (in between) using Images gets you "the common core" and you load extra packages for more advanced functionality

Right now we're closest to the third.

In many ways I think the third makes a certain amount of sense, with one big caveat: I'm not aware of any principle that defines what should or should not be in the common core. In practice it has largely been defined by history: what got put into Images.jl before the creation of the JuliaImages organization and the splitting out of much of the functionality to more focused packages. At the time I did the big 0.6 rewrite, I decided not to be breaking and to make sure that Images re-exported the functionality that had been moved to other packages. Right now the two big outsider packages (EDIT: of those hosted at JuliaImages) are ImageFeatures and ImageSegmentation, both focused on computer-vision type applications. (Here I'm not counting visualization packages.)

[timholy]

With regards to specifically whether this needs to depend on all of Images, probably not. I suspect the keypoints->corners->edges dependency would be the main one.

[Evizero]

That makes sense.

The one thing that makes this situation a little awkward to explain to a end-user, is that just typing using ImageFeatures is a sensible thing to do, while just typing using ImageTransformation is not (nor any other core package).

I say this because displaying images in Jupyter without the custom show code in Images.jl works just well enough to confuse users, but its basically a showstopper.

[timholy]

Yeah, it might be worth moving to an ImageIO package on its own, and have any package that loads an image format also load it.

[johnnychen94]

One thing we are sure of is that Images.jl is (or will be) just a convenient meta package. All actual codes will be moved outside to other separate packages eventually (If I understand it right).

Since this is the case, Images.jl is just one of many potential delicately-designed toolboxes, which means we(developers) or users can compose packages together accordingly and free as long as we provide a decoupled and flexible dependency relationship between modules. -- This isn't impossible.

Then the role of Images.jl becomes

• the most common end-user entrance for basic image processing work
• a useful living demo of how to compose modules together

Minimal or maximal, it really doesn't make much difference when composing modules becomes an easy work.

Possibly we could build up our packages just like we build up a docker image.