Newsgroup sci.image.processing 22576

rubinsnk@is2.nyu.edu (Kalman Rubinson) writes:
> S Butterfield (CoMIR) (stuart@scs.leeds.ac.uk) wrote:
> > Can anyone out there give me pointers towards how one might go about
> > transforming a black and white image into (something) like the original
> > colours?
The colour -> greyscale transformation is generally *not* invertable. If you
look at the conversion from color to b/w you see that a lot of
colours will be mapped to the same shade of grey (in a sense the color, let's
say represented by the Hue value, is *independent* from the brightness of a
pixel in an image).
So I don't see how to do it unless you know a lot of additional things
about your image (how to segment into areas of equal colour, which original
colour, etc.). There are circumstances where that might apply (you are
colouring an image of a place well known to you) but it is probably very hard
to automate and more something for an artist.
Best regards,
  Christian
--------------------------------------------------------------------
Christian Soeller                         mailto: csoelle@sghms.ac.uk
St. Georges Hospital Medical School       Dept. of Pharmacology
Cranmer Terrace                           London SW17 0RE

Robert Smith  wrote:
>tsui@mhd1.pfc.mit.edu wrote:
>> 
>> Dear friends:
>> 
>> I has a question and hope that you can give me some hints:
>> 
>> How to downsample an image without aliasing effect?
>> 
>> Thank you very much for your attention. I am waiting for your response.
>> 
>> Sincerely,
>> 
>> Chiwa Tsui
>The basic idea is not to throw away any spatial information.  For 
>example, if you were going to shrink the image 2x, you would create 
>"new" pixels by averaging a 2x2 array of the original pixels.  (The 
>alternative, discarding 3 out of 4 pixels is the best way to GET 
>aliasing!)
>  This is great if you're changing size by an integer, but it's harder 
>when you're not.  In that case you will have to create virtual pixels 
>with weighted averages.  e.g. Suppose you want a pixel which is 2/3 of 
>the way between 2 existing pixels; you must weight this pixel by adding 
>2/3 of one original pixel and 1/3 of the other.
>  Now we come to 2D.  There really is no obviously best way of 
>interpolating a pixel which falls between 4 existing pixels in 2D. 
>Fortunately it's not critical for most purposes so do a 1D interpolation 
>along all the rows, and then do it again along the resulting columns. 
>(Fancier than this requires curvilinear interpolation, and is rarely 
>necessary to avoid aliasing.)
As I said in a previous posting, you just need to avoid frequency
foldover.  If you avoid frequency foldover you will not have aliasing
and you should be able to reconstruct the original signal.
Best way to avoid frequency foldover, is to filter out unnecessary
information.  Usually, this unneeded information is in the high
frequency range.  This is why LPF are used.
If you downsample by K where K is an integer in ]1,max(width,height)],
you need to remove (K-1)/K of the frequency range.
To keep it simple, you simply design a filter with the required
cut-off frequency and a good roll-off.  Averaging the image for an
2x2 array is the same as using the
    1  1
    1  1
