JuliaAttic / Color.jl

Basic color manipulation utilities.
Other
47 stars 21 forks source link

Delete isless for ColorValues #55

Closed timholy closed 10 years ago

timholy commented 10 years ago

I have mixed feelings about this PR, but overall my concern is that defining an order on ColorValues is pretty arbitrary and leads to confusing behavior. For example:

julia> using Color

julia> c = RGB(1.2,0.8,0.4)
RGB{Float64}(1.2,0.8,0.4)

julia> o = RGB(1.0,1.0,1.0)
RGB{Float64}(1.0,1.0,1.0)

julia> min(c,o)
RGB{Float64}(1.0,1.0,1.0)

Naively I would have expected this to produce either an error or RGB{Float}(1.0,0.8,0.4), just like

julia> a = [1.2,0.8,0.4];

julia> b = [1.0,1.0,1.0];

julia> min(a,b)
3-element Array{Float64,1}:
 1.0
 0.8
 0.4

With this PR, min(cv1, cv2) will yield an error. If others feel that the elementwise result is more natural, I'll add another commit to this PR.

Note that we don't have to delete isless to get this min behavior, of course; it's only that min calls isless in the absence of a more specialized method. I'm proposing that we delete isless out of concern that it's simply too poorly-defined. If the only purpose for defining isless was to allow one to sort colorvalues, then there is a more restricted way to solve that problem: sort(A, lt=comparisonfunc).

StefanKarpinski commented 10 years ago

Unless there's one clearly correct ordering on colors (by wavelength?) I'd agree that having an isless method is a mistake.

timholy commented 10 years ago

Looks like this will cause Gadfly tests to fail:

...
Rendering hstack on svgjs backend.
Rendering hstack on svg backend.
Rendering hstack on png backend.
Rendering colorful_hist on svgjs backend.
FAILED!
ERROR: `isless` has no method matching isless(::LCHab{Float64}, ::LCHab{Float64})
 in sort! at sort.jl:246
 in sort! at sort.jl:290
 in sort! at sort.jl:329
 in sort at sort.jl:334
 in PooledDataArray at /home/tim/.julia/v0.3/DataArrays/src/pooleddataarray.jl:96
 in apply_statistic at /home/tim/.julia/v0.3/Gadfly/src/statistics.jl:238
 in apply_statistics at /home/tim/.julia/v0.3/Gadfly/src/statistics.jl:37
 in render at /home/tim/.julia/v0.3/Gadfly/src/Gadfly.jl:650
 in draw at /home/tim/.julia/v0.3/Gadfly/src/Gadfly.jl:744
 in run_tests at /home/tim/.julia/v0.3/Gadfly/tests/test.jl:111
 in include at ./boot.jl:245
 in include_from_node1 at loading.jl:128
 in process_options at ./client.jl:285
 in _start at ./client.jl:354
 in _start_3B_1713 at /home/tim/src/julia/usr/bin/../lib/julia/sys.so
while loading /home/tim/.julia/v0.3/Gadfly/tests/test.jl, in expression starting on line 155

I don't know enough about what's going on to really comment, but I don't understand why the PooledDataArray constructor needs to call sort!.

CC @dcjones, @johnmyleswhite.

m-lohmann commented 10 years ago

@StefanKarpinski You are right. You cannot sort colors by wavelength because all wavelength information is lost once a spectrum is converted to a color.

JeffBezanson commented 10 years ago

I don't see how there can be a sensible order on colors. We don't even have an order for vectors or complex numbers.

dcjones commented 10 years ago

The ordering is completely meaningless, but I'd like to make PooledDataArray work with unordered types before removing isless, which should be easy.

timholy commented 10 years ago

Sounds like there's agreement. While we have everyone's attention: should min(rgb1, rgb2) do an elementwise min, or be undefined? If so, only for RGB, or for any ColorValue? One illustration of the dangers is that min(rgb::RGB, luv::LUV) probably doesn't make any sense.

m-lohmann commented 10 years ago

@timholy I think min in terms of colors is as meaningless as a general order of colors. If there is no order then I can hardly imagine how there could be a min. min in terms of what? Hue, saturation, lightness, vector length from the origin, in what common color space? I don’t think there is a meaningful answer to it.

