Closed johnnychen94 closed 3 years ago
Yes, I guess it didn't occur to me at the time that one would want to load both packages in the same problem domain.
I'm not sure how to resolve the conflict of the AbstractImageBinarizationAlgorithm
type which makes sense in ImageBinarization, and the AbstractHistogramThresholding
type (currently just called ThresholdAlgorithm
) which makes sense for HistogramThresholding
.
Is the name conflict issue coming up in the Images ecosystem for when you try to replace otsu_threshold
? What if we just define a find_threshold
for ImageBinarization
which essentially wraps the HistogramThresholding
implementation?
Is the name conflict issue coming up in the Images ecosystem for when you try to replace
otsu_threshold
?
Yes, it turns out that once we reexport any one of these two packages in Images.jl, this issue raises.
I'm not sure how to resolve the conflict of the AbstractImageBinarizationAlgorithm type which makes sense in ImageBinarization, and the AbstractHistogramThresholding type (currently just called ThresholdAlgorithm) which makes sense for HistogramThresholding.
I was thinking of this, too. Will try it and see what possible side effects would it be after this semester.
What if we just define a find_threshold for ImageBinarization which essentially wraps the HistogramThresholding implementation?
In that case, you're encouraging common users to not use HistogramThresholding
anymore since find_threshold
is the only function there, and if so, it would be better to merge HistogramThresholding
as a sub package of ImageBinarization
, as @timholy suggested in https://github.com/JuliaImages/Images.jl/issues/898
It's a bit awkward that two closely related packages have name conflicts:
A simple and intuitive solution to this is to reuse the type
HistogramThresholding.Yen
and directly dispatchbinarize
on it. But this requires some code organization changes and it may have other unexpected side effects.