[GRASS-dev] PCA (i.pca) in G7: filtering and rescaling

GRASS GIS GRASS GIS developer
1

Hi list and Markus.

The i.pca module in G7 offers a "forward/filtering/backward" PCA. I have an
issue first with filtering and second with rescaling.

1) I can't see any differences in the derived Principal Components between
percent=70 and percent=99 for 4 bands which the PCs (both centered and scaled)
are:

PC1 2.78 ( 0.4947, 0.5922, 0.5743, 0.2735) [69.53%]
PC2 1.08 ( 0.5196, 0.0517,-0.0974,-0.8473) [26.99%]
PC3 0.11 ( 0.4210, 0.2486,-0.7926, 0.3644) [ 2.86%]
PC4 0.03 (-0.5551, 0.7647,-0.1805,-0.2729) [ 0.63%]

What is filtering doing actually? Shouldn't percent=70 just filter out the
rest, somehow?

2) a centered but non-scaled attempt, with rescaling (to [0,255] desired]
gives me floating point PCs as an output:

r.info -rh PC.1
min=167.116641509957
max=1063.871704546
Data Source:
   
Data Description:
   generated by i.pca
Comments:
   Eigen values, (vectors), and [percent importance]:
   PC1 142403.37 ( 0.0058,-0.0899,-0.0817,-0.9926) [93.76%]
   PC2 8979.58 ( 0.4285, 0.7402, 0.5071,-0.1062) [ 5.91%]
   PC3 416.51 (-0.3800,-0.3668, 0.8483,-0.0388) [ 0.27%]
   PC4 88.39 (-0.8197, 0.5563,-0.1287,-0.0446) [ 0.06%]
   
   i.pca -f input="Blue_DNs,Green_DNs,Red_DNs,NIR_DNs" output_prefix="P\
   C" rescale=0,255 percent=99

This isn't expected, right?

Thanks for this module as well -- it solved big issues (i.e. with hazed
images), Nikos

2

On 04/12/13 14:53, Nikos Alexandris wrote:

Hi list and Markus.

The i.pca module in G7 offers a "forward/filtering/backward" PCA. I have an
issue first with filtering and second with rescaling.

1) I can't see any differences in the derived Principal Components between
percent=70 and percent=99 for 4 bands which the PCs (both centered and scaled)
are:

PC1 2.78 ( 0.4947, 0.5922, 0.5743, 0.2735) [69.53%]
PC2 1.08 ( 0.5196, 0.0517,-0.0974,-0.8473) [26.99%]
PC3 0.11 ( 0.4210, 0.2486,-0.7926, 0.3644) [ 2.86%]
PC4 0.03 (-0.5551, 0.7647,-0.1805,-0.2729) [ 0.63%]

What is filtering doing actually? Shouldn't percent=70 just filter out the
rest, somehow?

AFAIU, filtering happens after pca: pca is run on all bands, then according to the filter percentage you chose inverse pca is run using the principal components necessary to reach the filter percentage of variance. In your example, 70% would use PC1 and 2 (unless variances is rounded up) and 99% would use PC1,2,3. Any difference you see is in the resulting images, not in the PCA.

Example with the Landsat bands in the NC data set (group landsat = all mx bands):

i.pca -f input=landsat output_prefix=filt percent=90

Computing covariance matrix...
Using 2 of 6 principal components for filtering
^^^^

=> For the inverse PCA, only 2 components are used since PC1+PC2>90%

However the info given is about the entire PCA:

Calculating principal components...
Eigen values, (vectors), and [percent importance]:
PC1 4334.35 ( 0.2824, 0.3342, 0.5092,-0.0087, 0.5264, 0.5217) [83.04%]
PC2 588.31 ( 0.2541, 0.1885, 0.2923,-0.7428,-0.5110,-0.0403) [11.27%]
PC3 239.22 ( 0.3801, 0.3819, 0.2681, 0.6238,-0.4000,-0.2980) [ 4.58%]
PC4 32.85 ( 0.1752,-0.0191,-0.4053, 0.1593,-0.4435, 0.7632) [ 0.63%]
PC5 20.73 (-0.6170,-0.2514, 0.6059, 0.1734,-0.3235, 0.2330) [ 0.40%]
PC6 4.08 (-0.5475, 0.8021,-0.2282,-0.0607,-0.0208, 0.0252) [ 0.08%]

