The measurements produced by OHIF are wrong, if pixel resolution is stored in ImagerPixelSpacing fields).
See attached image and DICOM file: the diameter should be 3 mm, instead of 15 mm.
The DICOM file is also attached.

I believe this has been resolved. If you're still seeing this issue in master, please don't hesitate to comment and I will be more than happy to re-open and investigate further.
This is not resolved, the value is only displayed in pixels rather than "mm" (which is better) but we should be able to display a valid measurement "3 mm" as other viewers
Latest OHIF Master:

MicroDicom

Read @chafey's comments here: https://github.com/cornerstonejs/cornerstoneWADOImageLoader/pull/261#issuecomment-499951878
We can't use imagerPixelSpacing as a fallback, or at least we shouldn't in these libraries. It introduces a hazard that should be a deliberate decision for anyone creating a viewer implementation.
That, at least, has been the guidance for all cornerstone libraries to date. Stick to the standard and try not to make allowances for vendors that don't adhere to them.
@swederik is the product owner. If you can convince him otherwise, we could introduce it as a fallback in OHIF libraries. We also have the ability to show a warning, highlight the hazard, or make this an opt-in behavior. The issue then becomes, if we persist these annotations, that warning likely wouldn't be recorded with what would be perceived as 100% accurate measurements.
@Zaid-Safadi, just now reading your response to @chafey. If the behavior is inconsistent with the standard, we can of course rectify things! I'll brush up on my understanding, and wait for this conversation to play out.
I would recommend we keep this open for reference as this is something that OHIF as a viewer/display application needs to address.
Whether reading the imagerPixelSpacing value in cornerstone library or directly in OHIF is agnostic from the fact that there are cases where the user wants to display the measurements in "mm" if imagerPixelSpacing is the only attribute available which is the current behavior in the original post and the viewers I have seen so far.
This was fixed (finally) by https://github.com/OHIF/Viewers/pull/1555
