Most likely due to 0002869

Hi Kevin, could you have a look ? As reported in previous note, this is most likely due to 0002869

Hi All,

I did a bit investigation and here is what I found. This issue is not due to 0002869. instead, it is something in
void qMRMLVolumeInfoWidget::setVolumeNode(vtkMRMLVolumeNode* volumeNode)

here we have the code look like this:

double* spacing = d->VolumeNode->GetSpacing();
int decimals = qMin(qMax(ctk::significantDecimals(spacing[0]),
                         qMax(ctk::significantDecimals(spacing[1]),
                              ctk::significantDecimals(spacing[2]))),
                    8);
d->ImageSpacingWidget->blockSignals(true);
d->ImageSpacingWidget->setDecimals(decimals);
d->ImageSpacingWidget->blockSignals(false);

so the decimal is set to be the minimum of significant decimals of spacing[0], spacing[1], spacing[2] and 8. in our case, the decimals for spacing[0] and spacing[1] is 1 so it is set to 1 which round 1.2999954223632813 to 1.3

I have changed the code to use maximum and now I can see the spacing to be 1.29999542 as shown in picture.

I think we need to come up with a rule how to set the number of decimals and this might be something we can discuss in the slicer hangout.

Nice catch, Kevin. It's important to not change any data in the MRML nodes unless the user changes something in the GUI - this gives protection agains unwanted changes when someone would like to just view data.

The minimum number of decimal digits for origin values should be at least 3, while for scaling and rotation should be about 8-10.
It's very tough to say what should be the maximum number of decimal digits during editing, because we don't want to see a value like 0.13000000000001 instead of 0.13, but at the same time we want to avoid information loss due to rounding.

I created a test which illustrates a catastrophic image information failure when this issue is combined with the precision issues:

https://github.com/blowekamp/Slicer/commit/25cf25f5cc4d7c490fab5c21eb871418c32ab9e6

Initial Origin: [547339, 218860, 20904.4]
Viewed Origin: (10000.0, 10000.0, 10000.0)

I find this whole double editing experience extremely frustrating. The behavior has changed a couple of times during the recent months, but it never worked correctly or intuitively.

For example, in the latest version (4.2.0-2013-08-06):
Clear one of the "Origin" fields and try to enter: 1.55555555555555555555... and the field will be filled with garbage such as 1.5656565656555.
Or try to enter 1.99999999999 and you'll see 2999mm.

I think the main problem is that you try to change the data while the user editing it. Maybe it cause by a loop in the model/GUI update (GUI change->model change->GUI change), which could be fixed by making the direction of the automatic synching between the model and the GUI one-way only: if the user modifies anything in the editbox (viewing only or moving the cursor does not mean modification!) then the synchronization direction would be set to GUI->model; if something (not the editbox!) changes the value in the model then the synchronization direction would be set to model->GUI.

Keeping precision (0003010) is fixed in r22281
Large numbers in Origin (0009428) are fixed in r22282
Odd decimal behavior (0009432) is fixed in r22281

Looks like a good fix for my issue.

What about my patch which adds a test for the issue? I don't see any other tests added to check this issue. Is there something wrong with my style or approach there?

you're patch a great, I'll integrate it asap

Closing resolved issues that have not been updated in more than 3 months