Back to the main page.

Bug 3260 - inconsistent surface/cortex colors

Status CLOSED FIXED
Reported 2017-03-01 07:06:00 +0100
Modified 2019-08-10 12:41:34 +0200
Product: FieldTrip
Component: plotting
Version: unspecified
Hardware: PC
Operating System: Mac OS
Importance: P5 normal
Assigned to: Arjen Stolk
URL:
Tags:
Depends on:
Blocks:
See also:

Arjen Stolk - 2017-03-01 07:06:42 +0100

ft_sourceplot (at line 1166): cortex_light = [0.781 0.762 0.664]; cortex_dark = [0.781 0.762 0.664]/2; whereas ft_plot_mesh relies on: cortex.m: [255 213 119]/255 = 1.0000 0.8353 0.4667 brain.m: [202 100 100]/255 = 0.7922 0.3922 0.3922 Personally, I use cortex_light most frequently as the others are just not very realistic (even for a colorblind). Does anyone know of a better cortex color? And should we try to be more consistent across functions? [ftver, ftpath] = ft_version; load([ftpath filesep 'template/anatomy/surface_pial_left.mat']); % cortex_light figure; ft_plot_mesh(mesh, 'facecolor', [0.781 0.762 0.664], 'EdgeColor', 'none'); view([-90 20]); lighting gouraud; camlight; % cortex_dark figure; ft_plot_mesh(mesh, 'facecolor', [0.781 0.762 0.664]/2, 'EdgeColor', 'none'); view([-90 20]); lighting gouraud; camlight; % cortex figure; ft_plot_mesh(mesh, 'facecolor', 'cortex', 'EdgeColor', 'none'); view([-90 20]); lighting gouraud; camlight; % brain figure; ft_plot_mesh(mesh, 'facecolor', 'brain', 'EdgeColor', 'none'); view([-90 20]); lighting gouraud; camlight;


Arjen Stolk - 2017-03-01 07:15:41 +0100

Note that 'realistic' is perhaps not the best choice of description given that intraop photos typically highlight a red/rose brain. I was more thinking of the gray tint typically used in publications.


Jan-Mathijs Schoffelen - 2017-03-01 11:01:10 +0100

I don't like the cortex_dark that much. Is it really used in ft_sourceplot? What about creating a cortex_light.m and making the stuff configureable in ft_sourceplot? This would allow the user to choose, and to use the cortex_light in ft_plot_mesh


Jan-Mathijs Schoffelen - 2017-03-01 20:17:06 +0100

it seems that the cortex_dark is only used in ft_sourceplot when a curv-field is present. I wonder whether we should just ditch it.


Arjen Stolk - 2017-03-01 20:40:52 +0100

Thanks for the swift response. It seems cortex_dark is used together with cortex_light to create a depth perspective across gyri and sulci: " %------do the plotting cortex_light = [0.781 0.762 0.664]; cortex_dark = [0.781 0.762 0.664]/2; if isfield(surf, 'curv') % the curvature determines the color of gyri and sulci color = surf.curv(:) * cortex_dark + (1-surf.curv(:)) * cortex_light; else color = repmat(cortex_light, size(surf.pos,1), 1); end ft_plot_mesh(surf,'edgecolor', 'none', 'vertexcolor', color); " I have moved this feature downstream to ft_plot_mesh, invoked by vertexcolor = 'curv', and added cortex_light.m and cortex_dark.m to plotting/private. Additionally moved lower level configurations (e.g. cfg.facecolor) upstream to ft_sourceplot (note, default cfg.vertexcolor = 'curv'). see: https://github.com/fieldtrip/fieldtrip/pull/352


Arjen Stolk - 2017-03-01 20:45:16 +0100

(In reply to Jan-Mathijs Schoffelen from comment #3) I see this comment just now. Plotting with facecolor 'cortex_light' and the cortex_dark/cortex_light curvature-dependent mix produces similar but not identical results: [ftver, ftpath] = ft_version; load([ftpath filesep 'template/anatomy/surface_pial_left.mat']); figure; ft_plot_mesh(mesh, 'facecolor', 'cortex_light', 'EdgeColor', 'none'); view([-90 20]); lighting gouraud; camlight; figure; ft_plot_mesh(mesh, 'vertexcolor', 'curv', 'EdgeColor', 'none'); view([-90 20]); lighting gouraud; camlight;


Arjen Stolk - 2017-03-01 20:46:06 +0100

(In reply to Arjen Stolk from comment #5) Note that the latter requires the new functionality (which is not pulled in yet).


Robert Oostenveld - 2019-08-10 12:35:22 +0200

This closes a whole series of bugs that have been resolved (either FIXED/WONTFIX/INVALID) for quite some time. If you disagree, please file a new issue on https://github.com/fieldtrip/fieldtrip/issues.


Robert Oostenveld - 2019-08-10 12:41:34 +0200

This closes a whole series of bugs that have been resolved (either FIXED/WONTFIX/INVALID) for quite some time. If you disagree, please file a new issue on https://github.com/fieldtrip/fieldtrip/issues.