Dependencies

[rafaqz]

A lot of the methods in this package are widely useful outside of image manipulation.

In ecology and geospatial fields there are uses for methods like label_components and feature_distance but dependencies like ColorVectorSpace.jl and ImageCore.jl are a lot to include.

Looking through the source, I cant actually find much that requires these dependencies. Could GenericGrayImage just be AbstractArray ? What other methods require ColorVectorSpace.jl and ImageCore.jl?

See:
EcoJulia/NeutralLandscapes.jl#14

[mkborregaard]

This would be amazing.
There has been a similar discussion over at ImageFiltering JuliaImages/ImageFiltering.jl#42 and JuliaImages/ImageFiltering.jl#51 and it seems that @timholy agrees this would make sense too. There are so many excellent general array functions in the image ecosystem that could benefit the entire ecosystem immensely if they came in a clearer more light-weight format

[rafaqz]

As with Imagefiltering.jl, moving a lot of this code somewhere without Image- in the name would make it more discoverable, and something more people are likely to contribute to.

[rafaqz]

coords_spatial is the only method form ImageCore.jl, used only in dilation_and_erosion.jl. Removing ColorVectorSpace.jl would mean users would have to import it manually for colors to work.

Swapping GenericGrayImage to AbstractArray and removing the specialization on array eltype in convexhull (which included Gray{Bool}) are the only other changes required.

[rafaqz]

I would put in a PR, except the traits dependency in ImageCore.jl is blocking this being possible - they would need to move somewhere - ArrayInterface.jl?

[juliohm]

I agree that we should try to generalize and split things out in terms of AbstractArray. @johnnychen94 can provide more useful feedback on the future plans. It is been a while since the last time I contributed to the Images.jl stack and I know a lot has changed since then.

[johnnychen94]

This is a good proposal.

Except for the maintainability, a similar relationship between Distances.jl and ImageDistances.jl is an ideal solution; people outside of the JuliaImages community could directly use and extend a "Morphology.jl" package, and JuliaImages keeps maintaining the colorant part of it.

Maintainability is the only issue here; we don't have many maintainers here to split everything apart to get the least dependencies. (Mostly it's me and @timholy doing it).

If there's someone giving a clear fork of ImageMorphology without the ImageCore.jl stack, I'll be very happy to see ImageMorphology built on top it.

[rafaqz]

Great. I understand the maintenance burden involved here, and don't have a huge amount available myself. But hopefully this would eventually spread the burden a little wider.

We could register a very minimally changed version of this package as Morphology.jl with type restrictions eased and without the coords_spatial method. Instead we can define coords (or something). ImageMorphology can override coords for AbstractArray{<:Color} (if I understand how Images workds correctly) and forward to coords_spatial, and otherwise be a nearly empty package.

The next question is what would be a good location/org for Morphology.jl? It could be the same place as MapFilter.jl/ArrayFilters.jl/Stencils.jl etc suggested in related issues (I would also be good to have those package separated out in a similar way).

Another angle is that in fact the traits in ImageCore.jl are themselves not specifically image-related, and could be in a more general arrays package.

[timholy]

I'm supportive of this. Hold for just a little while? ImageCore may soon be based on ArrayInterface (JuliaImages/ImageCore.jl#112 (comment)) but there will likely be a few things to sort out. I'd like to see ArrayInterface move to JuliaArrays first, and I haven't gone beyond JuliaArrays/ArrayInterface.jl#121 in terms of checking whether ArrayInterface is in adequate shape to be included in ImageCore.

[rafaqz]

I'd like to see ArrayInterface move to JuliaArrays first,

That would be great. I thought it was a stretch to propose moving array traits from ImageCore to SciML. But the images traits could live there if it was in JuliaArrays, and coords_spatial could stay.

I think we have a short term solution so we can wait, but I think the aim is to not have to duplicates of these algorithms around.

[rafaqz]

@timholy an @johnnychen94 I'll put together Morphology.jl and write the PR to depend on it here once the ImageCore.jl traits are sorted. Reading them I'm not sure I can do that myself, but I'm guessing that's possible now that ArrayInterface.jl has moved. I'm happy to maintain Morphology.jl as well so this isn't adding a burden here.

[rafaqz]

Just checking in on this, and where the ImageCore.jl traits are at now?

[johnnychen94]

Here's the plan with respect to the lazy loading(JuliaImages/Images.jl#1009) and monorepo (JuliaImages/Images.jl#898) stuff:

• the types and interface will go to "MorphologyInterface.jl" -- mainly the traits and structuring element stuff I've added recently. This should be always loaded by any package that depends on it.
• the main algorithm codebase will be a standalone package "Morphology.jl" without ImageCore dependency. I still plan to depend on FixedPointNumbers because that's a core number type we used across the entire JuliaImages ecosystem and because that's super lightweight -- 0.004 seconds in my machine.
• the current ImageMorphology.jl will be migrated to Images.jl

The Morphology and MorphologyInterface will be maintained in one repo. I'll do it in JuliaImages since we're probably the main maintainers of this package.

I'll also experiment with my Workflows.jl stuff, so sit tight!

[johnnychen94]

[johnnychen94]

Hmmm, I changed my mind wrt monorepo arch. Let's just get everything back to Images.jl

CRef: JuliaImages/Images.jl#898 (comment)