Pages: [1]   Go Down

Author Topic: ColorThink Bug - Wrong values extracted from images with dimension > 500px  (Read 4500 times)

darlingm

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 361
    • Westland Printworks

My detailed, technical, and long bug report is on ColorThink's forum here: http://www.colorforums.com/viewtopic.php?p=5565#5565

The summary is that ColorThink uses a shortcut method so it doesn't run horribly slow, and the shortcut method is programmed incorrectly so it creates pixel values that aren't in the original image.

ColorThink would be very slow with even moderately sized images such as 1212x1418 pixels - if it didn't use the shortcut method that we don't even see it using - or, if it didn't have a more efficient algorithm to deal with them.  Like, it would run for 30 minutes and crashes slow.

So, if you give ColorThink Color Worksheet or 3D grapher an image with its longest dimension over 500 pixels, it internally resizes it so the long dimension is 500 pixels, and continues on.

This is reasonably to me.  We want ColorThink to be relatively fast.

The problem is that the internal resizing it uses is a resampling method that creates colors that aren't in the image given to ColorThink.  Only nearest neighbor (or similar algorithms that choose actual pixels from the source image) keeps the original colors in an image when downsizing.  Bilinear, bicubic, and others like that aim to making the downsized image look unpixelated, and the only way to do that is to blend the pixels.

At the link above, I show a process to verify this.  It involves creating a TIFF of alternating pure black and white pixels row by row.  ColorThink should see RGB 0/0/0 (LAB 0/0/0) and RGB 255/255/255 (LAB 100/0/0), however it sees neither of these.  It sees a bunch of values inbetween.

This doesn't just happen on the special case of alternating black/white pixels.  It happens on any image, whether it's a photograph, a scanned image, or a digitally created image, if its longest dimension is over 500 pixels.

It's showing you erroneous data, if you're doing something like seeing which media fits your file's gamut the best, or watching how pixel values change during profile conversions.

I found this because I had scanner images that don't have pixels within a few values of L* 100, but noticed ColorThink had pixels graphed way up there.  Took a few days to nail this one down.


WORKAROUND: Before giving ColorThink an image, resize it in your image editor so the longest dimension is 500 pixels -- USING nearest neighbor as your resampling method.

I always downsized an image before giving it to ColorThink, but I typically went with 1000 pixels on the longest dimension, figuring that was small enough.
Logged
Mike • Westland Printworks
Fine Art Printing • Amazing Artwork Reproduction • Photography
http://www.westlandprintworks.com • (734) 255-9761

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20614
  • Andrew Rodney
    • http://www.digitaldog.net/
Re: ColorThink Bug - Wrong values extracted from images with dimension > 500px
« Reply #1 on: September 28, 2013, 06:03:34 pm »

ColorThink would be very slow with even moderately sized images such as 1212x1418 pixels
I always downsized an image before giving it to ColorThink, but I typically went with 1000 pixels on the longest dimension, figuring that was small enough.
Yes it can be VERY slow and this is why I always feed it tiny files. Most of the time I'm feeding it files where one pixel represents one color value because often, I'm making color lists and there's no reason for redundant colored pixels. I guess it depends on what you want ColorThink to do from your images but the bottom line is, you have to feed it very small numbers of pixels. When I feed it say a target, even one with a few thousand patches will be small when one samples (nearest Neighbor) such that you end up with one pixel per color patch value.
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

xpatUSA

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 390
    • Blog

May I ask if this thread applies to all versions of colorThink?

I use Version 3 on my older desktop 32-bit computer.

Logged
best regards,

Ted

darlingm

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 361
    • Westland Printworks

May I ask if this thread applies to all versions of colorThink?

I use Version 3 on my older desktop 32-bit computer.

I use ColorThink Pro v3.0.3, so all I know for sure is that it's in that version.

My guess is that it's in older versions as well.  I'm sure that previous versions downsized to 500px on longest dimension for speed reasons.  I wouldn't expect that at one point the downsampling would have been using nearest neighbor then later changed to bilinear or bicubic.

You can tell for sure by downloading this test file: http://www.westlandprintworks.com/temp/black-white-stripes-640x640px.tif

Try graphing it.  If you only see a point at L* 100 and at L* 0, there's no bug.  More likely, if you see no points there but quite a few points between the two, there's a bug.

Inspect the TIFF in Photoshop (zoom in to see actual pixels), and it's all pure black or white pixels.

Again, the "easy" workaround is to resize to 500px longest dimension in your editor -- using nearest neighbor instead of auto, bicubic, or bilinear.
Logged
Mike • Westland Printworks
Fine Art Printing • Amazing Artwork Reproduction • Photography
http://www.westlandprintworks.com • (734) 255-9761

