Hi,

It is nice to see the fix works. Dawn will understand only English 
locale, I can live with it. Indeed, I was not aware of this issue until 
now. However my opinion is that limiting Dawn to one local, while the 
underlying machine (Java), and the underlying operating system supports 
multiple locals, is an interesting decision. I do not know the best, 
optimal solution for parsing the numbers, but doing a quick search on 
the internet resulted in a suggestion of using java.util.Scanner. It can 
accept File, InputStream, Path, Readable and String as source, and can 
provide boolean, int, float, double, etc. as result of calling 
nextBoolean, nextInt, etc. It slightly differs for example from 
Integer.valueOf(String), because this valueOf assumes the whole String 
is the number, while nextInt processes characters what can be 
interpreted as Integer. That is "23bad" is an exception for valueOf, but 
returns 23 from nextInt, I guess. Besides, probably there are other 
solutions than Scanner, for the parsing issue.

Gábor

08/04/2014 12:03 keltezéssel, Gero Flucke írta:
> On Tue, 8 Apr 2014, [log in to unmask] wrote:
>
>> Could you tell me if this snapshot build works for you Gero?
>> ASAP please - thanks for finding this, as always :)
>>
>> http://opengda.org/DawnDiamond/master/downloads/builds-snapshot/
>
> Hi Matt, all,
> sorry, I was out of office...
>
> Now I tested on Windows where I had the trouble before and now I can 
> edit the values in the powder diffraction view.
>
> Thanks for fixing!!
>
>     Gero
>
> PS:
> While editing a number it is still written with a comma (see Pixel -> 
> y-size being "0,240" in attached screenshot), but afterwards it is 
> written with a dot, (see Pixel -> x-size being "0.21").
>
>> -----Original Message-----
>> From: Gerring, Matt (DLSLtd,RAL,LSCI)
>> Sent: 08 April 2014 09:42
>> To: Filik, Jacob (DLSLtd,RAL,LSCI); 'Gero Flucke'
>> Cc: [log in to unmask]
>> Subject: RE: [DAWN-DEV] 2D powder diffraction calibration in DAWN
>>
>> Hi folks,
>>
>> Jake and I have just experimented with locales. This looks like a 
>> show stopper for using DAWN in Germany - I will have to fix this 
>> before release.
>>
>> I suggest that we make sure that the Locale for DAWN is always 
>> English using something like:
>>
>>
>>     static {
>>         final Locale local   = Locale.getDefault();
>>         final Locale english = new Locale("en", local.getCountry());
>>         Locale.setDefault(english);
>>     }
>>
>> This will fix several other defects seen at the German end I think!!
>>
>> I will make this change to the 1.5 build unless anyone knows why it 
>> would not work?
>>
>> Sincerely,
>>
>> Matt
>>
>> -----Original Message-----
>> From: Filik, Jacob (DLSLtd,RAL,LSCI)
>> Sent: 08 April 2014 09:08
>> To: 'Gero Flucke'
>> Cc: Gerring, Matt (DLSLtd,RAL,LSCI)
>> Subject: RE: [DAWN-DEV] 2D powder diffraction calibration in DAWN
>>
>> Hi Gero,
>>
>> I have passed this issue on to Matt, it looks like the diffraction 
>> tool is not handling location correctly (i.e. it doesn't parse "0,9" 
>> into a double, whereas "0.9" would work fine).
>>
>> Hopefully we can get a fix in, I also have no idea why Linux and 
>> Windows would differ.
>>
>> Jacob
>>
>> -----Original Message-----
>> From: Gero Flucke [mailto:[log in to unmask]]
>> Sent: 08 April 2014 09:04
>> To: Filik, Jacob (DLSLtd,RAL,LSCI)
>> Subject: RE: [DAWN-DEV] 2D powder diffraction calibration in DAWN
>>
>> On Tue, 8 Apr 2014, Gero Flucke wrote:
>>
>>> Hi again,
>>> maybe you wanted to have a look at the .log file from 
>>> workspace/.metadata?
>>> Forgot to attach it yesterday.
>>
>> Hi,
>> in addition, I now ran on the most recent snapshot, 
>> DawnDiamond-1.5.0.v20140407-windows64. The problem stays as before.
>>
>> This also means that, after having run the calibration, I can edit 
>> even less of the parameters - only pitch angle and detector!
>> Together with the fact that the 'Diffraction Metadata Defaults' are 
>> neither editable nor do they react on 'Restore Defaults' (except the 
>> pitch if changed by hand!), I could imagine that the access to the 
>> actual values and the default values is somehow mixed, i.e. the 
>> numbers shown in the 'Powder Diffraction' view refer to the defaults 
>> (at least after calibration and except the untouched pitch), but one 
>> is not allowed to change them. In the preferences menu 'Restore 
>> defaults' would then overwrite the shown values by themselves.
>> Note that also on linux the metadata defaults after a fit are changed 
>> to the fit result and, after manipulation 'by hand', they are 
>> restorable to the fit results.
>>
>> Well, at least some thoughts - no idea though why Windows and Linuz 
>> should differ then...
>>
>> Cheers
>>
>>     Gero
>>
>>> On Mon, 7 Apr 2014, Gero Flucke wrote:
>>>
>>>> On Mon, 7 Apr 2014, [log in to unmask] wrote:
>>>>
>>>>> Oh, also a screenshot of the values not being editable would also be
>>>>> of assistance. I will grab the latest product build now and see if
>>>>> that shows any differences to a development version.
>>>>
>>>> Hi again,
>>>> attached is a scrrenshot where I have not yet calibrated, but want to
>>>> edit the start values. You can see that I am able to edit the
>>>> distance. It works similarly for the beam centre and the angles, but
>>>> not for the pixel size or the wavelength - whatever I click on the 
>>>> field with the '*', I cannot edit!
>>>> The 'dawn_std_out.txt' is attached, but doe snot seem to help,
>>>> std_err is empty.
>>>>
>>>> Note that it is the same problem with editing the metadata defaults
>>>> in the preferences! There 'Restore defaults' does not work either to
>>>> get back to
>>>> 0.9 Angstrom and 200 mm distance. (That seems also to be the case on
>>>> Linux!)
>>>>
>>>> Note sure whether this is of help...
>>>>
>>>> Cheers
>>>>
>>>>     Gero
>>>>
>>>>> -----Original Message-----
>>>>> From: Gero Flucke [mailto:[log in to unmask]]
>>>>> Sent: 07 April 2014 14:50
>>>>> To: Filik, Jacob (DLSLtd,RAL,LSCI)
>>>>> Subject: RE: [DAWN-DEV] 2D powder diffraction calibration in DAWN
>>>>>
>>>>> On Mon, 7 Apr 2014, [log in to unmask] wrote:
>>>>>
>>>>>> I am having trouble reproducing this issue, all is working fine for
>>>>>> me on windows,
>>>>>
>>>>> Hi Jacob,
>>>>> strange. Could it be something with access rights etc.? When I start
>>>>> DAWN on Windows the second time (first time never works, known
>>>>> problem if I remember correctly...), I am asked by the windows
>>>>> firewall to allow dawn.exe to communicate on domain and private
>>>>> networks. Since I have no admin rights, I cannot do that.
>>>>> Tomorrow I can probably check whether allowing this helps.
>>>>>
>>>>>> would you be able to send me the log file if you catch this
>>>>>> happening again.
>>>>>
>>>>> Now I have to leave for a meeting, but willsend later.
>>>>>
>>>>>> A few things to try if it does get stuck:
>>>>>> a) close and re-open perspective
>>>>>> b) close perspective, go to preferences and make sure default value
>>>>>> is something sensible (like 1), re-open
>>>>>> c) (horrible but might work) open diffraction tool on Diffraction
>>>>>> Plotting View. This should link to the same metadata, would be
>>>>>> interesting to see if this was editable.
>>>>>
>>>>> Nothing of that helped, more details later.
>>>>>
>>>>> Cheers
>>>>>
>>>>> Gero
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Gero Flucke [mailto:[log in to unmask]]
>>>>>> Sent: 07 April 2014 09:21
>>>>>> To: Filik, Jacob (DLSLtd,RAL,LSCI)
>>>>>> Subject: RE: [DAWN-DEV] 2D powder diffraction calibration in DAWN
>>>>>>
>>>>>> On Fri, 4 Apr 2014, [log in to unmask] wrote:
>>>>>>
>>>>>>> Thanks Gero, I hope you are having a mostly positive experience...
>>>>>>
>>>>>> Hi Jacob,
>>>>>> sure! Also the scientist said that the calibration itself seems to
>>>>>> provide quite good constants as can be judged from the calibration
>>>>>> check, even without providing reasonable start parameters.
>>>>>>
>>>>>>>> Playing with the calibration together with a scientist today on a
>>>>>>>> Windows 64-bit machine (using a snapshot from April 1)...
>>>>>>>
>>>>>>> Sounds like I will have to pull down the source on to windows and
>>>>>>> have a look at this. Thanks for this update. If you close and
>>>>>>> re-open the perspective does the problem go away?  Do your .dat
>>>>>>> file open in DExplore or Trace correctly?
>>>>>>
>>>>>> Will test soon - but now tehseminar room where I can use a windoas
>>>>>> machine is occupied...
>>>>>>
>>>>>>>> A bit odd was that, when storing the calibration results (export
>>>>>>>> metadata to file), one should select something in the workspace,
>>>>>>>> but when using the powder integration tool and 'imports metadata
>>>>>>>> from NeXus file', a dialog opens that browses the file system.
>>>>>>>> (Seen on Linux, not tested on Windows)
>>>>>>>
>>>>>>> Yes, this is really annoying, also some wizards will let you
>>>>>>> choose whether you browser the project OR the file system! I will
>>>>>>> see if there is a ticket for this and if not I will log one.
>>>>>>>
>>>>>>>> Finally, I was slightly 'confused' that the metadata NeXus file
>>>>>>>> stores Energy in units of Angstrom (i.e. in fact the wavelength).
>>>>>>>
>>>>>>> The current calibration Nexus files are not "proper" Nexus files
>>>>>>> (mostly our Diffraction metadata object stored in a Nexus file).
>>>>>>> The next release of DAWN should change this to a proper Nexus
>>>>>>> standard way of storing the Wavelength and detector geometry.
>>>>>>
>>>>>> Fine for these fixes later - hope that the problem that does not
>>>>>> let us select the wavelength on windows makes it into 1.5.0 - that
>>>>>> would make it much more useful for our scientists!
>>>>>>
>>>>>> Cheers
>>>>>>
>>>>>>     Gero
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Gero Flucke [mailto:[log in to unmask]]
>>>>>>> Sent: 04 April 2014 16:45
>>>>>>> To: Filik, Jacob (DLSLtd,RAL,LSCI)
>>>>>>> Subject: RE: [DAWN-DEV] 2D powder diffraction calibration in DAWN
>>>>>>>
>>>>>>> On Mon, 31 Mar 2014, Gero Flucke wrote:
>>>>>>>
>>>>>>>> Hi Jacob,
>>>>>>>> thanks for the explanations and the article! I may come back with
>>>>>>>> other questions later.
>>>>>>>>
>>>>>>>> For now just a little bug report:
>>>>>>>> Trying it this time on a windows7 64 bit system, I was not able
>>>>>>>> to edit many of the values in the 'Powder Diffraction' view of
>>>>>>>> the geometry parameters, only the pull down menu of the detector
>>>>>>>> and setting the usually not used angle worked. No trouble in my
>>>>>>>> case since the pixel size was among the known detector types, but
>>>>>>>> otherwise...
>>>>>>>
>>>>>>> Hi again Jacob,
>>>>>>> soem more feedback:
>>>>>>> Playing with the calibration together with a scientist today on a
>>>>>>> Windows 64-bit machine (using a snapshot from April 1) we were hit
>>>>>>> by this again (they believe the energy of their monochromator more
>>>>>>> than any
>>>>>>> fit...) - but found more details:
>>>>>>> Before a first calibration, we were not able to edit wavelength
>>>>>>> and distance, but the angles (not sure about the beam centre...).
>>>>>>> After running the calibration once, we could only edit one of the
>>>>>>> angles (pitch).
>>>>>>>
>>>>>>> Another problem we observed on Windows that I could not reproduce
>>>>>>> on Linux was that we 'converted' the integrated line (from Powder
>>>>>>> Intgeration or calibration check - do not know anymore) to a 
>>>>>>> .dat file.
>>>>>>> But then we were not able to read back this file - the datasets
>>>>>>> were not correctly identified, i.e. the 'Data' view of the Data
>>>>>>> Bowsing perspective was empty.
>>>>>>>
>>>>>>> A bit odd was that, when storing the calibration results (export
>>>>>>> metadata to file), one should select something in the workspace,
>>>>>>> but when using the powder integration tool and 'imports metadata
>>>>>>> from NeXus file', a dialog opens that browses the file system.
>>>>>>> (Seen on Linux, not tested on Windows)
>>>>>>>
>>>>>>> Finally, I was slightly 'confused' that the metadata NeXus file
>>>>>>> stores Energy in units of Angstrom (i.e. in fact the wavelength).
>>>>>>>
>>>>>>> Have a nice weekend!
>>>>>>>
>>>>>>>     Gero
>>>>>>>
>>>>>>>
>>>>>>>> In addition I did not find a way to do a complete reset of the
>>>>>>>> initial values used for my calibration image - except starting
>>>>>>>> from a clean workspace...
>>>>>>>>
>>>>>>>> Cheers
>>>>>>>>
>>>>>>>>     Gero
>>>>>>>>
>>>>>>>> On Mon, 31 Mar 2014, [log in to unmask] wrote:
>>>>>>>>
>>>>>>>>> Hi Gero,
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>> its indeed worth a paper - would be interesting to get details
>>>>>>>>>> about the procedure, the fit and the exact meaning of the
>>>>>>>>>> calibration parameters.
>>>>>>>>>
>>>>>>>>> Some parts of the calibration routine have already been
>>>>>>>>> published [Complete elliptical ring geometry provides energy and
>>>>>>>>> instrument calibration for synchrotron-based two-dimensional
>>>>>>>>> X-ray diffraction Michael L. Hart , Michael Drakopoulos ,
>>>>>>>>> Christina Reinhard , Thomas Connolley Journal of Applied
>>>>>>>>> Crystallography (Vol: 46, Pages: 1249 -
>>>>>>>>> 1260) DOI:
>>>>>>>>> 10.1107/S0021889813022437"], some parts have not. For the
>>>>>>>>> detector geometry the calibration uses the fit 2D style detector
>>>>>>>>> tilt and tilt plane rotation (directions of rotation may be
>>>>>>>>> flipped), although the results are stored in the
>>>>>>>>> DetectorProperties object which is capable of a more general
>>>>>>>>> description of geometry (see Java Doc header in 
>>>>>>>>> DetectorProperties class).
>>>>>>>>> Ideally we would allow you to save the calibration in a PyFAI
>>>>>>>>> PONI file but we haven't had a chance to look into that yet. The
>>>>>>>>> 2D powder image calibration/reduction functionality should grow
>>>>>>>>> rapidly over the next few releases, when we are happy with what
>>>>>>>>> we have we will write it up and add the code to the vanilla.
>>>>>>>>>
>>>>>>>>>> What is the idea to be able to put several images into the list
>>>>>>>>>> in the 'Diffraction Calibration View'? A combined fit?
>>>>>>>>>
>>>>>>>>> Yes, exactly this. If you have images collected at well defined
>>>>>>>>> separation from each other (a good, well characterised encoder,
>>>>>>>>> ie not a guess), but unknown distance from the sample, the
>>>>>>>>> multiple images can be used simultaneously to calibrate the
>>>>>>>>> energy and distance (as described in the above paper, ellipse
>>>>>>>>> parameter calibration only). This is really useful if you have
>>>>>>>>> only a few nice rings in each image, as you can get a good
>>>>>>>>> calibration without needing to use many outer rings. You should
>>>>>>>>> NEVER have more than one image in the table if this is not the
>>>>>>>>> case. On entering 2 or more images in the table an extra column
>>>>>>>>> appears to allow you to enter the encoder value for the 
>>>>>>>>> distances the images were collected at.
>>>>>>>>>
>>>>>>>>>> It would be nice to know what exactly is hidden behind Ellipse
>>>>>>>>>> and Point calibration - and why 'Point calibrate' settings are
>>>>>>>>>> greyed out although I can switch on to 'Finish with point
>>>>>>>>>> calibration optimisation' in the auto calibration.
>>>>>>>>>> But expect some docu to appear in the next weeks...
>>>>>>>>>
>>>>>>>>> Point calibration uses the found points on the rings to optimise
>>>>>>>>> the detector geometry rather than the determined ellipse
>>>>>>>>> parameters. The point calibration requires a good first guess
>>>>>>>>> (ie by matching the calibrant rings by eye), whereas the ellipse
>>>>>>>>> calibration works from no initial input. The advantage of the
>>>>>>>>> point calibration is that it works well for incomplete rings or
>>>>>>>>> cases where the tilt is so high the rings are no longer
>>>>>>>>> elliptical (see attached screenshot). The finish with point cal
>>>>>>>>> on the auto tends to give better results for a single image than
>>>>>>>>> for the auto alone, but since the distance/energy fix is set by
>>>>>>>>> the ellipse calibration there is no option to alter this (they
>>>>>>>>> are greyed out), the options are only for the manual
>>>>>>>>> calibration. Documentation will follow the release.
>>>>>>>>>
>>>>>>>>>> One central question:
>>>>>>>>>> I can calculate parameters and they are applied to the
>>>>>>>>>> caibration image for cross checks.
>>>>>>>>>> How do I apply the calibration to the integration of other 
>>>>>>>>>> images?
>>>>>>>>>> BTW:
>>>>>>>>>> It would be nice to export values 100% equivalent to those in
>>>>>>>>>> pyFAI to make use of its speed in Python scripts...
>>>>>>>>>
>>>>>>>>> There is a powder integration tool in the tools menu, it is very
>>>>>>>>> basic at the moment, but allows a stack of images to be reduced.
>>>>>>>>> It uses the stack processing functionality of the Data Browsing
>>>>>>>>> perspective, to run over a stack of tiffs/HDF5 image stack. The
>>>>>>>>> only integration options are pixel-splitting, non-pixel
>>>>>>>>> splitting, and 2D pixel splitting and whether to apply the
>>>>>>>>> cos3(2Theta) correction (not applied in the powder check tool).
>>>>>>>>> It is not fast, yet, but the output results should be similar to
>>>>>>>>> pyFAI. The reduced data is saved as HDF5, which can then be
>>>>>>>>> converted to txt using the NCD converter option. The reduction
>>>>>>>>> is VERY basic at the moment, but is our next target for 
>>>>>>>>> improvement.
>>>>>>>>> That being said, we do encourage people to use PyFAI on the
>>>>>>>>> python side, it is a lovely little library, some of our
>>>>>>>>> scientists here are using DAWN to calibrate, pyFAI to reduce, I
>>>>>>>>> can send you the python code to go from a DAWN exported
>>>>>>>>> calibration NXS file to a pyFAI azimuthal integrator if you like
>>>>>>>>> (loading fit2d style). DAWNs integration uses the same
>>>>>>>>> histogramming integration approach as pyFAI, I would hope that
>>>>>>>>> in the end, the results would be the same whether the 
>>>>>>>>> reduction was done in pyFAI or DAWN.
>>>>>>>>>
>>>>>>>>> Thanks for the bugs, we will try and get them sorted for the 
>>>>>>>>> release.
>>>>>>>>>
>>>>>>>>> Jake
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Gero Flucke [mailto:[log in to unmask]]
>>>>>>>>> Sent: 28 March 2014 16:26
>>>>>>>>> To: [log in to unmask]
>>>>>>>>> Subject: Re: [DAWN-DEV] 2D powder diffraction calibration in
>>>>>>>>> DAWN
>>>>>>>>>
>>>>>>>>> On Thu, 27 Mar 2014, [log in to unmask] wrote:
>>>>>>>>>
>>>>>>>>>> We will consider releasing it in Vanilla, Jake and I will
>>>>>>>>>> discuss with the players involved, it will not be for 1.5
>>>>>>>>>> Vanilla. The normal/ideal process for us would be to publish a
>>>>>>>>>> paper on features before releasing the source code.
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>> its indeed worth a paper - would be interesting to get details
>>>>>>>>> about the procedure, the fit and the exact meaning of the
>>>>>>>>> calibration parameters.
>>>>>>>>>
>>>>>>>>> No problem with official 1.5 Vanilla.
>>>>>>>>> Maybe you can help me how to sneak it into a DESY build? Just
>>>>>>>>> demonstrated it to a scientist in my group and he says it is
>>>>>>>>> clearly something that people are interested in - calibration by
>>>>>>>>> just pressing one button!
>>>>>>>>>
>>>>>>>>>> The 1.5 Betas do include the feature and are available on the
>>>>>>>>>> web
>>>>>>>>>> site:
>>>>>>>>>> http://www.dawnsci.org/downloads
>>>>>>>>>>
>>>>>>>>>> We would welcome any help with this process as always.
>>>>>>>>>
>>>>>>>>> OK, I just downloaded the most recent version:
>>>>>>>>> DawnDiamond-1.5.0.v20140325-1732-linux64
>>>>>>>>>
>>>>>>>>> Here some feedback:
>>>>>>>>>
>>>>>>>>> In general:
>>>>>>>>> Great!
>>>>>>>>> I tried a few files of different calibration standards and,
>>>>>>>>> after getting used to the way things are related, the auto
>>>>>>>>> calibration always got reasonable results (sometimes fixing beam
>>>>>>>>> energy toa value provided be the
>>>>>>>>> beamline) that one can nicely control with the 'Powder
>>>>>>>>> calibration check'!
>>>>>>>>> Besides the rough 0.5 pixel shift compared to Fit2D Jacob
>>>>>>>>> mentioned, the parameters look similar to ones calculated by 
>>>>>>>>> Fit2D.
>>>>>>>>>
>>>>>>>>> What is the idea to be able to put several images into the list
>>>>>>>>> in the 'Diffraction Calibration View'? A combined fit?
>>>>>>>>> First I thought that I can just list files and select one to be
>>>>>>>>> used (the high-lighted one). But then I was confused that,
>>>>>>>>> during processing, also other image files are displayed in the
>>>>>>>>> 'Diffraction Plotting'.
>>>>>>>>> After removing all files but one, the calibration ran smoothly,
>>>>>>>>> but still the 'Powder Calibration Check' is confused and shows
>>>>>>>>> something related to one of the removed files - see attached
>>>>>>>>> screenshot 'confusedDiffCalib.png'.
>>>>>>>>>
>>>>>>>>> It would be nice to know what exactly is hidden behind Ellipse
>>>>>>>>> and Point calibration - and why 'Point calibrate' settings are
>>>>>>>>> greyed out although I can switch on to 'Finish with point
>>>>>>>>> calibration optimisation' in the auto calibration.
>>>>>>>>> But expect some docu to appear in the next weeks...
>>>>>>>>>
>>>>>>>>> One central question:
>>>>>>>>> I can calculate parameters and they are applied to the
>>>>>>>>> caibration image for cross checks.
>>>>>>>>> How do I apply the calibration to the integration of other 
>>>>>>>>> images?
>>>>>>>>> BTW:
>>>>>>>>> It would be nice to export values 100% equivalent to those in
>>>>>>>>> pyFAI to make use of its speed in Python scripts...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Now some minor comments on data display:
>>>>>>>>>
>>>>>>>>> Diffraction Plotting:
>>>>>>>>> I miss the colour scale bar
>>>>>>>>>
>>>>>>>>> Powder calibration check:
>>>>>>>>> general:
>>>>>>>>> some of the views plot vertical calibration lines: would be nice
>>>>>>>>> if one could distinguish between lines used for calibration and
>>>>>>>>> not used
>>>>>>>>>
>>>>>>>>> cake view:
>>>>>>>>> y-axis
>>>>>>>>> - should get title 'phi/azimuth/or_how_you_call_it' with unit
>>>>>>>>> - odd azimuth values chosen as y-axis labels (e.g. -179.858, 
>>>>>>>>> -69.512,
>>>>>>>>>   40.835, 151.181 instead of some multiples of 90 or 20 or...)
>>>>>>>>> - x-axis lacks unit (1/A) or (degree)
>>>>>>>>>
>>>>>>>>> full image view
>>>>>>>>> - x-axis title lacks unit
>>>>>>>>> - what kind of 'geometrical correction' is applied in the 
>>>>>>>>> integration,
>>>>>>>>>   i.e. do you sum pixels, divide by pixel area and devide by
>>>>>>>>>   cos(2theta)**3? Since the background gets smaller towards
>>>>>>>>> large angles I
>>>>>>>>>   can imagine that you devide only by cos(2theta)**2.
>>>>>>>>>   (BTW: using the third power instead of the second has been 
>>>>>>>>> fixed
>>>>>>>>>   recently in pyFAI)
>>>>>>>>>
>>>>>>>>> quadrant view
>>>>>>>>> - while calculating, x-axis has proper axis title with unit
>>>>>>>>> after some processing, but y-axis is just 'y-axis'
>>>>>>>>> - final plot has correct y-axis but its x-axis lacks a unit
>>>>>>>>>
>>>>>>>>> peak fit view
>>>>>>>>> - x-axis title lacks unit
>>>>>>>>> - should one also add verticallines for the peaks used in 
>>>>>>>>> calibration?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Cheers
>>>>>>>>>
>>>>>>>>>     Gero
>>>>>
>>>>> -- 
>>>>> --------------------------------------------------------------------
>>>>> ---
>>>>> Gero Flucke
>>>>> Group 'Experiment Control' (FS-EC)
>>>>>   * Scientific Software
>>>>> DESY
>>>>> (Room 228, Bldg. 25b)
>>>>> Notkestr. 85
>>>>> 22607 Hamburg
>>>>> Germany
>>>>> Tel: +49 (0)40 8998 1985
>>>>>
>>>>> -- 
>>>>> This e-mail and any attachments may contain confidential, copyright
>>>>> and or privileged material, and are for the use of the intended 
>>>>> addressee only.
>>>>> If you are not the intended addressee or an authorised recipient of
>>>>> the addressee please notify us of receipt by returning the e-mail
>>>>> and do not use, copy, retain, distribute or disclose the information
>>>>> in or attached to the e-mail.
>>>>> Any opinions expressed within this e-mail are those of the
>>>>> individual and not necessarily of Diamond Light Source Ltd.
>>>>> Diamond Light Source Ltd. cannot guarantee that this e-mail or any
>>>>> attachments are free from viruses and we cannot accept liability for
>>>>> any damage which you may sustain as a result of software viruses
>>>>> which may be transmitted in or with the message.
>>>>> Diamond Light Source Limited (company no. 4375679). Registered in
>>>>> England and Wales with its registered office at Diamond House,
>>>>> Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11
>>>>> 0DE, United Kingdom
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> -- 
>>>> ---------------------------------------------------------------------
>>>> -- 
>>>> Gero Flucke
>>>> Group 'Experiment Control' (FS-EC)
>>>>  * Scientific Software
>>>> DESY
>>>> (Room 228, Bldg. 25b)
>>>> Notkestr. 85
>>>> 22607 Hamburg
>>>> Germany
>>>> Tel: +49 (0)40 8998 1985
>>>
>>> -- 
>>> ----------------------------------------------------------------------
>>> -
>>> Gero Flucke
>>> Group 'Experiment Control' (FS-EC)
>>>  * Scientific Software
>>> DESY
>>> (Room 228, Bldg. 25b)
>>> Notkestr. 85
>>> 22607 Hamburg
>>> Germany
>>> Tel: +49 (0)40 8998 1985
>>
>> -- 
>> -----------------------------------------------------------------------
>> Gero Flucke
>> Group 'Experiment Control' (FS-EC)
>>   * Scientific Software
>> DESY
>> (Room 228, Bldg. 25b)
>> Notkestr. 85
>> 22607 Hamburg
>> Germany
>> Tel: +49 (0)40 8998 1985
>>
>> -- 
>> This e-mail and any attachments may contain confidential, copyright 
>> and or privileged material, and are for the use of the intended 
>> addressee only. If you are not the intended addressee or an 
>> authorised recipient of the addressee please notify us of receipt by 
>> returning the e-mail and do not use, copy, retain, distribute or 
>> disclose the information in or attached to the e-mail.
>> Any opinions expressed within this e-mail are those of the individual 
>> and not necessarily of Diamond Light Source Ltd.
>> Diamond Light Source Ltd. cannot guarantee that this e-mail or any 
>> attachments are free from viruses and we cannot accept liability for 
>> any damage which you may sustain as a result of software viruses 
>> which may be transmitted in or with the message.
>> Diamond Light Source Limited (company no. 4375679). Registered in 
>> England and Wales with its registered office at Diamond House, 
>> Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, 
>> United Kingdom
>>
>>
>>
>>
>>
>
> -- 
> -----------------------------------------------------------------------
> Gero Flucke
> Group 'Experiment Control' (FS-EC)
>   * Scientific Software
> DESY
> (Room 228, Bldg. 25b)
> Notkestr. 85
> 22607 Hamburg
> Germany
> Tel: +49 (0)40 8998 1985