timholy commented 10 years ago

OK, in Images there will be a clamp function to keep RGBs between RGB(0.0, 0.0, 0.0) and RGB(1.0, 1.0, 1.0). But I'm pretty happy keeping it restricted to that one case, and just in Images.

timholy commented 10 years ago

Bump. I just had something work unexpectedly in Images, but it turned out to be due to this. I'd rather it had been broken :smile:.

timholy commented 10 years ago

Thanks!

rennis250 commented 9 years ago

One could argue that there is one instance in which an ordering can be placed on a subset of colour space. There are colour ordering tests for colour vision deficiencies, such as the Farnsworth 100 hue test. Individuals are given a random assortment of colours from around a hue circle in a given isoluminant plane and are asked to put them in order, which almost everyone can readily do without any further explanation of what "order" is (the lighting conditions and powders used are such that the perceived colours should all be isoluminant and of "equal" saturation). The result is that people without colour vision deficiencies will assort them such that a continuous visual progression results (much like this: http://www.jyotirmay.com/wp-content/uploads/2013/12/FM-100-Mihir3-150x150.jpg), but people with colour vision deficiencies will place them in a more-or-less haphazard manner (much like this: http://linesandcolors.com/images/2008-12/hue_450.jpg or like this: http://apps.ketchum.edu/ceonline/content_images/jng/inheritedvisiondef6large.jpg), with the random placement depending on the type and origin of the deficiency. However, I have heard that other studies have shown that when given a strategy for ordering the colours (e.g., "pay attention to the small differences between each colour sample and arrange them such that the 'greater' one is to the right of the 'lesser' one"), then individuals with colour deficiencies can achieve an ordering that comes closer to that of trichromatic individuals, but I haven't had a chance to actually read these yet.

I would argue that probably the only time an ordering of colours makes sense is in this situation, so we could do something like sort colours by hue angle, where 0° is the least and 360° is the greatest, with the restriction that the colours need to be close to isoluminant and close to equal saturation. (EDIT: These requirements are much too limited and not worth it. Actually, the previous sentence that this edit removed was just a re-creation of a centuries old problem that has no satisfying solution - see my post below.) This could be applied to all colour representations (RGB, HSV, LUV, etc.), by first converting the colour to a common measure of hue (H of the HSV space should be sufficient for starters) and then converting back to the original representation. I agree that an ambiguity arises due to the periodic nature of the hue circle, but one could accept some standard convention to go by. In the colour perception research literature, it is common to accept "red" as lying at 0°.

EDIT: This previous sentence was just the result of an exaggeration of the severe constraints placed on the stimuli used in the 100 hue test, allowing an ordering to be imposed in those limited circumstances. In other words, I tend to be long-winded - see my post below.

Best, Rob

EDIT: I said that the colours had to be arranged in a circular shape for the Farnsworth test, but that isn't true. Individuals arrange them in rows.

dcjones commented 9 years ago

That's pretty interesting. I'm not convinced we should define isless though, because it would be hard to guess what it's doing. If someone was doing work that involved ordering colors, I'd imagine they'd want to be very specific about the definition of the ordering.

rennis250 commented 9 years ago

Ah, yes, sorry, I wasn't suggesting implementing an isless function, but something that could provide this sort of pattern, if desired. Something like huesort, but do note that my tact for function naming is subpar.

Best, Rob

rennis250 commented 9 years ago

Actually, I'm realising that all I've done is just gone through an elaborate way of saying that when your subspace can be represented on a single dimension (such as angle), then you can place an ordering on those elements. If we had a bunch of colours with the same luminance, but different hues AND different saturations, then the whole thing begins to fall apart (for math and for the visual system). In fact, part of the reason that two-dimensional colour spaces (and subsequently three-dimensional colour spaces) were formed was because no one could find a good way to order colours of different hues/saturations/luminances (choose any two) on a single line (or on a single plane if we choose all three). So, yea, apologies for the (big burst of) noise and what I now see as my slight snarkiness at the end of that post. I really need to cut back on the caffeine, I think. :/