xpatUSA

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 390
    • Blog

I use ColorThink Pro v3.0.3, so all I know for sure is that it's in that version.

My guess is that it's in older versions as well.

You can tell for sure by downloading this test file: http://www.westlandprintworks.com/temp/black-white-stripes-640x640px.tif

Try graphing it.  If you only see a point at L* 100 and at L* 0, there's no bug.  More likely, if you see no points there but quite a few points between the two, there's a bug.

Inspect the TIFF in Photoshop (zoom in to see actual pixels), and it's all pure black or white pixels.

Again, the "easy" workaround is to resize to 500px longest dimension in your editor -- using nearest neighbor instead of auto, bicubic, or bilinear.

Thanks for the input . .

I have Version 2.3. I tried the test and wished I had not  :-[ the 640x640 file showed up as 3 dots around 50% L*

"Aha!", I go, and re-size it to 480x480px, check for all black and white stripes and graph it again. Now there are 6 dots up and down the L* pole. In the back of my mind, the number 256 has sprung up. Hmmm . .  one more test.

later,

. . . I'm back. V 2.3 sucks, may never trust it again. Re-sized to 256px it now shows as approx 21 dots up and down the pole, with black nowhere near the bottom and white nowhere near the top.

I guess pure black and pure white content is some sort of special case, gamuts with non-neutral colors have 'looked' OK before, but how would you know ?!

Off to look at Bruce's color card simulation now . .

It looked as one might expect, although difficult to assess as regards the bug.

Getting late, g'night!
« Last Edit: October 05, 2013, 01:20:14 am by xpatUSA »
Logged
best regards,

Ted

darlingm

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 361
    • Westland Printworks

. . .the 640x640 file showed up as 3 dots around 50% L*

Surprising to me.  In 3.0.3, I get 21 dots ranging from L* 13.39 to 92.46.  All right around A & B of 0.  Maybe the older version uses a different resampling algorithm.

"Aha!", I go, and re-size it to 480x480px, check for all black and white stripes and graph it again. Now there are 6 dots up and down the L* pole. In the back of my mind, the number 256 has sprung up. Hmmm . .  one more test.

later,

. . . I'm back. V 2.3 sucks, may never trust it again. Re-sized to 256px it now shows as approx 21 dots up and down the pole, with black nowhere near the bottom and white nowhere near the top.

Also surprising.  If you use nearest neighbor resampling to 500px or less on longest size, it should extract and/or graph correctly - at least in v3.0.3.  Any chance the resampling method you used when downsizing was set to auto, bilinear, or bicubic?

Photoshop resizing using nearest neighbor produces the correct L* 0 & L * 100 points and no phantom dots for me, in v3.0.3.

I guess pure black and pure white content is some sort of special case, gamuts with non-neutral colors have 'looked' OK before, but how would you know ?!

It's not just pure black & white content.  That was just an easy case to illustrate.  Any image is going to do this - it's just the nature of the "better" resampling techniques that are aiming to make the new image look good rather than restrict it to original color content.  See another post by me, from last year when I hadn't nailed down what was going wrong, that shows how it can act with non neutral colors, here: http://www.luminous-landscape.com/forum/index.php?topic=71561.0  -- The first and third graphs should be identical, and they are massively different.  All the image extracted dots in the third image are by definition forced to be within the transparent printer profile, yet tons of them are way outside of it.
Logged
Mike • Westland Printworks
Fine Art Printing • Amazing Artwork Reproduction • Photography
http://www.westlandprintworks.com • (734) 255-9761

xpatUSA

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 390
    • Blog

Yes, I did use nearest neighbor re-sampling. Thanks for the additional info re: not just black and white.

Now I understand the point a lot better. I have the Norman Koren color-card simulation file in sRGB where the patches are homogenous in in color and realized that this should present as one dot for each color patch and one for the image background, duh!

I fired up ColorThink and, sure enough, each color was spread out with a number of dots per color. Furthermore, the yellow patch was badly color clipped at the sRGB boundary and also patch 12 to a lesser extent.

Check it out . . . (with "tone using L*" unchecked)



Horrible. . . . and it said "5900 colors" in my TIFF image of the 24 patches and a gray background !!

The implication being that, for me (I don't print), something like a sunflower image might have out-of-gamut yellows or it might not! Apart from the fuzzy presentation of single colors, that is.
« Last Edit: October 06, 2013, 02:03:46 am by xpatUSA »
Logged
best regards,

Ted
Pages: [1]   Go Up