Fix bugs in mvtec exporter

[djdameln]

Summary

This PR fixes two small bugs in the MVTec exporter:

• When writing images, the defect type was added to the save path as part of the subdirectory, but the defect type was also added by _make_item_filename as part of the item id. So the final path contained the defect type twice (bottle/test/broken_large/broken_large/000.png instead of bottle/test/broken_large/000.png). This was fixed by not appending the defect type to the subdirectory.
• Binary anomaly masks were not multiplied by 255 before writing the image, resulting in empty masks.

How to test

Checklist

• I submit my changes into the develop branch
• I have added description of my changes into CHANGELOG
• I have updated the documentation accordingly
• I have added tests to cover my changes
• I have linked related issues

License

• I submit my code changes under the same MIT License that covers the project.
  Feel free to contact the maintainers if that's a concern.
• I have updated the license header for each file (see an example below)

# Copyright (C) 2023 Intel Corporation
#
# SPDX-License-Identifier: MIT

[vinnamkim]

Hi @djdameln,

Thanks for your contribution!

Is it ok if MvtecTask.detection has {0,1} mask? I think your correction should apply to this too.

datumaro/datumaro/plugins/data_formats/mvtec/exporter.py

Lines 88 to 95 in 064a314

	mask = np.zeros((*item.media.size,), dtype=np.uint8)
	for bbox in bboxes:
	x, y, h, w = bbox.get_bbox()
	mask = cv2.rectangle(mask, (x, y), (x + w, y + h), (1), -1)
	if not osp.exists(osp.join(self._save_dir, osp.dirname(mask_path))):
	os.mkdir(osp.join(self._save_dir, osp.dirname(mask_path)))
	cv2.imwrite(osp.join(self._save_dir, mask_path), mask)

If MVTec should mandatorily have {0, 255} binary mask rather than {0, 1} one, I think it would be good to add a unit test for this.

[djdameln]

@vinnamkim Thanks for the suggestion. I added the correction for the detection task type. I also added some unit tests to test this behaviour

[codecov-commenter]

Codecov Report

Patch coverage: 100.00% and no project coverage change

Comparison is base (04e23ab) 78.47% compared to head (42ba67e) 78.48%.

Additional details and impacted files

@@            Coverage Diff            @@
##           develop     #835    +/-   ##
=========================================
  Coverage    78.47%   78.48%            
=========================================
  Files          191      196     +5     
  Lines        23911    24304   +393     
  Branches      4912     4946    +34     
=========================================
+ Hits         18765    19075   +310     
- Misses        4044     4127    +83     
  Partials      1102     1102            

Flag	Coverage Δ
macos-11_Python-3.8	77.81% <100.00%> (+0.01%)	⬆️
ubuntu-20.04_Python-3.8	78.46% <100.00%> (+0.01%)	⬆️
windows-2019_Python-3.8	78.41% <100.00%> (+0.02%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
datumaro/plugins/data_formats/mvtec/exporter.py	72.72% <100.00%> (ø)
...aro/plugins/data_formats/datumaro_binary/mapper.py	0.00% <0.00%> (-86.42%)	⬇️
datumaro/util/__init__.py	86.73% <0.00%> (-2.63%)	⬇️
datumaro/plugins/splitter.py	88.44% <0.00%> (-0.23%)	⬇️
...o/plugins/data_formats/datumaro_binary/importer.py	100.00% <0.00%> (ø)
...gins/data_formats/datumaro_binary/mapper/common.py	100.00% <0.00%> (ø)
...ns/data_formats/datumaro_binary/mapper/__init__.py	100.00% <0.00%> (ø)
...ata_formats/datumaro_binary/mapper/dataset_item.py	81.03% <0.00%> (ø)
.../data_formats/datumaro_binary/mapper/annotation.py	100.00% <0.00%> (ø)
...o/plugins/data_formats/datumaro_binary/__init__.py	100.00% <0.00%> (ø)
... and 7 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[vinnamkim]

LGTM.