Introduces AbstractIntensityAdjustmentAlgorithm

[zygmuntszpak]

This is a work in progress to address #32

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 23 lines in your changes missing coverage. Please review.

Project coverage is 92.12%. Comparing base (37000d7) to head (42795dd).
Report is 12 commits behind head on master.

Files with missing lines	Patch %	Lines
src/ContrastAdjustmentAPI/intensity_adjustment.jl	0.00%	23 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master      #50      +/-   ##
==========================================
- Coverage   95.97%   92.12%   -3.85%     
==========================================
  Files          12       13       +1     
  Lines         546      597      +51     
==========================================
+ Hits          524      550      +26     
- Misses         22       47      +25     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[johnnychen94]

Another choice is to make it

abstract type AbstractIntensityAdjustmentAlgorithm <: AbstractHistogramAdjustmentAlgorithm end

and so that we don't need to deprecate the old usages. We can just incrementally add new adjust_intensity methods with default alg to be LinearStretching. This means that both adjust_histogram and adjust_intensity would work for AbstractIntensityAdjustmentAlgorithm types.

How do you think?

[zygmuntszpak]

I think that making

abstract type AbstractIntensityAdjustmentAlgorithm <: AbstractHistogramAdjustmentAlgorithm end

goes against the spirit of the issue #32 which seems to be specifically about the fact that operations that don't manipulate the histogram ought not to be conceptualised as histogram adjustment algorithms.

I reckon let's just go ahead and make the deprecations before we embed this all in the Images ecosystem.

[johnnychen94]

goes against the spirit of the issue #32 which seems to be specifically about the fact that operations that don't manipulate the histogram ought

My argument is that not all histogram adjustment algorithm needs to explicitly construct a histogram. Directly adjust intensity can be considered as an implicit way to scale the x scale of the intensity histogram.

My personal understanding of #32 is that we just need a default algorithm for easier and more convenient usage to close #32. For generic histogram adjustment, there isn't a consensus default algorithm, but for intensity adjustment, we can default to linear stretching.

[zygmuntszpak]

My argument is that not all histogram adjustment algorithm needs to explicitly construct a histogram. Directly adjust intensity can be considered as an implicit way to scale the x scale of the intensity histogram.

That was also my argument and the reason why I implemented it the way I did in the first place :D, but @stillyslalom seems to disagree with our view here.

We can just incrementally add new adjust_intensity methods with default alg to be LinearStretching. This means that both adjust_histogram and adjust_intensity would work for AbstractIntensityAdjustmentAlgorithm types.

I'm torn here. If we go this route, then what's the benefit of introducing the adjust_intensity function? Is it effectively not going to just be an alias for adjust_histogram?

I guess one distinction is that AbstractIntensityAdjustmentAlgorithm is typically embarrassingly parallelisable, whereas some of the histogram-based algorithms may not be.

My personal understanding of #32 is that we just need a default algorithm for easier and more convenient usage to close #32. For generic histogram adjustment, there isn't a consensus default algorithm, but for intensity adjustment, we can default to linear stretching.

I was planning to introduce some convenience functions such as span_contrast to address issues such as #27

[johnnychen94]

I think all we need here is to introduce a convenient function span_contrast backed by LinearStretching to save some typings and easier to remember without checking the documentation. Changing the type hierarchy doesn't make things easier.

In the meantime, we can generalize LinearStretching and solves #33

[timholy]

My argument is that not all histogram adjustment algorithm needs to explicitly construct a histogram. Directly adjust intensity can be considered as an implicit way to scale the x scale of the intensity histogram.

I don't know if I agree with this argument. We don't call fill! adjust_variance even though it does that.

[zygmuntszpak]

Thanks for sharing your thoughts. What is your suggestion regarding the type hierarchy? Should AbstractIntensityAdjustmentAlgorithn subtype the AbstractHistogramAdjustmentAlgorithm type?

[timholy]

Vice versa, I'd say. The second sounds way more specific, the first is much more vague.