Moritz

3

Nikos Alexandris wrote:

> The i.pca module in G7 offers a "forward/filtering/backward" PCA. I have
> an issue first with filtering and second with rescaling.

> 1) I can't see any differences in the derived Principal Components

okay, to clarify: I mean the resulting images which, initially are Principal
Components (synthetic images) and, after applying filtering & backward PCA,
the resulting images approach the original data -- still they are modified.

> between percent=70 and percent=99 for 4 bands which the PCs (both centered
> and scaled) are:
>
> PC1 2.78 ( 0.4947, 0.5922, 0.5743, 0.2735) [69.53%]
> PC2 1.08 ( 0.5196, 0.0517,-0.0974,-0.8473) [26.99%]
> PC3 0.11 ( 0.4210, 0.2486,-0.7926, 0.3644) [ 2.86%]
> PC4 0.03 (-0.5551, 0.7647,-0.1805,-0.2729) [ 0.63%]

> What is filtering doing actually? Shouldn't percent=70 just filter out
> the rest, somehow?

Moritz Lennert wrote:

AFAIU, filtering happens after pca: pca is run on all bands, then
according to the filter percentage you chose inverse pca is run using
the principal components necessary to reach the filter percentage of
variance. In your example, 70% would use PC1 and 2 (unless variances is
rounded up) and 99% would use PC1,2,3. Any difference you see is in the
resulting images, not in the PCA.

Sure -- I didn't (mean to) state otherwise. But, there are no differences in
the resulting images (after PCA > Filtering > Backward PCA). Makes sense?
Apologies for not being very clear.

Thanks from the prompt reaction, Nikos

4

On Wednesday 04 of December 2013 16:22:51 Nikos Alexandris wrote:

Nikos Alexandris wrote:
> > The i.pca module in G7 offers a "forward/filtering/backward" PCA. I
> > have
> > an issue first with filtering and second with rescaling.
> >
> > 1) I can't see any differences in the derived Principal Components

okay, to clarify: I mean the resulting images which, initially are Principal
Components (synthetic images) and, after applying filtering & backward PCA,
the resulting images approach the original data -- still they are modified.

Example (using i.pca in G7, though r.info below executed from G64):

<http://nikosalexandris.net/owncloud/public.php?service=files&t=e87b1223bf6402786ef7478690099602&gt;

and details for

P=90) r.info -rh PC90N.1

min=171.596979136065
max=1107.42672094831
Data Source:
   
Data Description:
   generated by i.pca
Comments:
   Eigen values, (vectors), and [percent importance]:
   PC1 2.78 ( 0.4947, 0.5922, 0.5743, 0.2735) [69.53%]
   PC2 1.08 ( 0.5196, 0.0517,-0.0974,-0.8473) [26.99%]
   PC3 0.11 ( 0.4210, 0.2486,-0.7926, 0.3644) [ 2.86%]
   PC4 0.03 (-0.5551, 0.7647,-0.1805,-0.2729) [ 0.63%]
   
   i.pca -n -f input="Blue_DNs,Green_DNs,Red_DNs,NIR_DNs" output_prefix\
   ="PC90N" rescale=0,0 percent=90

P=70) r.info -rh PC70N.1

min=171.596979136065
max=1107.42672094831
Data Source:
   
Data Description:
   generated by i.pca
Comments:
   Eigen values, (vectors), and [percent importance]:
   PC1 2.78 ( 0.4947, 0.5922, 0.5743, 0.2735) [69.53%]
   PC2 1.08 ( 0.5196, 0.0517,-0.0974,-0.8473) [26.99%]
   PC3 0.11 ( 0.4210, 0.2486,-0.7926, 0.3644) [ 2.86%]
   PC4 0.03 (-0.5551, 0.7647,-0.1805,-0.2729) [ 0.63%]
   
   i.pca -n -f input="Blue_DNs,Green_DNs,Red_DNs,NIR_DNs" output_prefix\
   ="PC70N" rescale=0,0 percent=70

