FFT>Bandpass Filter: How to exclude particles or other foreground objects?

[Ovrec]

Hello everybody
I'm using the FFT>Bandpass Filter to suppress horizontal stripes (streaks) in AFM images.
Is there a way to exclude particles or other foreground objects from the fit? ...like selecting a threshold to include the background only and thus restricting the stripes suppression only to a selection (i.e., to the background).

Thank you in advance

[Cammer, Michael]

Set the spots to exclude to zero.
see  http://www.einstein.yu.edu/aif/instructions/fft/lasernoisefilter/confocal-lines.htm

_________________________________________
Michael Cammer, Assistant Research Scientist
Skirball Institute of Biomolecular Medicine
Lab: [phone]  Cell: [phone]

________________________________________
From: ImageJ Interest Group [[hidden email]] On Behalf Of Ovrec [[hidden email]]
Sent: Thursday, October 14, 2010 9:03 AM
To: [hidden email]
Subject: FFT>Bandpass Filter: How to exclude particles or other foreground objects?

Hello everybody
I'm using the FFT>Bandpass Filter to suppress horizontal stripes (streaks)
in AFM images.
Is there a way to exclude particles or other foreground objects from the
fit? ...like selecting a threshold to include the background only and thus
restricting the stripes suppression only to a selection (i.e., to the
background).

------------------------------------------------------------
This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is proprietary, confidential, and exempt from disclosure under applicable law. Any unauthorized review, use, disclosure, or distribution is prohibited. If you have received this email in error please notify the sender by return email and delete the original message. Please note, the recipient should check this email and any attachments for the presence of viruses. The organization accepts no liability for any damage caused by any virus transmitted by this email.
=================================

[Ovrec]

Thank you for your reply.
What do you mean exactly?
I can not understand...

[Michael Schmid]

Hi Ovrec,

a Fourier transform always uses the full image, you can't exclude  
areas from it. This also applies to filters in the Fourier domain.

If your objects are small enough, a simple approach would be the  
'Fast Filters' with filter type 'Background from minima' and a radius  
that is larger than that of all objects. The Fast Filters plugin can  
also subtract the background from your image without an additional step.

What you could also do - this is more like your original idea:
- duplicate the image
- threshold the objects
- Create Selection from the threshold
- remove the objects useing several iterations of 'Fast Filters',  
blur ('Border-limited mean') in x direction only (y Radius = 0)
- Use a Fourier filter (Custom Filter) that keeps the streaks instead  
of removing them, i.e. a filter function with a vertical bar in the  
center having a value of 255 (use Gaussian blur to avoid sharp edges)
- Subtract the result from the original.

(Instead of the Custom Fourier filter, you could also try the Fast  
Filters, blur the full image in x direction to create the background.)


If it did not come with your distribution of ImageJ, the Fast Filters  
plugin is available at
   http://imagejdocu.tudor.lu/doku.php?
id=plugin:filter:fast_filters:start


Michael
________________________________________________________________

On 14 Oct 2010, at 15:03, Ovrec wrote:

> Hello everybody
> I'm using the FFT>Bandpass Filter to suppress horizontal stripes  
> (streaks)
> in AFM images.
> Is there a way to exclude particles or other foreground objects  
> from the
> fit? ...like selecting a threshold to include the background only  
> and thus
> restricting the stripes suppression only to a selection (i.e., to the
> background).
>
> Thank you in advance
>
>
>
>
> -----
> Ovrec

[Dr. Harald von der Osten]

Hello everybody,


how can I import an ascii file consisting out of nearly 5 million z  
values in one row. I mean: how can I tell the plugin that the values  
should be transformed to an binary image of the size x by y? Is there  
a possibility of a header, for example:



10000, 4800
value no. 1
value no. 2
:
value no. 48000000

Thanks a lot. By the way: must be the range of the value between 0 <=  
z <= 255 (integer)?


Harald

[Adrian Daerr-2]

Hello Harald,

> how can I import an ascii file consisting out of nearly 5 million z
> values in one row.

Supposing that your z values are separated only by whitespace (spaces,
tabs, newlines), it should suffice to prepend (using a text editor for
example) the following lines to your file:

P2
<width> <height>
<maxval>

