I tried to reproduce it. I can verify Step 1 with the MITK Multilabel Image reader but if I use the ITK NrrdImageIO reader there is no option to use autocrop.

With step 2 I'm not sure what to expect:
I can confirm that I get a cropped segmentation as a normal image with multiple pixel values if I use an image with more than two labels (e.g. MultiLabel/Pic3DAsMultilabelImage.nrrd).
If I remove one of the regions using the MultiLabel View I get a cropped segmentation as a normal image, not in black and white but grayscale (having two different gray colors for the two labels). I could set the Colormap of the node (context-menu of the data node) to Multilabel but this does not always produce nice results.

Can someone please verify, e.g. @kislinsk

I can confirm that autocrop in the DataManager context menu is broken and that it probably was never adapted to the LabelSetImage data type: when someone autocrops a segmentation (which is a LabelSetImage since years now even for "binary" segmentations created by the old segmention view), the cropped image should also be a cropped LabelSetImage containing all labels and layers. Other crop strategies like crop to a certain label is subject of the Multilabel Segmentation View context menu, but not of the general DataManager context menu.

Note that it's still possible to have true binary images as input to Autocrop, in which case both possible output types have their reasons to exist.

@kalali I can confirm that there is no option to use autocrop when using the ITK NrrdImageIO reader. However, when you load an image with the ITK reader (I used MultiLabel/Pic3DAsMultilabelImage.nrrd as well) and you convert it to a segmentation
(Right click ->Convert to segmentation) and then autocrop the new segmentation node, the name also changes to "No Name". So it might be a general problem when autocropping.

@kahl I can confirm your workflow for the ITK NrrdImageIO reader.
@kislinsk I can also confirm that autocrop does not alter the name if used on a binary segmentation.

What I found out so far:
The bug starts with

line 101 / 104: node->SetData( this->IncreaseCroppedImageSize(image) );

inside

void QmitkAutocropAction::Run( const QList<mitk::DataNode::Pointer> &selectedNodes )

(depending on the image type segmentation / multilabel segmentation).
This leads to a call of

void mitk::DataNode::SetData(mitk::BaseData *baseData)

And here we have the following lines, where both the binary segmentation and the multilabel segmentation differ:

// Do previous and new data have same type? Keep existing properties.
if (0 == strcmp(m_Data->GetNameOfClass(), baseData->GetNameOfClass()))
{
  m_Data = baseData;
}
else
{
  m_Data = baseData;
  this->GetPropertyList()->Clear();
  mitk::CoreObjectFactory::GetInstance()->SetDefaultProperties(this);
}

The call of mitk::CoreObjectFactory::GetInstance()->SetDefaultProperties(this); produces the node name DataNode::NO_NAME_VALUE = "No Name!";
In the multilabel segmentation case the two class types are:
\MITK-Data\Multilabel\Pic3DAsMultilabelImage.nrrd = mitk::LabelSetImage
cropped image = mitk::Image
whereas in the binary segmentation case the two class types are:
binary segmentation = mitk::Image
cropped image = mitk::Image

So there is a problem with different image output types the autocrop action generates.

For 2. I would like to have a discussion about the expected results.

The problem of different class types / image types is also the source for the bug mentioned in T27386: [MultiLabel] Workbench crashes if autocrop is used with opened plugin view without patient image.
@floca suggested to completely remove the autocrop-action from the context menu (at least for the multilabel segmentation) because it is not clear what to expect. Multilabel segmentations offer different possibilities for cropping and this could be handled inside the multilabel segmentation view.
That's also an option I see for the issue mentioned in 2.

@kislinsk/@kalali Is this bug also solved due to your fix of T27386?

+1