Nikos

5

On 04/12/13 15:22, Nikos Alexandris wrote:

Nikos Alexandris wrote:

The i.pca module in G7 offers a "forward/filtering/backward" PCA. I have
an issue first with filtering and second with rescaling.

1) I can't see any differences in the derived Principal Components

okay, to clarify: I mean the resulting images which, initially are Principal
Components (synthetic images) and, after applying filtering & backward PCA,
the resulting images approach the original data -- still they are modified.

between percent=70 and percent=99 for 4 bands which the PCs (both centered
and scaled) are:

PC1 2.78 ( 0.4947, 0.5922, 0.5743, 0.2735) [69.53%]
PC2 1.08 ( 0.5196, 0.0517,-0.0974,-0.8473) [26.99%]
PC3 0.11 ( 0.4210, 0.2486,-0.7926, 0.3644) [ 2.86%]
PC4 0.03 (-0.5551, 0.7647,-0.1805,-0.2729) [ 0.63%]

What is filtering doing actually? Shouldn't percent=70 just filter out
the rest, somehow?

Moritz Lennert wrote:

AFAIU, filtering happens after pca: pca is run on all bands, then
according to the filter percentage you chose inverse pca is run using
the principal components necessary to reach the filter percentage of
variance. In your example, 70% would use PC1 and 2 (unless variances is
rounded up) and 99% would use PC1,2,3. Any difference you see is in the
resulting images, not in the PCA.

Sure -- I didn't (mean to) state otherwise. But, there are no differences in
the resulting images (after PCA > Filtering > Backward PCA). Makes sense?
Apologies for not being very clear.

Here I see a difference:

> r.info -r lsat7_2002_10
min=42
max=255

  > r.info -r filt.1
min=49.4097659695008
max=200.074494678242

> r.info -r lsat7_2002_20
min=28
max=255

r.info -r filt.2
min=29.93376973921
max=204.43559249011

etc.

Moritz

6

Nikos Alexandris wrote:

> > > 1) I can't see any differences in the derived Principal Components

..

> okay, to clarify: I mean the resulting images which, initially are
> Principal Components (synthetic images) and, after applying filtering &
> backward PCA, the resulting images approach the original data -- still
> they are modified.

Example (using i.pca in G7, though r.info below executed from G64):

..
PC1 2.78 ( 0.4947, 0.5922, 0.5743, 0.2735) [69.53%]
..

Ignore please. I picked the wrong example. It works with percentage = 99 for
example. Because 70 + 20 = 90 was still inside the 1st component (=96.52).

Sorry for the noise. Then I need to see why the rescaling is not getting at
[0,255].

Nikos

7

On 04/12/13 15:34, Nikos Alexandris wrote:

On Wednesday 04 of December 2013 16:22:51 Nikos Alexandris wrote:

Nikos Alexandris wrote:

The i.pca module in G7 offers a "forward/filtering/backward" PCA. I
have
an issue first with filtering and second with rescaling.

1) I can't see any differences in the derived Principal Components

okay, to clarify: I mean the resulting images which, initially are Principal
Components (synthetic images) and, after applying filtering & backward PCA,
the resulting images approach the original data -- still they are modified.

Example (using i.pca in G7, though r.info below executed from G64):

<http://nikosalexandris.net/owncloud/public.php?service=files&t=e87b1223bf6402786ef7478690099602&gt;

and details for

P=90) r.info -rh PC90N.1

min=171.596979136065
max=1107.42672094831
Data Source:

Data Description:
    generated by i.pca
Comments:
    Eigen values, (vectors), and [percent importance]:
    PC1 2.78 ( 0.4947, 0.5922, 0.5743, 0.2735) [69.53%]
    PC2 1.08 ( 0.5196, 0.0517,-0.0974,-0.8473) [26.99%]
    PC3 0.11 ( 0.4210, 0.2486,-0.7926, 0.3644) [ 2.86%]
    PC4 0.03 (-0.5551, 0.7647,-0.1805,-0.2729) [ 0.63%]

    i.pca -n -f input="Blue_DNs,Green_DNs,Red_DNs,NIR_DNs" output_prefix\
    ="PC90N" rescale=0,0 percent=90