filter.  Its cutoff frequency is before 1/2 and this is why it works.
But, it is not the best filter for that kind of job, you can design
a better filter using    fir1(#tap, 0.5)  in Matlab  (it is a 1-D
filter but use  conv2(ans,ans') to have a 2-D equivalent (it is
separable but sufficient).
========
If you want to interpolate your data (which is different from
downsampling and usually used in upsampling), you could just use a
bilinear or a bicubic interpolation.  bicubic interpolation is not a
major improvement over bilinear interpolation.
For interpolation during upsampling, K=2:
zero order interpolation:
    1   1
    1   1
bilinear interpolation:
   1   2   1  
   2   4   2   
   1   2   1
========
If you want to interpolate a new image using bilinear interpolation
(like the 1/3, 2/3 problem of the previous poster):
Let's define coordinates a(ax,ay), b(bx,by), c(cx,cy) and d(dx,dy):
     a-----b
      |      |
     c-----d
where bx = dx = ax+1 = cx+1  and  by = ay = cy+1 = dy+1
if e(ex,ey) is inside abcd then, you can find its value by using:
e = (b-a) (ex-ax) + (d-c-b+a) (ex-ax)(ey-ay) + (c-a) (ey-ay) + a
which is bilinear interpolation.
Hope this answer you question...
			PMT
PS:
If I am wrong with my argumentation, please let me know.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Pierre-Martin Tardif, graduate student  email: tardif@gel.ulaval.ca
Computer Vision and Systems Lab         http://www.gel.ulaval.ca/~tardif
Laval University, Ste-Foy, Canada       phone: 418-656-2131, 4848

FS: #9 Imagine 128 Series I w/4 MB VRAM $350
Bought in January 96, incompatible with Portrait Display Labs Pivot 1700
monitor (PDL never wrote pivot-mode drivers after long wait), selling in
like new condition, with book, disks, & blank registration card.  Used for
only 3 months, sat in a static bag since then.
Price firm, terms 2-day FedEx C.O.D., s/h included in price.  Continental
United States only.  E-mail inquiries only, first come, first served.
Respond to:
intevans@aol.com

Michel Voue  wrote in article
<3283240E.41C6@gibbs.umh.ac.be>...
> What should be to structure (header and data organization) of images
> corresponding to the ITI .img format ?
I wrote this based on the info from an old manual of a ITI PCVisionPlus
framegrabber,
I do not know if they have modified the format since then, but you can try.
You can use the following C structure:
typedef unsigned char uchar;     /* 8-bit unsigned character */
typedef unsigned short uint16;    /* 16-bit unsigned integer */
/*  64 bytes of header */
typedef struct {
	uchar          I;
			/* Should be character 'I' */
	uchar          M;		
			/* Should be character 'M' */               
	uint16          c_size;	
			/* Size of 'comment' string that follows header*/
	uint16          width, height;
			/*  Size of image in pixels */
	uint16          h_pos, v_pos;	
			/* horizontal and vertical offsets of image */
	uint16          f_type;		
			/* file "type", set to zero? */
	uchar          reserved[50];
			/* set to zero? */
}  img;
You can do a binary read of the first 64 bytes of the file and that should
give you the header. You might have to swap the byte order of the
16-bit integers to get the actual values depending on your computer
(do not have to on Intel PC's)
After the 64 bytes of header comes "c_size" bytes of a "comment" string,
and after that comes the image data starting from the top-left corner
(width*height bytes (unsigned char))
Hope this helps
Oscar del Rio

Here at W.M. Keck Observatory, we are in need of a new image processing
system for use in our Adaptive Optics system.  We are running VxWorks on
a Force40 CPU in a VME cage.  We have narrowed the choices to two...
	Imaging Technology Inc.
	DataCube MaxVideo-200
We have cost comparisons, but are interested in getting some feedback on
ease of use.  We have heard that DataCube systems are difficult to
program, and have heard nothing at all about the ITI ease of use or
programming.  Obviously it will be application dependent, but we would
like to just get a gut feeling.
Can anyone tell us anything about the ease of use of these two systems?
Any horror stories?  Any testimonials?  Any recommendations? 
Thanks,
Paul Stomski
Adaptive Optics Software Engineer
W.M. Keck Observatory
Kamuela, Hawaii

A couple of other books which discuss the Hough transform are:
    _Computer Vision_ by Ballard and Brown
and
    _Digital Image Processing_ by Pratt
Sorry that I don't have more complete references to these two books.
_Computer Vision_ discusses the Hough transform for lines and for
circles, and then goes on to discuss the "generalized" Hough transform.
_Digital Image Processing_ discusses discussed the Hough transform for
lines, but does not go on to other objects.
Neither book gives actual code which implements the Hough transform
but they are simple enough algorithms that it is possible to write
code without much thought after reading the verbal description.
While it is fairly straightforward to write code which implements the
Hough transform, it can be rather rather slow, especially for circles
where you have 3 parameters.  If these is being used in an application
where you want results while you wait, instead of letting something
run overnight, you must find ways to limit the range of candidate
parameter values.  This may involve apriori knowledge about where in
the image you'd expect to find the circle(s) you are looking for and/or
what range of circle sizes you are looking for.
I've used the Hough transform for circles to precisely determine the
center of the Solar disk in each of a series of digitized images of
the Sun during the partial phases of a solar eclipse.  In some ways
these images are easier to work because of the very high contrast
between the solar disk vs. the Moon and the rest of the sky.  One might
ask why I didn't do something simple like find the centroid of all the
bright pixels or find the centroid of the boundary between the bright
and dark pixels.  Such methods probably work find when the entire
disk of the Sun is visible, but as more and more of the Sun is eclipsed
by the Moon, the position of the centroid becomes skewed further and
further from the true center of the disk of the Sun.  The the problem
was not to find the center of a full circle, which is rather easy, but
to find the center of a circular arc forming the uneclipsed part of the
limb of the Sun, and not be distracted by the circular are forming the
part of the limb of the Moon which is in front of the Sun.
A trick I used to limit the number of candidate positions of the center
of the solar disk is to first find the minimal (smallest sized) bounding
circle which surrounds the edge pixels.  This is some cases may be
somewhat larger than the solar disk since there may be stray bright
spots in the photo due to dust/scratches on the negatives, etc.
To find the mimimal bounding circle, I first found the bounding box of
the edge pixels.  Then I came up with a relatively small rectangular
region where the center of the mimimal bounding circle must be within.
This can be defined by noting that the diameter of the minimal bounding
circle must be at least as large as the sides of the bounding box in
its longer direction, but can't be any larger than the length of the
diagonal of the bounding box.  I then tried each candidate center
point to determine when one resulted in the smallest circle which
contained all of the edge points.  To reduce the amount of computation
I used just a subset of the edge points which I call the "corner" points
these are edge points which are not colinear with any two of its
neighboring edge points.
Once the size of the mimimal bounding circle is known, I used it, the
bounding box, and the fact that at least 180 of the Sun's limb is
always visible (since this was an annular eclipse in which the apparent
size of the Moon is slightly smaller than the apparent size of the Sun
- this wouldn't work for the later partial phases leading up to a TOTAL
eclipse of the Sun, BTW) to come up with a different releatively small
candidate locations for the center of the circular arc forming the
limb of the Sun.  With the sufficiently limited set of center positions
I was able to determine the center and radius of the Solar disk to
the resolution of individual pixels in about 20 or 30 seconds of CPU 
time on an HP PA-RISC workstation (or about a couple of minutes of CPU 
time on a 100 MHz Pentium PC).  Not exactly extremely lightening speed,
but a lot faster than the hours of CPU time it might take for the Hough
transform if I tried every pixel position in the image as a candidate
center location.
A more difficult problem, at which I was somewhat less than sucessful
in solving using the Hough transform is finding the center of the
disk of the Moon in these eclipse photos.  Since in most of the images
less than 180 degrees of the limb of the Moon is in front of the Sun
and is thus visible (there's too much glare from the exposed part of
the Sun in that part of the sky to see the boundary between the dark
side of the Moon facing the Earth and the sky surrounding the part of
the Moon that is not in front of the Sun).  Thus my minimal bounding
circle optimization can be used and so I used other less reliable
heuristic methods for guessing the general location of the center of
the Moon.  Many times the guess is not very good and may totaly miss
where the center of the Moon really is.
-Michael

A couple of other books which discuss the Hough transform are:
    _Computer Vision_ by Ballard and Brown
and
    _Digital Image Processing_ by Pratt
Sorry that I don't have more complete references to these two books.
_Computer Vision_ discusses the Hough transform for lines and for
circles, and then goes on to discuss the "generalized" Hough transform.
_Digital Image Processing_ discusses discussed the Hough transform for
lines, but does not go on to other objects.
Neither book gives actual code which implements the Hough transform
but they are simple enough algorithms that it is possible to write
code without much thought after reading the verbal description.
While it is fairly straightforward to write code which implements the
Hough transform, it can be rather rather slow, especially for circles
where you have 3 parameters.  If these is being used in an application
where you want results while you wait, instead of letting something
run overnight, you must find ways to limit the range of candidate
parameter values.  This may involve apriori knowledge about where in
the image you'd expect to find the circle(s) you are looking for and/or
what range of circle sizes you are looking for.
I've used the Hough transform for circles to precisely determine the
center of the Solar disk in each of a series of digitized images of
the Sun during the partial phases of a solar eclipse.  In some ways
these images are easier to work because of the very high contrast
between the solar disk vs. the Moon and the rest of the sky.  One might
ask why I didn't do something simple like find the centroid of all the
bright pixels or find the centroid of the boundary between the bright
and dark pixels.  Such methods probably work find when the entire
disk of the Sun is visible, but as more and more of the Sun is eclipsed
by the Moon, the position of the centroid becomes skewed further and
further from the true center of the disk of the Sun.  The the problem
was not to find the center of a full circle, which is rather easy, but
to find the center of a circular arc forming the uneclipsed part of the
limb of the Sun, and not be distracted by the circular are forming the
part of the limb of the Moon which is in front of the Sun.
A trick I used to limit the number of candidate positions of the center
of the solar disk is to first find the minimal (smallest sized) bounding
circle which surrounds the edge pixels.  This is some cases may be
somewhat larger than the solar disk since there may be stray bright
spots in the photo due to dust/scratches on the negatives, etc.
To find the mimimal bounding circle, I first found the bounding box of
the edge pixels.  Then I came up with a relatively small rectangular
region where the center of the mimimal bounding circle must be within.
This can be defined by noting that the diameter of the minimal bounding
circle must be at least as large as the sides of the bounding box in
its longer direction, but can't be any larger than the length of the
diagonal of the bounding box.  I then tried each candidate center
point to determine when one resulted in the smallest circle which
contained all of the edge points.  To reduce the amount of computation
I used just a subset of the edge points which I call the "corner" points
these are edge points which are not colinear with any two of its
neighboring edge points.
Once the size of the mimimal bounding circle is known, I used it, the
bounding box, and the fact that at least 180 of the Sun's limb is
always visible (since this was an annular eclipse in which the apparent
size of the Moon is slightly smaller than the apparent size of the Sun
- this wouldn't work for the later partial phases leading up to a TOTAL
eclipse of the Sun, BTW) to come up with a different releatively small
candidate locations for the center of the circular arc forming the
limb of the Sun.  With the sufficiently limited set of center positions
I was able to determine the center and radius of the Solar disk to
the resolution of individual pixels in about 20 or 30 seconds of CPU 
time on an HP PA-RISC workstation (or about a couple of minutes of CPU 
time on a 100 MHz Pentium PC).  Not exactly extremely lightening speed,
but a lot faster than the hours of CPU time it might take for the Hough
transform if I tried every pixel position in the image as a candidate
center location.
A more difficult problem, at which I was somewhat less than sucessful
in solving using the Hough transform is finding the center of the
disk of the Moon in these eclipse photos.  Since in most of the images
less than 180 degrees of the limb of the Moon is in front of the Sun
and is thus visible (there's too much glare from the exposed part of
the Sun in that part of the sky to see the boundary between the dark
side of the Moon facing the Earth and the sky surrounding the part of
the Moon that is not in front of the Sun).  Thus my minimal bounding
circle optimization can be used and so I used other less reliable
heuristic methods for guessing the general location of the center of
the Moon.  Many times the guess is not very good and may totaly miss
where the center of the Moon really is.
-Michael

Here is an excerpt from section entitled "PBM, PGM, PNM, and PPM" from
the book _Encyclopedia of Image File Formats_ by Murray and vanRyper,
published by O'Reilly:
    RAWBITS Variant
    There is also a variant of the format, available by setting the
    RAWBITS option at compile time.  This variant differs from the
    traditional format in the following ways:
    - The "magic numbers" are as follows:
      Format   Normal   RAWBITS Variant
      PBM       P1      P4
      PGM       P2      P5
      PPM       P3      P6
    - The pixel values are stored as plain bytes, instead of ASCII
      decimal:
      PBM   RAWBITS is eight pixels per byte
      PGM   RAWBITS is one pixel per byte
      PPM   RAWBITS is three bytes per pixel
    - White space is not allowed in the pixel area, and only a single
      character of white space (typically a newline) is allowed after
      the MaxGrey value.
    - The files are smaller and many times farster to read and write.
    - Bit order within the byte is most significant bit (MSB) first.
    Note that this raw format can only be used for maximum values of
    less than or equal to 255.  If you use the PPM library and try to
    write a file with a larger maximum value, it automatically uses the
    slower, but more general, plain format.
-Michael

Hi,
I'm the technology editor of Vision System Design magazine, a new
publication from Penwell Publications (Computer Design, Laser Focus) for
image processing professionals.
My January piece is on pattern recognition and I'm looking for a couple
sidebars on leading-edge research to accompany the piece. Topics I'm
looking for include medical imaging pattern recognition and automatic
target recognition. I'm also open to ideas.
Please contact me: Barry Phillips, barryp@ico.com, 408-633-0307.
Regards,

Speak for yourself Sheldon. LECO Corp sell an Image ANALYSIS product which
is less concerned with all the imaging terminology and more concerned with
making actual measurements and using this data in reports automatically.
> 
> Well to begin, there is no such thing as a 'user-friendly' imaging
> system.  To understand why this is so, you have to meet the people
> who write the software.  They are thinking in terms of words
> such as 'morphology' while you thinking 'immunohistochemical staining'.
> What you need is a person to do translation and provide the goodies
> you need.
> 

I am looking for information regarding the CIE value for NTSC and PAL 
television Red, Green, and Blue phosphors.
I image it's somewhere around 470, 540, and 620 for NTSC (6500K) Is PAL based 
on a different colour temperature?
thanks,
Rob Chambers.
-- 
>> Satellite Control v2.3 is now available! Supports MT810/830 <<
>> For information, or to download http://infomatch.com/~robgc <<

Rob Chambers (robgc@infomatch.com) wrote:
: I am looking for information regarding the CIE value for NTSC and PAL 
: television Red, Green, and Blue phosphors.
I assume you mean the specification for the display primaries.
: I image it's somewhere around 470, 540, and 620 for NTSC (6500K) Is PAL based 
: on a different colour temperature?
Colour primaries for television are not based on wavelengths, but are defined
by their chromaticity coordinates.
System M (525 NTSC or PAL)
     x     y
R    0.67  0.33
G    0.21  0.71
B    0.14  0.08
White balance is to Illuminant C
W    0.310 0.316
All other systems (625 PAL or SECAM)
     x     y
R    0.64  0.33
G    0.29  0.60
B    0.15  0.06
White balance is to Illuminant D65
W    0.313 0.329
Information from ITU-R BT.470
-- 
******* Alan Roberts ******* BBC Research & Development Department *******
* My views, not necessarily Auntie's, but they might be, you never know. *
**************************************************************************

tluu@thunder.ocis.temple.edu wrote:
>I am currently trying to the ultrasoud reasearch but I can't find any
>resoures on the internet. Could anyone helps me to find it.
>Thank you for your time.
>PLease, E mail me at tluu@thunder.ocis.temple.edu
The University of Michigan Biomedical Ultrasonics Laboratory's WWW
pages have abstracts, data sets, papers and relevant animations.  Areas of
research include ultrasonic imaging and therapy.
  http://bul.eecs.umich.edu