Closed timholy closed 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.
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.
@StefanKarpinski You are right. You cannot sort colors by wavelength because all wavelength information is lost once a spectrum is converted to a color.
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.
The ordering is completely meaningless, but I'd like to make PooledDataArray
work with unordered types before removing isless
, which should be easy.
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.
@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.
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.
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:.
Thanks!
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.
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.
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
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. :/
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:
Naively I would have expected this to produce either an error or
RGB{Float}(1.0,0.8,0.4)
, just likeWith 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 thismin
behavior, of course; it's only thatmin
callsisless
in the absence of a more specialized method. I'm proposing that we deleteisless
out of concern that it's simply too poorly-defined. If the only purpose for definingisless
was to allow one to sort colorvalues, then there is a more restricted way to solve that problem:sort(A, lt=comparisonfunc)
.