P=70) r.info -rh PC70N.1

min=171.596979136065
max=1107.42672094831
Data Source:

Data Description:
    generated by i.pca
Comments:
    Eigen values, (vectors), and [percent importance]:
    PC1 2.78 ( 0.4947, 0.5922, 0.5743, 0.2735) [69.53%]
    PC2 1.08 ( 0.5196, 0.0517,-0.0974,-0.8473) [26.99%]
    PC3 0.11 ( 0.4210, 0.2486,-0.7926, 0.3644) [ 2.86%]
    PC4 0.03 (-0.5551, 0.7647,-0.1805,-0.2729) [ 0.63%]

    i.pca -n -f input="Blue_DNs,Green_DNs,Red_DNs,NIR_DNs" output_prefix\
    ="PC70N" rescale=0,0 percent=70

Which components are used ? IIUC, in both cases it will be PCs 1 and 2 as

PC1 < 70% and PC1 + PC2 > 90%

Moritz

8

Moritz Lennert wrote:

Which components are used ? IIUC, in both cases it will be PCs 1 and 2 as
PC1 < 70% and PC1 + PC2 > 90%

Absolutely true (see previous post, I didn't cc you :(). Yet, consider the
following cases (just to justify why I started this thread):

1) Centered and Scaled with:

PC1 2.78 ( 0.4947, 0.5922, 0.5743, 0.2735) [69.53%]
PC2 1.08 ( 0.5196, 0.0517,-0.0974,-0.8473) [26.99%]
PC3 0.11 ( 0.4210, 0.2486,-0.7926, 0.3644) [ 2.86%]
PC4 0.03 (-0.5551, 0.7647,-0.1805,-0.2729) [ 0.63%]

here: 69.53 + 26.99 = 96.52

1.1) Get only the 1st

i.pca in=Blue_DNs,Green_DNs,Red_DNs,NIR_DNs out=PC70N -f -n percent=70 --o

r.info -r PC70N.1

min=171.596979136065
max=1107.42672094831

r.info -r PC70N.2

min=180.569566126261
max=1871.35099616711

1.2) Just above the 1st+2nd, setting p=96.53 > 96.52

i.pca in=Blue_DNs,Green_DNs,Red_DNs,NIR_DNs out=PC9653N -f -n percent=96.53 --
o

r.info -r PC9653N.1

min=171.596979136065
max=1107.42672094831

r.info -r PC9653N.2

min=180.569566126261
max=1871.35099616711

Why same results here?

1.3) Clearly above 1st + 2nd, setting p=97 > 96.52

i.pca in=Blue_DNs,Green_DNs,Red_DNs,NIR_DNs out=PC97N -f -n percent=97 --o

r.info -r PC97N.1

min=170.679128221915
max=1090.28043417784

r.info -r PC97N.2

min=172.894850271274
max=1849.10208527211

The "percent=96.53" gets rounded I guess or so... ? I think in one of my tests
I got confused due to this.

and 2) Centered only

PC1 142403.37 ( 0.0058,-0.0899,-0.0817,-0.9926) [93.76%]
PC2 8979.58 ( 0.4285, 0.7402, 0.5071,-0.1062) [ 5.91%]
PC3 416.51 (-0.3800,-0.3668, 0.8483,-0.0388) [ 0.27%]
PC4 88.39 (-0.8197, 0.5563,-0.1287,-0.0446) [ 0.06%]

here: 93.76 + 5.91 = 99.67

2.1) 1st

r.info -r PC94N.1

min=171.596979136065
max=1107.42672094831

r.info -r PC94N.2

min=180.569566126261
max=1871.35099616711

r.info -r PC9968.1

min=167.116641509957
max=1063.871704546

r.info -r PC9968.2

min=180.695102005218
max=1831.85035336866

Here, immediate effect when percent=99.68. I guess it gets rounded to 99.7 ?

Nikos

9

On 04/12/13 16:18, Nikos Alexandris wrote:

Here, immediate effect when percent=99.68. I guess it gets rounded to 99.7 ?

Actually, the man page says "percent=integer". The input is treated with atoi(). I don't know if that rounds or floors..

Moritz

10

Nikos Alexandris:

> Here, immediate effect when percent=99.68. I guess it gets rounded to
> 99.7 ?

Moritz Lennert:

Actually, the man page says "percent=integer". The input is treated with
atoi(). I don't know if that rounds or floors..

Heck, overlooked that :-(. In my very humble and ever-wannabe-scientist
opinnion, though, we need those extra digits to make it easy rejecting last
Principal Component(s) prior to the backward PCA. Might be one, two or
numerous (?) depending on the dimensions.

Nikos

11

On 04/12/13 23:46, Nikos Alexandris wrote:

Nikos Alexandris:

Here, immediate effect when percent=99.68. I guess it gets rounded to
99.7 ?

Moritz Lennert:

Actually, the man page says "percent=integer". The input is treated with
atoi(). I don't know if that rounds or floors..

Heck, overlooked that :-(. In my very humble and ever-wannabe-scientist
opinnion, though, we need those extra digits to make it easy rejecting last
Principal Component(s) prior to the backward PCA. Might be one, two or
numerous (?) depending on the dimensions.

Try the attached diff to imagery/i.pca/main.c.

Moritz

(attachments)

i_pca_filtering_doubles.diff (1.42 KB)

12

On Wed, Dec 4, 2013 at 3:42 PM, Nikos Alexandris
<nik@nikosalexandris.net> wrote:

Nikos Alexandris wrote:

> > > 1) I can't see any differences in the derived Principal Components

..

> okay, to clarify: I mean the resulting images which, initially are
> Principal Components (synthetic images) and, after applying filtering &
> backward PCA, the resulting images approach the original data -- still
> they are modified.

Example (using i.pca in G7, though r.info below executed from G64):

..
PC1 2.78 ( 0.4947, 0.5922, 0.5743, 0.2735) [69.53%]
..

Ignore please. I picked the wrong example. It works with percentage = 99 for
example. Because 70 + 20 = 90 was still inside the 1st component (=96.52).

Sorry for the noise. Then I need to see why the rescaling is not getting at
[0,255].

Rescaling applies to PC scores. With filtering, the output is not PC
scores, but a filtered version of the input. If you want the filtered
output to be rescaled, please use r.recode afterwards.

13

On 04/12/13 22:02, Moritz Lennert wrote:

On 04/12/13 16:18, Nikos Alexandris wrote:

Here, immediate effect when percent=99.68. I guess it gets rounded to
99.7 ?

Actually, the man page says "percent=integer". The input is treated with
atoi(). I don't know if that rounds or floors..

For the record: if floors as it stops reading at the first non-numerical character.

Moritz

14

On Wed, Dec 4, 2013 at 11:46 PM, Nikos Alexandris
<nik@nikosalexandris.net> wrote:

Nikos Alexandris:

> Here, immediate effect when percent=99.68. I guess it gets rounded to
> 99.7 ?

Moritz Lennert:

Actually, the man page says "percent=integer". The input is treated with
atoi(). I don't know if that rounds or floors..

I think it truncates = floor for positive numbers.

Heck, overlooked that :-(. In my very humble and ever-wannabe-scientist
opinnion, though, we need those extra digits to make it easy rejecting last
Principal Component(s) prior to the backward PCA. Might be one, two or
numerous (?) depending on the dimensions.

I think it rather depends in the amount of information encoded in each PC.

Alternatively, PC selection could also be based on the Eigenvalue,
typically all PCs with an Eigenvalue >= 1 (centered and scaled input)
would be used.

Markus M

15

Nikos A:

> Sorry for the noise. Then I need to see why the rescaling is not getting
> at [0,255].

Markus M:

Rescaling applies to PC scores. With filtering, the output is not PC
scores, but a filtered version of the input. If you want the filtered
output to be rescaled, please use r.recode afterwards.

Makes sense, N

16

Nikos Alexandris:

> ...we need those extra digits to make it easy rejecting last Principal
> Component(s) prior to the backward PCA. Might be one, two or numerous (?)
> depending on the dimensions.

Markus M:

I think it rather depends in the amount of information encoded in each PC.

It does. PCA works on global stats so one has to go through, then study
visuals and numbers, then decide what to keep or how to treat further.

In my very simple example, I want to see whether I want to reject the last or
the two last ones. If the filtering option lets me do that, I am happy :-).
To exemplify, currently I can't reject two last components whicih account for
0.06 and 0.21 of the original data variance. I tested yesterday and the filter
does not differentiate those subtle details which might be of importance (for
a subsequent classification of High-Res images).

Will test Moritz' diff. Thank you for that one.

Alternatively, PC selection could also be based on the Eigenvalue,
typically all PCs with an Eigenvalue >= 1 (centered and scaled input)
would be used.

It depends. Typically might be simply compressing data or reducing salt 'n'
pepper. However, in change detection studies, where changes are likely to
appear in higher order components, it's not uncommon to have several
components which account for <= 1 of the original variance and still are the
ones you really need.

In fact I would like to have fine-control over centering as well . My
"feelings" about scaling are less enthousiastic. Especially for change
detection studies, subtle (though important) changes might disappear after
scaling between dimensions which already measure the same thing (same units,
no huge range of values differences) from a different "perspective". It always
depends what the aim is of course.

Nikos

17

Moritz Lennert wrote:
..

Try the attached diff to imagery/i.pca/main.c.

Great! So, applied the diff. Here some numbers:

PC1 238310.68 ( 0.1606, 0.2231, 0.1228, 0.9536) [96.10%]
PC2 9364.65 ( 0.4319, 0.5989, 0.6082,-0.2912) [ 3.78%]
PC3 217.78 ( 0.7028, 0.1609,-0.6897,-0.0672) [ 0.09%]
PC4 80.33 ( 0.5420,-0.7521, 0.3732, 0.0366) [ 0.03%]

Thus, we have:

96.10 + 3.78 + 0.09 = 99.88 + 0.09 = 99.97

Then, pca with "-f":

i.pca in=Blue_DNs,Green_DNs,Red_DNs,NIR1_DNs out=TEST_PC --o -f percent=96.10
ERROR: Not enough principal components left for filtering

and

i.pca in=Blue_DNs,Green_DNs,Red_DNs,NIR1_DNs out=TEST_PC --o -f percent=96.11

gives:

r.info -r TEST_PC.1
min=19.4012346427396
max=1570.71398669652

Good sign, means it works :-). And it does not truncate (otherwise,
trunc(96.11) = 96, so "normally" it should fail to filter again)! Then, with
"percent=99.87" still the same:

r.info -r TEST_PC.1
min=19.4012346427396
max=1570.71398669652

while with "percent=99.88" it works:

r.info -r TEST_PC.1
min=8.08831247843905
max=1443.35532373978

Finally, with "percent=99.97" OR below OR above, always gives the same

r.info -r TEST_PC.1
min=8.08831247843905
max=1443.35532373978

So, the questions are:

1) why does it make the switch with 99.11 and not with 99.10, while it does
make the switch already with 99.88 instead of requiring 99.89?

2) Why is there no filtering taking place for "percent >= 99.97" ?

In a way, though, this is already getting better :slight_smile:

Nikos

18

On Thu, Dec 5, 2013 at 1:15 PM, Nikos Alexandris
<nik@nikosalexandris.net> wrote:

Nikos Alexandris:

> ...we need those extra digits to make it easy rejecting last Principal
> Component(s) prior to the backward PCA. Might be one, two or numerous (?)
> depending on the dimensions.

Markus M:

I think it rather depends in the amount of information encoded in each PC.

It does. PCA works on global stats so one has to go through, then study
visuals and numbers, then decide what to keep or how to treat further.

In my very simple example, I want to see whether I want to reject the last or
the two last ones. If the filtering option lets me do that, I am happy :-).
To exemplify, currently I can't reject two last components whicih account for
0.06 and 0.21 of the original data variance. I tested yesterday and the filter
does not differentiate those subtle details which might be of importance (for
a subsequent classification of High-Res images).