where <width> and <height> are your x and y dimensions, and <maxval> is
the maximum z value (must be smaller or equal 65535; in your case 255 ?).
The resulting image should be read by ImageJ as a portable gray map
(pgm) image.

Below is the manual page for the pnm/pgm format copied from a Linux box.

cheers
Adrian

NAME
 pgm - portable graymap file format


DESCRIPTION
 The  PGM  format  is a lowest common denominator grayscale file format.
 It is designed to be extremely easy to learn and  write  programs  for.
 (It's  so  simple  that  most  people  will  simply reverse engineer it
 because it's easier than reading this specification).

 A PGM image represents a  grayscale  graphic  image.   There  are  many
 psueudo-PGM  formats  in  use  where  everything is as specified herein
 except for the meaning of individual pixel values.  For most  purposes,
 a  PGM image can just be thought of an array of arbitrary integers, and
 all the programs in the world that think they're processing a grayscale
 image can easily be tricked into processing something else.

 One  official  variant of PGM is the transparency mask.  A transparency
 mask in Netpbm is represented by a PGM image, except that in  place  of
 pixel intensities, there are opaqueness values.  See below.


 The format definition is as follows.

 A  PGM file consists of a sequence of one or more PGM images. There are
 no data, delimiters, or padding before, after, or between images.

 Each PGM image consists of the following:

 - A "magic number" for identifying the file type.  A pgm image's  magic
   number is the two characters "P5".

 - Whitespace (blanks, TABs, CRs, LFs).

 - A width, formatted as ASCII characters in decimal.

 - Whitespace.

 - A height, again in ASCII decimal.

 - Whitespace.

 - The  maximum  gray  value  (Maxval), again in ASCII decimal.  Must be
   less than 65536.

 - Newline or other single whitespace character.

 - A raster of Width * Height gray values, proceeding through the  image
   in  normal English reading order.  Each gray value is a number from 0
   through Maxval, with 0 being black and Maxval being white.  Each gray
   value  is  represented in pure binary by either 1 or 2 bytes.  If the
   Maxval is less than 256, it is 1 byte.  Otherwise,  it  is  2  bytes.
   The most significant byte is first.

 - Each  gray  value  is  a  number proportional to the intensity of the
   pixel, adjusted by the CIE Rec. 709 gamma transfer  function.   (That
   transfer  function  specifies  a gamma number of 2.2 and has a linear
   section for small intensities).  A value of zero is therefore  black.
   A value of Maxval represents CIE D65 white and the most intense value
   in the image and any other image to which the  image  might  be  com?
   pared.

 - Note  that  a  common variation on the PGM format is to have the gray
   value be "linear," i.e. as specified above except without  the  gamma
   adjustment.   pnmgamma takes such a PGM variant as input and produces
   a true PGM as output.

 - In the transparency mask  variation  on  PGM,  the  value  represents
   opaqueness.   It  is  proportional  to the fraction of intensity of a
   pixel that would show in place of an underlying pixel, with the  same
   gamma  transfer  function  mentioned above applied.  So what normally
   means white represents total opaqueness and what normally means black
   represents  total  transparency.   In  between, you would compute the
   intensity of a composite pixel of an  "under"  and  "over"  pixel  as
   under * (1-(alpha/alpha_maxval)) + over * (alpha/alpha_maxval).<

 - Characters  from  a  "#"  to  the next end-of-line, before the maxval
   line, are comments and are ignored.

 Note that you can use pnmdepth To convert between a the format  with  1
 byte per gray value and the one with 2 bytes per gray value.

 There  is  actually  another  version  of the PGM format that is fairly
 rare: "plain" PGM format.  The format above, which generally considered

 the  normal one, is known as the "raw" PGM format.  See pbm(5) for some
 commentary on how plain and raw formats relate to one another.

 The difference in the plain format is:

 - There is exactly one image in a file.

 - The magic number is P2 instead of P5.

 - Each pixel in the raster is represented as an  ASCII  decimal  number
   (of arbitrary size).

 - Each  pixel in the raster has white space before and after it.  There
   must be at least one character of white space between any two pixels,
   but there is no maximum.

 - No line should be longer than 70 characters.

 Here is an example of a small graymap in this format:
 P2
 # feep.pgm
 24 7
 15
 0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
 0  3  3  3  3  0  0  7  7  7  7  0  0 11 11 11 11  0  0 15 15 15 15  0
 0  3  0  0  0  0  0  7  0  0  0  0  0 11  0  0  0  0  0 15  0  0 15  0
 0  3  3  3  0  0  0  7  7  7  0  0  0 11 11 11  0  0  0 15 15 15 15  0
 0  3  0  0  0  0  0  7  0  0  0  0  0 11  0  0  0  0  0 15  0  0  0  0
 0  3  0  0  0  0  0  7  7  7  7  0  0 11 11 11 11  0  0 15  0  0  0  0
 0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0

 Programs  that  read  this  format  should  be  as lenient as possible,
 accepting anything that looks remotely like a graymap.


COMPATIBILITY
 Before April 2000, a raw format  PGM  file  could  not  have  a  maxval
 greater than 255.  Hence, it could not have more than one byte per sam?
 ple.  Old programs may depend on this.

 Before July 2000, there could be at most one image in a PGM file.  As a
 result,  most  tools  to  process PGM files ignore (and don't read) any
 data after the first image.

AUTHOR
       Copyright (C) 1989, 1991 by Jef Poskanzer.

[Dr. Harald von der Osten]

Hi Adrian,


thnaks a lot for your help.

Unfortunately, TextReader says:

"Line 2 is not the same lenght as the first line"... and Fiji is killed.

The beginning of the data file is:


P2
8001 960
255
#
148
150
155
155
155
160
165
165
165
163
165
165
:

and so on. Hmmm...


Best wishes,

Harald



Zitat von Adrian Daerr <[hidden email]>:

> Hello Harald,
>
>> how can I import an ascii file consisting out of nearly 5 million z
>> values in one row.
>
> Supposing that your z values are separated only by whitespace (spaces,
> tabs, newlines), it should suffice to prepend (using a text editor for
> example) the following lines to your file:
>
> P2
> <width> <height>
> <maxval>
>
> where <width> and <height> are your x and y dimensions, and <maxval> is
> the maximum z value (must be smaller or equal 65535; in your case 255 ?).
> The resulting image should be read by ImageJ as a portable gray map
> (pgm) image.
>
> Below is the manual page for the pnm/pgm format copied from a Linux box.
>
> cheers
> Adrian
>
> NAME
>  pgm - portable graymap file format
>
>
> DESCRIPTION
>  The  PGM  format  is a lowest common denominator grayscale file format.
>  It is designed to be extremely easy to learn and  write  programs  for.
>  (It's  so  simple  that  most  people  will  simply reverse engineer it
>  because it's easier than reading this specification).
>
>  A PGM image represents a  grayscale  graphic  image.   There  are  many
>  psueudo-PGM  formats  in  use  where  everything is as specified herein
>  except for the meaning of individual pixel values.  For most  purposes,
>  a  PGM image can just be thought of an array of arbitrary integers, and
>  all the programs in the world that think they're processing a grayscale
>  image can easily be tricked into processing something else.
>
>  One  official  variant of PGM is the transparency mask.  A transparency
>  mask in Netpbm is represented by a PGM image, except that in  place  of
>  pixel intensities, there are opaqueness values.  See below.
>
>
>  The format definition is as follows.
>
>  A  PGM file consists of a sequence of one or more PGM images. There are
>  no data, delimiters, or padding before, after, or between images.
>
>  Each PGM image consists of the following:
>
>  - A "magic number" for identifying the file type.  A pgm image's  magic
>    number is the two characters "P5".
>
>  - Whitespace (blanks, TABs, CRs, LFs).
>
>  - A width, formatted as ASCII characters in decimal.
>
>  - Whitespace.
>
>  - A height, again in ASCII decimal.
>
>  - Whitespace.
>
>  - The  maximum  gray  value  (Maxval), again in ASCII decimal.  Must be
>    less than 65536.
>
>  - Newline or other single whitespace character.
>
>  - A raster of Width * Height gray values, proceeding through the  image
>    in  normal English reading order.  Each gray value is a number from 0
>    through Maxval, with 0 being black and Maxval being white.  Each gray
>    value  is  represented in pure binary by either 1 or 2 bytes.  If the
>    Maxval is less than 256, it is 1 byte.  Otherwise,  it  is  2  bytes.
>    The most significant byte is first.
>
>  - Each  gray  value  is  a  number proportional to the intensity of the
>    pixel, adjusted by the CIE Rec. 709 gamma transfer  function.   (That
>    transfer  function  specifies  a gamma number of 2.2 and has a linear
>    section for small intensities).  A value of zero is therefore  black.
>    A value of Maxval represents CIE D65 white and the most intense value
>    in the image and any other image to which the  image  might  be  com?
>    pared.
>
>  - Note  that  a  common variation on the PGM format is to have the gray
>    value be "linear," i.e. as specified above except without  the  gamma
>    adjustment.   pnmgamma takes such a PGM variant as input and produces
>    a true PGM as output.
>
>  - In the transparency mask  variation  on  PGM,  the  value  represents
>    opaqueness.   It  is  proportional  to the fraction of intensity of a
>    pixel that would show in place of an underlying pixel, with the  same
>    gamma  transfer  function  mentioned above applied.  So what normally
>    means white represents total opaqueness and what normally means black
>    represents  total  transparency.   In  between, you would compute the
>    intensity of a composite pixel of an  "under"  and  "over"  pixel  as
>    under * (1-(alpha/alpha_maxval)) + over * (alpha/alpha_maxval).<
>
>  - Characters  from  a  "#"  to  the next end-of-line, before the maxval
>    line, are comments and are ignored.
>
>  Note that you can use pnmdepth To convert between a the format  with  1
>  byte per gray value and the one with 2 bytes per gray value.
>
>  There  is  actually  another  version  of the PGM format that is fairly
>  rare: "plain" PGM format.  The format above, which generally considered
>
>  the  normal one, is known as the "raw" PGM format.  See pbm(5) for some
>  commentary on how plain and raw formats relate to one another.
>
>  The difference in the plain format is:
>
>  - There is exactly one image in a file.
>
>  - The magic number is P2 instead of P5.
>
>  - Each pixel in the raster is represented as an  ASCII  decimal  number
>    (of arbitrary size).
>
>  - Each  pixel in the raster has white space before and after it.  There
>    must be at least one character of white space between any two pixels,
>    but there is no maximum.
>
>  - No line should be longer than 70 characters.
>
>  Here is an example of a small graymap in this format:
>  P2
>  # feep.pgm
>  24 7
>  15
>  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>  0  3  3  3  3  0  0  7  7  7  7  0  0 11 11 11 11  0  0 15 15 15 15  0
>  0  3  0  0  0  0  0  7  0  0  0  0  0 11  0  0  0  0  0 15  0  0 15  0
>  0  3  3  3  0  0  0  7  7  7  0  0  0 11 11 11  0  0  0 15 15 15 15  0
>  0  3  0  0  0  0  0  7  0  0  0  0  0 11  0  0  0  0  0 15  0  0  0  0
>  0  3  0  0  0  0  0  7  7  7  7  0  0 11 11 11 11  0  0 15  0  0  0  0
>  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>
>  Programs  that  read  this  format  should  be  as lenient as possible,
>  accepting anything that looks remotely like a graymap.
>
>
> COMPATIBILITY
>  Before April 2000, a raw format  PGM  file  could  not  have  a  maxval
>  greater than 255.  Hence, it could not have more than one byte per sam?
>  ple.  Old programs may depend on this.
>
>  Before July 2000, there could be at most one image in a PGM file.  As a
>  result,  most  tools  to  process PGM files ignore (and don't read) any
>  data after the first image.
>
> AUTHOR
>        Copyright (C) 1989, 1991 by Jef Poskanzer.
>

[Jan Eglinger-2]

Dear Harald,

in order to read this file format, you should rename the file to *.pgm
and then open it via File>Open... or by Drag&Drop.

File>Import>Text Image... works on pure text files without a format header.

Hth,
Jan


On 09.12.2010 8:24 PM, Dr. Harald von der Osten wrote:

> Hi Adrian,
>
>
> thnaks a lot for your help.
>
> Unfortunately, TextReader says:
>
> "Line 2 is not the same lenght as the first line"... and Fiji is killed.
>
> The beginning of the data file is:
>
>
> P2
> 8001 960
> 255
> #
> 148
> 150
> 155
> 155
> 155
> 160
> 165
> 165
> 165
> 163
> 165
> 165
> :
>
> and so on. Hmmm...
>