Back to the main page.
Bug 680 - bad axes plotting in ft_multiplotER
| Status | CLOSED FIXED |
| Reported | 2011-05-20 18:12:00 +0200 |
| Modified | 2011-06-29 09:50:25 +0200 |
| Product: | FieldTrip |
| Component: | plotting |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Mac OS |
| Importance: | P1 normal |
| Assigned to: | Jörn M. Horschig |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Eliezer Kanal - 2011-05-20 18:12:45 +0200
Created attachment 55 ft_multiplotER figure showing bad axes See attached file for visual. The y-axes are being plotted too far to the right when doing a frequency plot using ft_multiplotER. I generated this using the following: cfg = []; cfg.method='mtmfft'; cfg.output='pow'; cfg.calcdof='yes'; cfg.taper='hanning'; cfg.foilim=[5 40]; data_preprocessed_freq = ft_freqanalysis(cfg,data_preprocessed); cfg=[]; cfg.layout='neuromag306mag.lay'; cfg.showlabels='yes'; cfg.ylim=[0 4e-27]; ft_multiplotER(cfg,data_preprocessed_freq); Note that I was able to fix this by changing the following lines in ft_multiplotRT, subfunction plotWnd: Line 692: -- xs = xpos+width*([0 0]-xlim(1))/(xlim(2)-xlim(1)); ++ xs = [xpos xpos]; This effectively removes the whole normalizing by xlim bit. I was not able to determine out the purpose of the normalizatoin to figure out why this works, so I hope you guys know what it does :) Let me know if you want me to upload the datasets (data_preprocessed, data_preprocessed_freq) as well.
Jörn M. Horschig - 2011-05-30 16:59:52 +0200
Hi Eli, Thanks for reporting! I fixed the function according to your proposal. I could not determine why to move either of the axes either. I fixed this as well for the y-axis (which is only off like 0.01 units). You should find this fix in the new FT version from tomorrow on. If you encounter another problem with this function due to this fix, let me know and I'll deal with it asap ;) Best, Jörn
Jörn M. Horschig - 2011-05-31 09:37:25 +0200
short update: I just realized that there was also a division-by-zero bug in ft_plot_vector in case one of the axes was at [0 0]. I fixed this as well
Eliezer Kanal - 2011-06-02 20:44:07 +0200
I'm not sure if this was intended, but you removed some existing features in this bugfix, with respect to time plotting. Previously, the [0 0] point of the axes was located at the appropriate location relative to thex and y axes. Now, the axes are located along the edge of the graph all the time. Maybe there should be a `switch` block to determine whether it's temporal or frequency code? See new attachments for detail.
Eliezer Kanal - 2011-06-02 20:44:50 +0200
Created attachment 63 ft_multiplotER output using time data after the fix
Eliezer Kanal - 2011-06-02 20:45:03 +0200
Created attachment 64 ft_multiplotER output using time data before the fix
Eliezer Kanal - 2011-06-02 21:13:27 +0200
Reopening as per comment 3, forgot to mark this last time.
Jörn M. Horschig - 2011-06-05 10:13:22 +0200
hm, strange, Since I changed what you suggested, the problem should be caused by the missing normalization. I'll look into this one again when I got some time (~Wednesday)
Jörn M. Horschig - 2011-06-05 10:30:40 +0200
Okay, after some short thinking, I'll discuss this on Wednesday with Robert during our weekly meeting. Your initial proposed fixed caused the axis to look nice, but lead to the problem that the x-axis it not located at time- or frequency-point 0. If you plot a frequency spectrum starting at 5Hz, the question arises whether this function should mark frequency 0, or the beginning of the spectrum you put in. I guess it should be first one, which would make the proposed fix invalid, but I'll check with Robert.
Eliezer Kanal - 2011-06-06 15:39:38 +0200
Thanks for checking this out, and sorry my original fix wasn't good. I guess I now know why there were axis offsets in the original algorithm :)