Closed annimesh2809 closed 7 years ago
Seeing the travis build, it seems like ImageTransformations.jl
is breaking with Julia 0.7.
ImageTransformations.jl is breaking with Julia 0.7
:(
Are we at all close to 0.7? I have not spend any time investigating the required changes
Whoops sorry! I meant Julia nightly :sweat_smile:
No no I understood. I am just wondering if we are close to a point in time where the nightly fails should be addressed since at the moment I am rather ignorant towards them
0.7 will have some nice goodies; I've made quite a few contributions myself, including a better inlining algorithm in the compiler---which turned out to yield quite a few performance improvements---and more user-friendly (i.e., useful for debugging) error messages for InexactError
, DomainError
, and OverflowError
. That said, I'm not all that worried about targeting 0.7 yet, because there are going to be a lot of breakages still to come. The worst one currently is the migration of FFTW out of base (https://github.com/JuliaMath/FFTW.jl/issues/13), which is currently making Images not even buildable. So I've been considering adding nightly to the allow_failures
matrix.
Merging #7 into master will decrease coverage by
20.73%
. The diff coverage is4%
.
@@ Coverage Diff @@
## master #7 +/- ##
===========================================
- Coverage 100% 79.26% -20.74%
===========================================
Files 5 5
Lines 281 352 +71
===========================================
- Hits 281 279 -2
- Misses 0 73 +73
Impacted Files | Coverage Δ | |
---|---|---|
src/ImageSegmentation.jl | 100% <ø> (ø) |
:arrow_up: |
src/core.jl | 2.7% <0%> (-97.3%) |
:arrow_down: |
src/fast_scanning.jl | 98.48% <100%> (-1.52%) |
:arrow_down: |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact)
,ø = not affected
,? = missing data
Powered by Codecov. Last update d7dff8e...f5db63a. Read the comment docs.
Merging #7 into master will increase coverage by
0.12%
. The diff coverage is100%
.
@@ Coverage Diff @@
## master #7 +/- ##
=========================================
+ Coverage 99.37% 99.5% +0.12%
=========================================
Files 6 6
Lines 321 400 +79
=========================================
+ Hits 319 398 +79
Misses 2 2
Impacted Files | Coverage Δ | |
---|---|---|
src/ImageSegmentation.jl | 100% <ø> (ø) |
:arrow_up: |
src/fast_scanning.jl | 98.48% <100%> (-0.03%) |
:arrow_down: |
src/core.jl | 100% <100%> (ø) |
:arrow_up: |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact)
,ø = not affected
,? = missing data
Powered by Codecov. Last update 205a6a4...7b2f7dc. Read the comment docs.
Just checking, anything particular holding this up?
Sorry, completely forgot about this. I was working on increasing the performance of region splitting and merging. I will make the required changes ASAP.
No problem, that sounds like important work!
The labels applied to the segments in a SegmentedImage
have not been restricted to be "consecutive" integers from 1 to no_of_segments. Currently, they can be any positive integer. However, the vertex labels in a SimpleWeightedGraph
must be consecutive integers, hence I thought of adding the vert_map
.
We have two options:
1) Restrict the segment labels to be consecutive positive integers starting from 1. This will allow us to remove vert_map
.
2) Allow arbitrary positive segment labels. This will require vert_map
.
Which one should we go for?
Do you have a favorite? I would be strongly influenced by your own thoughts on the matter.
My own thoughts: presumably this boils down to, "how much of an advantage would it be to allow non-consecutive segment labels?" I can imagine segmenting two corresponding images, one in which there's a ball in the picture and the other in which there is not (imagine two images from a sports game separated by half a second, where the ball flies in or out of the view). You might want to "seed" some segmentation algorithm using the exact same labels for both images, and so you might want to just omit the seed corresponding to "ball" from the one that doesn't have it. Assuming that applications like this are not unreasonable, it seems that given the constraints of SimpleWeightedGraphs
that perhaps we'd better keep vert_map
.
But if this isn't right, and there really aren't strong justifications for non-consecutive labels, maybe it would be better to skip them just so we can simplify the indexing here.
seeded_region_growing
allows for arbitrary labels as supplied by the user. The user might want to have some a specific label for some interested regions, this can't be achieved if we force consecutive labels.
Also, efficient implementation of some algorithms like fast_scanning
produces SegmentedImage
with non-consecutive labels.
Considering these, I think we should allow non-consecutive labels.
LGTM!
The following functions have been added:
region_adjacency_graph
: Create an RAG (SimpleWeightedGraph
) from aSegmentedImage
rem_segments!
: Similar torem_edges!
inLightGraphs.jl
. It removes a segment replacing it with its neighbor having largest pixel count. The removal is done in place.rem_segment
: Similar torem_segments!
but the removal is done on a copy of theSegmentedImage
.prune_segments
: Removes all segments having pixel count <thres
. It is much more efficient than callingrem_segment
for individual segments.All these functions have been verified to be working on N-d
SegmentedImage
. For 512x512 color images,region_adjaceny_graph
takes ~50ms and others take ~100ms. Tests will be added soon.There is also a performance fix for
fast_scanning
.