juliaimages / imagebinarization.jl Goto Github PK

I would expect this work as a more efficient version of Gray{Bool}.(binarize(...)) but there seems some issue here:

julia> img_input = binarize(Gray{Bool}, testimage("mandril"), UnimodalRosin())
ERROR: InexactError: Bool(0.541N0f8)

This seems a bug to me.

cc: @ashwani-rathee

In #164,It was pointed out that even though ImageBinarization.jl has very detailed explanations in docstring.There is a need for setting up a demo page and move the explanations to the form of demos for each algorithm.

Looks like both travis-ci.org and travis-ci.com are used in CI tests.

I think you can disable one of them. BTW the URL link in README's CI badge is travis-ci.com :D

In #30 we changed the usage of AdaptiveThreshold from

w = recommend_window_size(img)
f = AdaptiveThreshold(window_size = w, percentage = 15)
binarize(img, f)

to

f = AdaptiveThreshold(percentage = 15)
binarize(img, f)

By doing this, users no longer need to call recommend_window_size anymore, which is an improvement.

However, this isn't what we really want in the beginning, since we'd like to hold all parameters of AdaptiveThreshold inside of it.

a window_size is something that is intrinsic to an adaptive method since the existence of a window is what often differentiates global thresholding from adaptive local thresholding. A sensible choice of window_size does indeed depend on the size of the image.
-- @zygmuntszpak

As a solution, I’m keeping thinking of introducing another set of API that generate the algorithms with the “best” inferred parameters from prior information, for example, the usage could be:

# option 1
f = AdaptiveThreshold(img)
# option 2
f = algorithm_plan(:AdaptiveThreshold, img)

binarize(img, f)

The idea here is, use img to infer as much information as needed, and leave the others using the default value.

A toy implementation of option 1 could be:

AdaptiveThreshold(img::AbstractArray; kwargs...) = 
    AdaptiveThreshold(;window_size=default_AdaptiveThreshold_window_size(img), kwargs...)

P.S., a practical example of this design is used in my NonlocalMean, where we infer the best r_p (aka. window_size) using img.

It would be convenient to make binarize(alg) return a function so that

map(binarize(Yen()), imgs)

This is equivalent to binarize.(Ref(Yen()), imgs) but a function can be composed together with other functions using ∘, or eventually the |> API similar to that in Augmentor:

pipeline = FlipX(0.5) |> Rotate([-5,-3,0,3,5]) |> CropSize(64,64) |> Zoom(1:0.1:1.2)

Cases that I know in Base are isequal, isapprox(in Julia 1.5), startwith(in Julia 1.5) and endswith(in Julia 1.5):

julia> map(isequal(2), 1:5)
5-element Array{Bool,1}:
 0
 1
 0
 0
 0

The basic usage example has the below code:

img = testimage("cameraman")
alg = Otsu()
img = binarize(img, alg)

If one just copies and pastes the above into a Julia 1.2 REPL it does not work, even after adding in using ImageBinarization. Digging around the docs found mention of a using TestImages, but simply adding that package to Julia has its own issues when trying to use it on a MacOS 10.14.6 with errors about QuartzImageIO etc.. So for the sake of greater adoption and ease of use it would be worth having a nice self contained examples that one can simply cut and paste and have it work.

I'm wondering if it is necessary to export all implemented methods: https://github.com/zygmuntszpak/ImageBinarization.jl/blob/master/src/ImageBinarization.jl#L61-L72

If this package is reexported by Images.jl, which I think eventually will be, then all these names: Ostu,Balanced,Yen become be meaningless for Images.jl users.

Perhaps we need an intermediate wrapper method binarize_method to generate BinarizationAlgorithm

Currently,

using OffsetArrays, ImageBinarization
Xo = OffsetArray(rand(10, 10), OffsetArrays.Origin(0))
binarize(Xo, Otsu()) # oops

Background: common warp operations(e.g., imrotate) in ImageTransformations returns an OffsetArray.

Balanced, Entropy, Intermodes,MinimumError, Minimum Intermodes, Moments, Unimodal Rosin and Yen don't have docstrings

Currently, ImageBinarization doesn't support transparent colors (e.g., RGBA) so I open this issue to see your opinions:

• leave it unsupported
• drop the transparent channel
• keep the transparent channel and output the transparent gray color, e.g., GrayA{T} (Unfortunately, T can't be Bool here).

I'm not sure if we should support this. Neither dropping or making output GrayA{Float64} type doesn't sound very good to me.

cc: @ashwani-rathee

https://github.com/JuliaImages/IntegralArrays.jl

Making a note to refactor the code in accordance with the discussion taking place at:
JuliaImages/ImageCore.jl#77

The package looks great, thanks for the contribution!

Would it make sense to swap the arguments? Most Julia APIs I've came across adopt the following convention:

binarize(img, alg)

as opposed to

binarize(alg, img)

I read the first version as "binarize the image with algorithm", the second version doesn't have a clear "spelling", at least for me.

I adopted the above mentioned convention in ImageInpatining.jl for example, and in the internals of GeoStats.jl in multiple places.

It's a bit awkward that two closely related packages have name conflicts:

julia> using HistogramThresholding

julia> using ImageBinarization
[ Info: Precompiling ImageBinarization [cbc4b850-ae4b-5111-9e64-df94c024a13d]

julia> Yen
WARNING: both ImageBinarization and HistogramThresholding export "Yen"; uses of it in module Main must be qualified
ERROR: UndefVarError: Yen not defined

A simple and intuitive solution to this is to reuse the type HistogramThresholding.Yen and directly dispatch binarize on it. But this requires some code organization changes and it may have other unexpected side effects.

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Looks like it's broken months ago, one recent report is:

https://github.com/JuliaCI/NanosoldierReports/blob/master/pkgeval/by_date/2020-03/19/logs/ImageBinarization/1.5.0-DEV-7f28d91b70.log

No idea what breaks there, my best guess is the architecture differences.

Please add install instructions for brand new user stumbling across Julia on how to add the package. This will increase usability.

I was looking for information on the Entropy binarization algorithm, and found the following:

https://zygmuntszpak.github.io/ImageBinarization.jl/stable/reference/

However, that documentation is visible here:

https://juliaimages.org/HistogramThresholding.jl/stable/

abstract type BinarizationAlgorithm end
struct Otsu <: BinarizationAlgorithm end

The current design is

• (Design A)

binarize(algo::Otsu, img) = println("binarize img with Otsu")

The usage is

julia> algo = Otsu()
julia> binarize(algo, img)
binarize img with Otsu

Actually, there's an alternative design, which is commonly used in Flux.jl AFAIK

• (Design B)

(binarizer::Otsu)(img) = println("binarize img with Otsu")

The usage is:

julia> binarizer = Otsu()
julia> binarizer(img)
binarize img with Otsu

In design A, two different algorithms are connected in two ways: BinarizationAlgorithm and binarize. In design B, they're only connected by BinarizationAlgorithm.

According to the naming guide https://github.com/JuliaImages/Images.jl/issues/767, we should use binarize

for functions that compute something or perform an operation, start with a verb (e.g., warp)

But I guess there would be some cases Design B is more natural.

Any ideas?