I don't think filtering makes sense in this case. If important
information is encoded in components explaining only a small part of
the variance, you don't want to filter them out. The idea of the
filtering option is to discard components that do not contribute much
in terms of observed variance.

It sounds like you rather want to identify those PCs that encode
information that is important in your case. In this case filtering
does not make sense, instead the identified components could be used
for subsequent processing.

Alternatively, PC selection could also be based on the Eigenvalue,
typically all PCs with an Eigenvalue >= 1 (centered and scaled input)
would be used.

It depends. Typically might be simply compressing data or reducing salt 'n'
pepper. However, in change detection studies, where changes are likely to
appear in higher order components, it's not uncommon to have several
components which account for <= 1 of the original variance and still are the
ones you really need.

Don't filter in these cases, use the components relevant for the study ?

You can also filter manually using the factor loadings of the
components of interest.

Markus M

19

On 07/12/13 17:46, Nikos Alexandris wrote:

Moritz Lennert wrote:
..

Try the attached diff to imagery/i.pca/main.c.

Great! So, applied the diff. Here some numbers:

PC1 238310.68 ( 0.1606, 0.2231, 0.1228, 0.9536) [96.10%]
PC2 9364.65 ( 0.4319, 0.5989, 0.6082,-0.2912) [ 3.78%]
PC3 217.78 ( 0.7028, 0.1609,-0.6897,-0.0672) [ 0.09%]
PC4 80.33 ( 0.5420,-0.7521, 0.3732, 0.0366) [ 0.03%]

Thus, we have:

96.10 + 3.78 + 0.09 = 99.88 + 0.09 = 99.97

That's 96.10 + 3.78 = 99.88 + 0.09 = 99.97 :wink:

Then, pca with "-f":

i.pca in=Blue_DNs,Green_DNs,Red_DNs,NIR1_DNs out=TEST_PC --o -f percent=96.10
ERROR: Not enough principal components left for filtering

and

i.pca in=Blue_DNs,Green_DNs,Red_DNs,NIR1_DNs out=TEST_PC --o -f percent=96.11

gives:

r.info -r TEST_PC.1
min=19.4012346427396
max=1570.71398669652

Good sign, means it works :-). And it does not truncate (otherwise,
trunc(96.11) = 96, so "normally" it should fail to filter again)! Then, with
"percent=99.87" still the same:

r.info -r TEST_PC.1
min=19.4012346427396
max=1570.71398669652

while with "percent=99.88" it works:

r.info -r TEST_PC.1
min=8.08831247843905
max=1443.35532373978

Finally, with "percent=99.97" OR below OR above, always gives the same

r.info -r TEST_PC.1
min=8.08831247843905
max=1443.35532373978

So, the questions are:

1) why does it make the switch with 99.11 and not with 99.10, while it does
make the switch already with 99.88 instead of requiring 99.89?

Probably rounding. For printing the numbers are rounded to two decimals.

2) Why is there no filtering taking place for "percent >= 99.97" ?

Because you need all PCs to get above 99.97% and so the result is no filtering...

Moritz

20

On Monday 09 of December 2013 14:29:21 you wrote:

> Great! So, applied the diff. Here some numbers:
>
> PC1 238310.68 ( 0.1606, 0.2231, 0.1228, 0.9536) [96.10%]
> PC2 9364.65 ( 0.4319, 0.5989, 0.6082,-0.2912) [ 3.78%]
> PC3 217.78 ( 0.7028, 0.1609,-0.6897,-0.0672) [ 0.09%]
> PC4 80.33 ( 0.5420,-0.7521, 0.3732, 0.0366) [ 0.03%]
>
> Thus, we have:
>
> 96.10 + 3.78 + 0.09 = 99.88 + 0.09 = 99.97

That's 96.10 + 3.78 = 99.88 + 0.09 = 99.97

Heheh... :smiley:

That was written like (striking away the numbers):

   / /
96/.10 + 3./78 + 0.09 = 99.88 + 0.09 = 99.97
/ /
                          ^
                          |
          o ---------------
                          +
o ------------------------

Nikos