(registered 2016-07-01, last updated 2016-07-01) Name: David Clunie Email: dclunie&dclunie.com Media type name: image Media subtype name: jls Required parameters: N/A Optional parameters: N/A Encoding considerations: binary N/A Security considerations: JPEG-LS utilizes a marker segment structure to store image data and metadata about this image data. The segments defined in the JPEG-LS standard are of a descriptive nature and provide information useful for viewing, rendering and cataloging of images by a recipient. As such, the fields currently defined in the JPEG-LS standard do not in themselves create security risks beyond the information disclosed, since the fields are not used to induce any particular behavior by the recipient application. The marker segment syntax is extensible structure, so that it is theoretically possible that metadata fields could be defined in the future which could be used to induce particular actions on the part of the recipient, thus presenting additional security risks, but this type of capability is currently not supported in the referenced JPEG-LS standard. The media type does not provide any privacy or integrity services, so, if needed these may be provided externally, e.g., through the use of TLS or Cryptographic Message Syntax (CMS). This media type employs compression, so users are warned that decompression may lead to significant increase in the size of the data. Interoperability considerations: JPEG-LS allows for encoding of images with one or more components and a variety of bit depths as well as in lossless and near-lossless modes. This media type does not specify restrictions beyond those specified in ISO/IEC 14495-1 (ITU T.87), so recipients may expect that some image types (e.g., those with more than 8 bits per component) might not be directly renderable without further processing. ISO/IEC 14495-1 (ITU T.87) does not specify or require the use of a JFIF header (APP0 marker segment as described in ISO/IEC 10918-5 (ITU-T T.871, ECMA TR/98)), and recipients should not expect that one is present. In the absence of a JFIF header, there is no mechanism to specify the color space of a multi-component image. Published specification: The baseline encoding of lossless and near-lossless images encoded with JPEG-LS is fully specified in ISO/IEC 14495-1 (ITU T.87). Applications which use this media: Though JPEG-LS is generally applicable to any type or natural or artificial color or monochrome images, it is primarily used in the medical field, particularly to encode the encapsulated pixel data of DICOM images. In this role it may be used for single or multi-frame images, but does not take advantage of any inter-frame correlation (i.e., is a still image compression mechanism). When pixel data of a single is extracted from its DICOM encapsulated representation, the compressed bit stream conforms to the JPEG-LS standard and it is highly desirable that such extracted data be made available using web services and identified with a standard media type that is recognized by non-medical (consumer) applications, such as web browsers, in much the same way, for example, as baseline JPEG (ISO/IEC 10918-1) is identified by the image/jpeg media type. Note that even though JPEG-LS is a product of ISO/IEC JTC1/SC29/WG1 and as such is part of the JPEG "family" of standards, just as JPEG 2000 is, like JPEG 2000, which has a media type assigned of image/jp2 [RFC3745], JPEG-LS needs its own media type. Fragment identifier considerations: JPEG-LS encodes single frame rasterized pixel data that is encoded in a compressed bit stream that is not fragmented and is decoded starting at the beginning of the bit stream. As such, no media type specific fragment identifier or fragment semantics are defined. In particularly no mechanism to selectively locate positions or sub-regions within an image is defined. Restrictions on usage: Payment free licensing of patents claimed to be of relevance for the implementation of JPEG-LS are discussed in Annex I of ISO/IEC 14495-1. Provisional registration? (standards tree only): image/jls Additional information: 1. Deprecated alias names for this type: image/x.jls 2. Magic number(s): N/A 3. File extension(s): jls 4. Macintosh file type code: 'jls ' 5. Object Identifiers: N/A General Comments: Person to contact for further information: 1. Name: David Clunie 2. Email: dclunie&dclunie.com Intended usage: Common Common Author/Change controller: DICOM Standards Committee dicom&medicalimaging.org