Recent

Author Topic: clNone etc.  (Read 8508 times)

user5

  • Sr. Member
  • ****
  • Posts: 357
clNone etc.
« on: June 08, 2021, 09:05:17 am »
    The code I'm working on at some point asks the user to choose a 'work' color that does not exist anywhere in the image.
    This color is used for various operations and is eventually removed. After a color is chosen it's of course easy for the
program to find out if it's in the image or not but does anyone know of a way for the program to quickly pick a work color
that does not exist in the image without prompting the user or is there a way to create a color that does not exist on the palatte?
    I'm already using clNone for a particular purpose so I can't use it as the work color.

circular

  • Hero Member
  • *****
  • Posts: 4220
    • Personal webpage
Re: clNone etc.
« Reply #1 on: June 10, 2021, 01:55:46 pm »
The color needs to be an actual color I suppose? If that's the case, what you could do is create a list of all colors in the image, sort them, and then find the first gap in the palette.

Though maybe there would be another way than having such work color. What are you actually doing with it?
Conscience is the debugger of the mind

user5

  • Sr. Member
  • ****
  • Posts: 357
Re: clNone etc.
« Reply #2 on: June 11, 2021, 08:59:29 am »
    It's hard to explain but I'll try since you took the time to respond.
    The attached raster scan picture img1.gif shows a picture (a clRed ball) before before edge softening is applied to it. The background under the image is clWhite and the image will be edged to clWhite. The user picks clYellow as the work color and img2.gif shows the image after some preliminary edging other than gradients has been applied to it. You would have to look closely to notice that some of the pixels are slightly lighter than clRed. The use of clYellow or any other color as a work color is not new and has been used before in theory and practice. The picture img3.gif shows the image after the edging is done and img4.gif shows the image after it is made to be transparent.
    You mentioned making a list and I guess that you might have referred to TList or something like that. Such a list could become quite large if the image has many colors and I still haven't figured out how to find a color that is not in the image. After a list is made of all the colors in the image (in this case just clRed and clAqua) then how would the program find a color that is not in the image like clBlue, clYellow etc?

user5

  • Sr. Member
  • ****
  • Posts: 357
Re: clNone etc.
« Reply #3 on: June 11, 2021, 09:02:21 am »
    I noticed that the pictures I attached don't look right until you left click and enlarge them a bit.

user5

  • Sr. Member
  • ****
  • Posts: 357
Re: clNone etc.
« Reply #4 on: June 11, 2021, 09:13:32 am »
    I want to mention that the program I'm working on does have a tool that searches for a chosen
color and informs the user if that particular color exists or not in the image and this is some help
but it would be so much better if the program could automatically choose a work color instead of
requiring the user to choose it.

Thaddy

  • Hero Member
  • *****
  • Posts: 14369
  • Sensorship about opinions does not belong here.
Re: clNone etc.
« Reply #5 on: June 11, 2021, 11:17:58 am »
I think the sort is an idea, BUT:
A color that initially is not used can logically be introduced by any sharpen or soften algorithm and then you have a problem, Houston....

(Ofcourse TRUE sharpen does not have that issue, but the terms are used rather liberaly)
« Last Edit: June 11, 2021, 11:22:21 am by Thaddy »
Object Pascal programmers should get rid of their "component fetish" especially with the non-visuals.

user5

  • Sr. Member
  • ****
  • Posts: 357
Re: clNone etc.
« Reply #6 on: June 11, 2021, 01:52:51 pm »
    Until I read what Thaddy said I was going to use the pseudocode shown below. He makes a very good point
and it is something that I haven't considered. If I understand him correctly then what he's saying is: When the
gradients and the other edging colors are made then the program is in effect adding some new edging colors to
the image being edged. If any of these new colors = the work color then the results will not be exactly correct.
    Maybe the program needs to focus on what colors are UNDER the image instead of the colors in the image
(or both) since the matchup between the two are what determine the edging colors. I will have to think about
this for a while. Thank you very much Thaddy and circular for your comments.

Code: Pascal  [Select][+][-]
  1.  //Make a list of all the colors in the image.
  2.  //Sort list so that no color is shown more than once in the list
  3.  
  4.  colordecnum := 0; //start with clBlack
  5.  go := true;
  6.  cancel := false;
  7.  header := '$';
  8.  while (go) and (cancel = false) and (colordecnum <= 16777216) do //16777216 colors in palatte
  9.   begin
  10.    found := false;
  11.    tempstr := IntToHex(colordecnum,6);
  12.    tempstr := header+tempstr;
  13.    newcolor := StringToColor(tempstr);
  14.  
  15.    //search the list for newcolor
  16.    //if newcolor is in the list then
  17.     found := true;
  18.  
  19.    if found = false then //if after search found remains false then work color is found
  20.     begin
  21.      go := false;
  22.      workcolor := newcolor;
  23.     end;
  24.  
  25.    colordecnum := colordecnum + 1; //test the next color in the palatte if found = true
  26.   end;
  27.  
  28.  if go = true then
  29.   edit5.text := 'Cannot find a work color.';

