Back to the main page.

Bug 1610 - autodetected layout for ctf151 has 1e-10 width and height

Reported 2012-07-12 15:46:00 +0200
Modified 2013-01-17 10:41:19 +0100
Product: FieldTrip
Component: plotting
Version: unspecified
Hardware: PC
Operating System: Windows
Importance: P3 normal
Assigned to: Roemer van der Meij
Depends on:
See also:

Roemer van der Meij - 2012-07-12 15:46:26 +0200

The layout automatically created based on data.grad for the ctf151 system (and possibly others) has an almost non-existent width and height. The pos fields are also different (not priority to check atm). This can be replicated by using e.g. freq-output from the time-freq tutorial and doing an empty cal (ft_multiplotTFR([],data), or by changing test_ft_multiplotTFR to use the ctf151 test-data.

Roemer van der Meij - 2012-07-12 15:47:43 +0200

*** Bug 1456 has been marked as a duplicate of this bug. ***

Johanna - 2012-07-12 15:52:40 +0200

is this also related to bug 1568?

Roemer van der Meij - 2012-07-12 16:06:38 +0200

*** Bug 1492 has been marked as a duplicate of this bug. ***

Roemer van der Meij - 2012-07-19 15:47:09 +0200

Bug originated from ft_prepare_layout, were width and height are determined by the minimum distance between projected channel locations, based on grad/elec. Bug fixed, improved (hopefully in all cases) the determining of distance between channel pairs. Previously, the width of a channel was 0.8 of the minimum non-zero distance between all projected channel locations. Now, the width of a channel is 0.8 of the median of the first/closest quartile of the non-zero distance to the closest neighbor of each channel. I'm CC'ing you JM, as you made the last known change to the automatic determining of channel width and height (sens2lay subfunction of ft_prepare_layout), correcting it for machine precision (which though, in the case of the ctf151 system, was not conservative enough). Also CC'ing you, as my changes here will probably affect many users not using their own layout (and it's good to spread the awareness in this 'default' change ;)).

Roemer van der Meij - 2012-07-19 15:57:27 +0200

As an additional comment, the reason for my more complicated definition was that, in the case of the ctf151 system, the minimal non-zero distance (even after using a more liberal detection of '0') was still very small. A few channels, which were extremely close to each other, thus caused all other channels to become unreadable tiny squares (but visible). After the changes I made, much more of the available screen space was used, at the cost of a few channels maybe overlapping. Although, in the case of the ctf151 system, I didn't see any channels overlapping afterwards.

Roemer van der Meij - 2013-01-17 10:41:19 +0100

bug closing time