Add per-channel contrast GUI for AbstractRGB images. #145
Conversation
| gsig = Signal(chanlims[2]) | ||
| bsig = Signal(chanlims[3]) | ||
| #make sure that changes to individual channels update the color clim signal and vice versa | ||
| bindmap!(clim, x->change_red(clim, x), rsig, x->channel_clim(red, x); initial = false) |
There was a problem hiding this comment.
On the Travis run, bindmap! caused an error. Looks like bindmap! was merged to master in Reactive in Sept 2017 but Reactive hasn't been tagged since August 2017. If you need this then you might want to nudge them?
There was a problem hiding this comment.
I nudged here. I'll wait a bit and see whether I get a response. If not I can rework it to avoid using bindmap!.
|
should we merge this? 0.7 will need some error fixing anyway I assume |
Cody-G
force-pushed
the
cjg/color_contrast2
branch
from
84de1c7 to
624abf7
Compare
|
I just rebased and pushed again in case it's decided to merge this. |
|
If tests can pass on at least 0.6 I think this is highly desired. But given that even 0.6 didn't pass, I need to finish the Interpolations rewrite before I can invest the time to figure out what is causing the trouble here. Apologies. |
|
I just checked into this and when I run the tests locally (with fresh package directory) I get the error the first time I run the tests, but after the first time everything passes fine. My guess is that there's some kind of race condition with GTK that only causes an error when things are first compiling. I would also guess that the error is unrelated to this PR, but I didn't check that. |
|
So I just tried this on master and there's also an error on the first run that disappears on later runs, but it's a different one: INFO: Start installing ImageMagick...
INFO: Installing ImageMagick v0.5.2
INFO: Building FFTW
INFO: Building SpecialFunctions
INFO: Building ImageMagick
INFO: Package database updated
ERROR: LoadError: LoadError: MethodError: no method matching getindex(::Void, ::UnitRange{Int64}, ::UnitRange{Int64})
Stacktrace:
[1] include_from_node1(::String) at ./loading.jl:576
[2] include(::String) at ./sysimg.jl:14
[3] include_from_node1(::String) at ./loading.jl:576
[4] include(::String) at ./sysimg.jl:14
while loading /home/cody/Desktop/jpacks2/v0.6/ImageView/test/scalesigned.jl, in expression starting on line 6
while loading /home/cody/Desktop/jpacks2/v0.6/ImageView/test/runtests.jl, in expression starting on line 3Maybe it's still explained by the same compilation race condition? |
|
That smells like a garbage-collector induced problem to me. Are you creating a signal that you're not holding onto? Compilation can expose GC issues because compilation allocates memory, and thus forces more frequent GCs. You could test by adding an explicit |
|
Ah, I see. Well the stack trace for this PR (see Travis) doesn't show where to put the |
|
Didn't realize this happened on master. Will fix (tomorrow). |
|
Tests do not fail on master with 0.6, see #152. I can't get it to fail locally either. Next I will look into this PR to see what can be done to fix it. |
|
Merged in #153 |
Supersedes #142