Thaddy

  • Hero Member
  • *****
  • Posts: 14369
  • Sensorship about opinions does not belong here.
Re: clNone etc.
« Reply #7 on: June 11, 2021, 02:02:44 pm »
You understood me correctly.
Object Pascal programmers should get rid of their "component fetish" especially with the non-visuals.

Thaddy

  • Hero Member
  • *****
  • Posts: 14369
  • Sensorship about opinions does not belong here.
Re: clNone etc.
« Reply #8 on: June 11, 2021, 02:32:09 pm »
Oh, I just came up with this:
Look for the greatest span of unused colors after the sort and choose something in the middle.
That makes a clash highly - but not always - unlikely.
Indeed if there is a picture under yours, it is better to look for one in that..
In both cases you will loose just one pixel precision which is likely not visible to the human eye.
Object Pascal programmers should get rid of their "component fetish" especially with the non-visuals.

user5

  • Sr. Member
  • ****
  • Posts: 357
Re: clNone etc.
« Reply #9 on: June 11, 2021, 02:37:38 pm »
    The program generally does a pretty good job the way it is since the odds of conflict between a work color
and a newly created edging color that equals the work color are low but it can happen.
    What Thaddy said illustrates why clNone makes such a good work color since it should never exist in any of
the images involved. Unfortunately, the program already uses clNone as a work color but it also needs a
second work color and in some cases a third work color. If only there were clNone1, clNone2 and clNone3 then
I would be in business, hah, hah.
    I tried to create some non-existent work colors but the compiler wouldn't accept them I guess because they
weren't actual colors on the palatte.
    I'm sure glad Thaddy that you said what you said before and what you just said. Wow.
    Maybe I can work something out.

wp

  • Hero Member
  • *****
  • Posts: 11916
Re: clNone etc.
« Reply #10 on: June 11, 2021, 03:59:38 pm »
If only there were clNone1, clNone2 and clNone3 then
I would be in business, hah, hah.
Why not? I suppose you work in 24-bit Pixelformat - this means that the 4th byte is unused. Looking in the graphics unit you'll see this for clNone:
Code: Pascal  [Select][+][-]
  1. const
  2.  clNone    = TColor($1FFFFFFF);
This is a color with $1F in the unused 4th byte. There are some other predefined colors with something in the 4th byte:
Code: Pascal  [Select][+][-]
  1. const
  2.   clScrollBar               = TColor(SYS_COLOR_BASE or COLOR_SCROLLBAR);
  3.   clBackground              = TColor(SYS_COLOR_BASE or COLOR_BACKGROUND);
  4.   clActiveCaption           = TColor(SYS_COLOR_BASE or COLOR_ACTIVECAPTION);
  5.   clInactiveCaption         = TColor(SYS_COLOR_BASE or COLOR_INACTIVECAPTION);
  6.   clMenu                    = TColor(SYS_COLOR_BASE or COLOR_MENU);
  7.   clWindow                  = TColor(SYS_COLOR_BASE or COLOR_WINDOW);
  8.   clWindowFrame             = TColor(SYS_COLOR_BASE or COLOR_WINDOWFRAME);
  9.  ...
where SYS_COLOR and COLOR_* are defined in LCLTYPE to be
Code: Pascal  [Select][+][-]
  1. const
  2.   SYS_COLOR_BASE = TColorRef($80000000);
  3.   COLOR_SCROLLBAR = 0;
  4.   COLOR_BACKGROUND = 1;
  5.   COLOR_ACTIVECAPTION = 2;
  6.   COLOR_INACTIVECAPTION = 3;
  7.   COLOR_MENU = 4;
  8.   COLOR_WINDOW = 5;
  9.   COLOR_WINDOWFRAME = 6;
  10. ...
This means: They all have the normal r,g,b bytes but since there is a non-zero 4th byte they do not appear in the normal color space.

