Dear Martin Lentz,
I'l try to explain this behavior.
Why this happens?
In general you can not expect to export an ODF to a certain format and to recover it without any error. In your case assume the number of orientations you export would be very small, e.g., 20, then you probably would not expect the whole ODF information to be stored withing these 20 points. Of course you used much more points but nevertheless you have the problem that not the entire ODF information is stored within these points.
Why there is such a huge difference given the number of orientations I used to store the ODF?
The reason is how MTEX recovers the ODF from individual orientations. MTEX performs something that is called kernel density estimation, i.e., it places a "Gaussian" at every given orientation. This works quit well if the halfwidth of the Gaussian is chosen correctly. However, the halfwidth of the Gaussian is a priori unknown. Although MTEX provides some sophisticated methods to estimate a good halfwidth, the default value without any user interaction is 10 degree. This very conservative choice explains the strong smoothing in you example.
How to overcome this problem?
The most simplest way is to set the halfwidth of the "Gaussian" manually. This can be done by
odf = loadODF_generic(fname,'CS',CS,'SS',SS,'Bunge','Degree',...
'ColumnNames',{'Euler 1' 'Euler 2' 'Euler 3' 'weight'},'halfwidth',2.5*degree)
Replacing the halfwidth 2.5*degree by a smaller / larger value the resulting ODF becomes sharper / weaker.
What MTEX should do in the future?
We are planning to use a more ambitious choice of the halfwidth which is determined by the number of orientations. This should avoid the manual tuning in most cases.