@@ -807,39 +807,38 @@ We recommend that if you do this, you specify ``max_fractional_value=1`` to
807807clearly communicate that the segmentation is inherently binary in nature.
808808
809809Why would you want to make this seemingly rather strange choice? Well,
810- ``"FRACTIONAL" `` SEGs tend to compress *much * better than ``"BINARY" `` ones
811- (see next section). Note however, that this is arguably an misuse of the intent
812- of the standard, so *caveat emptor *.
810+ ``"FRACTIONAL" `` SEGs tend to compress better than ``"BINARY" `` ones (see next
811+ section). Note however, that this is arguably an misuse of the intent of the
812+ standard, so *caveat emptor *. Also note that while this used to be a more
813+ serious issue it is less serious now that ``"JPEG2000Lossless" `` compression is
814+ now supported for ``"BINARY" `` segmentations as of highdicom v0.23.0.
813815
814816Compression
815817-----------
816818
817819The types of pixel compression available in segmentation images depends on the
818- segmentation type. Pixels in a ``"BINARY" `` segmentation image are "bit-packed"
819- such that 8 pixels are grouped into 1 byte in the stored array. If a given frame
820- contains a number of pixels that is not divisible by 8 exactly, a single byte
820+ segmentation type.
821+
822+ Pixels in an uncompressed ``"BINARY" `` segmentation image are "bit-packed" such
823+ that 8 pixels are grouped into 1 byte in the stored array. If a given frame
824+ contains a number of pixels that is not divisible by 8 exactly, a single byte
821825will straddle a frame boundary into the next frame if there is one, or the byte
822826will be padded with zeroes of there are no further frames. This means that
823- retrieving individual frames from segmentation images in which each frame
824- size is not divisible by 8 becomes problematic. No further compression may be
825- applied to frames of ``"BINARY" `` segmentation images.
827+ retrieving individual frames from segmentation images in which each frame size
828+ is not divisible by 8 becomes problematic. For this reason, as well as for
829+ space efficiency (sparse segmentations tend to compress very well), we
830+ therefore strongly recommend using ``"JPEG2000Lossless" `` compression with
831+ ``"BINARY" `` segmentations. This is the only compression method currently
832+ supported for ``"BINARY" `` segmentations. However, beware that reading these
833+ single-bit JPEG 2000 images may not be supported by all other tools and
834+ viewers.
826835
827836Pixels in ``"FRACTIONAL" `` segmentation images may be compressed using one of
828837the lossless compression methods available within DICOM. Currently *highdicom *
829838supports the following compressed transfer syntaxes when creating
830839``"FRACTIONAL" `` segmentation images: ``"RLELossless" ``,
831840``"JPEG2000Lossless" ``, and ``"JPEGLSLossless" ``.
832841
833- Note that there may be advantages to using ``"FRACTIONAL" `` segmentations to
834- store segmentation images that are binary in nature (i.e. only taking values 0
835- and 1):
836-
837- - If the segmentation is very simple or sparse, the lossless compression methods
838- available in ``"FRACTIONAL" `` images may be more effective than the
839- "bit-packing" method required by ``"BINARY" `` segmentations.
840- - The clear frame boundaries make retrieving individual frames from
841- ``"FRACTIONAL" `` image files possible.
842-
843842Multiprocessing
844843---------------
845844
0 commit comments