So, this is my idea: Take clNone and subtract 1 to get a clNone1, subtract 2 to get a clNone2 etc.
Code: Pascal  [Select][+][-]
  1. const
  2.   clNone1 = clNone - 1;  // $1FFFFFFE
  3.   clNone2 = clNone - 2;  // $1FFFFFFD
  4.   clNone3 = clNone - 3;  // $1FFFFFFC
  5.   clNone4 = clNone - 4;  // $1FFFFFFB
  6.   ...
There 16777215=$FFFFFF ways to construct a clNone variant according to this pattern. Or even more if you relax the requirement that the 4th byte must be $1F. It only cannot be $00 (this is reserved for a normal RGB color) or $80 (this is reserved for a system color - see above). Nothing prevents you to define a
Code: Pascal  [Select][+][-]
  1. const
  2.   cMyOwnNoColor = $99012345;

circular

  • Hero Member
  • *****
  • Posts: 4220
    • Personal webpage
Re: clNone etc.
« Reply #11 on: June 11, 2021, 09:22:28 pm »
Indeed as wp says, if you have your own storage on 4 bytes, then you can put any special value as a color.

Otherwise, maybe the simplest would be to create mask: a 2d array of booleans that says if a pixel is on the edge. Thus you would have the information instead of painting an arbitrary color.
Conscience is the debugger of the mind

user5

  • Sr. Member
  • ****
  • Posts: 357
Re: clNone etc.
« Reply #12 on: June 11, 2021, 09:45:39 pm »
    I tested your suggestions wp and got some interesting results.
    When I set the TColor variable nocolor1 to your suggestion of $1FFFFFFE then the program searched through
all 16777215 (ie 0 to 16777214) palatte colors without finding a match, which is good because it means that
nocolor1 does not exist on the palatte and I can use it as a workcolor. However, when I applied that color to
image13 and then took a color sampling of image13 the program showed the result as $00FFFFFE, not $1FFFFFFE.
    When I set nocolor1 to $00FFFFFE and applied it to image13 then a color sampling showed $00FFFFFE but a
search of the palatte colors was only successful if the search was limited to 16777214 colors, not 16777215 colors.
    The code I used is shown below.
    I must be missing something here or this situation is simply due to a formatting issue or something like that.
    The results are encouraging. Should I use $1FFFFFFE or $00FFFFFE?
    Thank you so much.

Code: Pascal  [Select][+][-]
  1.  nocolor1 := StringToColor('$1FFFFFFE');
  2.  go := true;
  3.  cancel := false;
  4.  header := '$';
  5.  found := false;
  6.  counter := 0;
  7.  
  8.  while (go = true) and (cancel = false) do
  9.   begin
  10.  
  11.    if counter <= 16777214 then
  12.     begin
  13.      tempstr := IntToHex(counter,6);
  14.      tempstr := header+tempstr;
  15.      newcolor := StringToColor(tempstr);
  16.     end
  17.    else
  18.     go := false;
  19.  
  20.    if go then
  21.    if (newcolor = nocolor1) then
  22.     begin
  23.      go := false;
  24.      found := true;
  25.     end;
  26.  
  27.    if (go = true) and (counter >= 100000) and ((counter mod 100000) = 0) then
  28.     begin
  29.      str(counter,tempstr);
  30.      edit4.text := tempstr;
  31.      application.processmessages;
  32.     end;
  33.  
  34.    if counter = 16777214 then
  35.     go := false
  36.    else
  37.     counter := counter + 1;
  38.  
  39.   end;
  40.  
  41.  str(counter,tempstr);
  42.  edit4.text := tempstr;
  43.  application.processmessages;
  44.  
  45.  if found = true then
  46.   edit5.text := 'nocolor1 exists on palatte.'
  47.  else
  48.   edit5.text :='nocolor1 does not exist on palatte';

wp

  • Hero Member
  • *****
  • Posts: 11916
Re: clNone etc.
« Reply #13 on: June 11, 2021, 09:55:32 pm »
I think you are right. When you use the clNone1 to paint something on the canvas with it, the 4th byte will be stripped off because the pixelformat is 24bit. And then $1FFFFFFE will be the same as the "real" color $00FFFFFE. Forget this idea...

user5

  • Sr. Member
  • ****
  • Posts: 357
Re: clNone etc.
« Reply #14 on: June 11, 2021, 10:36:03 pm »
    The way things stand now, I do have a fallback compromise solution. It the picture or video doesn't have
many colors then the user should have no problem in choosing a work color. If the image has many colors and
the user is in doubt then he or she can have the program come up with the work color by searching the image.
    However, I will then still have the problem that Thaddy mentioned to deal with.
    In any event, thanks for helping me. I'll check back here later in case someone has additional suggestions.

 

TinyPortal © 2005-2018