DICOM SOP Classes Visible Light for Microscopy and Visible Light for
Microscopy for Slide Coordinates can be used for images of cells,
proteins, etc. However there are some issues and limitations with these
SOP classes

The above formats assume a single large matrix of pixels for the image.
Many of the vendors who are scanning slide images, especially full
slide images, are generating digital image formats with a
multi-resolution, hierarchical representation of the pixel data. While
DICOM allows the pixel data to be compressed with JPEG2000 which
internal to the compressed data "black box"can use a hierarchical,
multi-resolution representation of the data, that data represenation is
not externalized in the dicom header metadata. Thus, you could not use
the information in the dicom metadata to address into the pixel data to
extract a subset of the slide image data at a particular matrix
coordinate and resolution level -- as is done with DICOM multi-frame
formats

The DICOM multiframe scheme will not support different pixel resolution
or sizing over the frames of a multiframe object. Digital slide
scanning vendors/pathology pacs vendors recently approached the dicom
standard committee about developing a multiframe data model which
supports multiple pixel resolutions over the frames. The work item was
turned down, largely because it is viewed as a presentation technology
issue rather than an intervendor interchange issue. It is being argued
that the DICOM work items to support JPEG2000 and JPIP interchanges
will support multi-resolution pixel data exchange without building a
multi-resolution multiframe object

I disagree with my colleagues on the dicom standard committee on this
point. For one thing, there are some limitations in terms of addressing
ranges in single image matrices. Very high resolution, full slide
images will exceed those limits. Multiframe resolutions are able to
work around those limits by breaking the large pixel matrix into small
pieces. Second, the scanning devices need to be able to communicate the
image objects they're generating to external PACS systems.

It would be of interest to understand where you're coming from on your
request. When there is enough demand from device and pacs vendors, I
believe the dicom standard will reverse the prior decision not to
support the requirements

While working with WG17 on the multi-dimensional framework, I
evaluated the applications with some individuals in this specialty.
Some applications have demanding requirements. Images may have
two or three spatial dimensions; multi-spectral components;
and temporal phases.

As Eric points out, the current DICOM standard is too limited
for most applications and there has been little if any adoption.
(The multi-frame approach he refers was designed for MRI and
is not a good candidate for the classs biomicroscopy applications).

"Clemens" wrote in message
news:1110891640.910651.30440@l41g2000cwc.googlegro ups.com...
> Does anybody know if it is allowed / possible to use the DICOM standard
> for images of cells, proteins or even smaller items. Or is there
> already a kind of DICOM dialect for the above mentioned images. Or is
> there some other standard for storing these images?
> I would be gratefull if somebody could help me.
>

Assuming you refer to multi-resolution storage approach for the purpose
of panning or zooming large 2D images, that is a compression syntax issue,
motivated by presentation for human interpretation and usabilty.
Given that some images have multiple spectral components and may have
more than just two dimensions, it is not clear that JPIP is adequate.

wrote in message
news:1110904220.211119.265840@l41g2000cwc.googlegr oups.com...
> DICOM SOP Classes Visible Light for Microscopy and Visible Light for
> Microscopy for Slide Coordinates can be used for images of cells,
> proteins, etc. However there are some issues and limitations with these
> SOP classes
>
> The above formats assume a single large matrix of pixels for the image.
> Many of the vendors who are scanning slide images, especially full
> slide images, are generating digital image formats with a
> multi-resolution, hierarchical representation of the pixel data. While
> DICOM allows the pixel data to be compressed with JPEG2000 which
> internal to the compressed data "black box"can use a hierarchical,
> multi-resolution representation of the data, that data represenation is
> not externalized in the dicom header metadata. Thus, you could not use
> the information in the dicom metadata to address into the pixel data to
> extract a subset of the slide image data at a particular matrix
> coordinate and resolution level -- as is done with DICOM multi-frame
> formats
>
> The DICOM multiframe scheme will not support different pixel resolution
> or sizing over the frames of a multiframe object. Digital slide
> scanning vendors/pathology pacs vendors recently approached the dicom
> standard committee about developing a multiframe data model which
> supports multiple pixel resolutions over the frames. The work item was
> turned down, largely because it is viewed as a presentation technology
> issue rather than an intervendor interchange issue. It is being argued
> that the DICOM work items to support JPEG2000 and JPIP interchanges
> will support multi-resolution pixel data exchange without building a
> multi-resolution multiframe object
>
> I disagree with my colleagues on the dicom standard committee on this
> point. For one thing, there are some limitations in terms of addressing
> ranges in single image matrices. Very high resolution, full slide
> images will exceed those limits. Multiframe resolutions are able to
> work around those limits by breaking the large pixel matrix into small
> pieces. Second, the scanning devices need to be able to communicate the
> image objects they're generating to external PACS systems.
>
> It would be of interest to understand where you're coming from on your
> request. When there is enough demand from device and pacs vendors, I
> believe the dicom standard will reverse the prior decision not to
> support the requirements
>

Thanks for your reaction and information.
We investigate the possibility to be able to use some kind of standard
for 'images' with a wide range of detail. From light microscopy for
cells down to the atomic level with x-ray diffraction, 1mm to 0.1nm.
See our project description, www.cyttron.org
Because DICOM combines the metadata and the actual image data with each
other, it might be a good candidate. The RAW data from the different
acquisition instruments are no DICOM data (so far we know), so we need
to convert the RAW data towards a DICOM like image before we can
present it.
Our goal is to be able to present the data of the different instruments
in a uniform way using a uniform image format, probably DICOM, but if
you have suggestions for another format please let me know.
So our goal is quit different from the normal uses of DICOM. For now we
don't want to store the images or obtain them from a PACS; we mainly
want to use it as an intermediate format to present images.
The project goes beyond the bio-microscopy and enters the chemistry
world, this might also a problem to DICOM, it is not possible to
determine, for instance, the patient of the molecule shown in the
image. From our point of view it would be nice to have a modality
without some modules, which are mandatory to all modalities at the
moment.
Please let me know if you have suggestion how we might implement this.

If the desire is merely to represent a 'for presentation' RGB image
then that is possible using DICOM "secondary capture."

Depending on the requirements, consider another approach.
Your applications suggest data fusion from various acquisition modalities
as well as fusing structural or functional information to the image.

There is a new DICOM infrastructure (not yet standard) is designed
to meet such requirements. Assuming there was interest in using this,
interested parties could collaborate to create a full DICOM specification
to meet the requirements of your applications.

However, if your interest is purely in a data format rather than leveraging
DICOM clinical products then the motivation to use DICOM may
not make sense.

I can't think of any other options of the top of my head, however I
vaguely recall about some initiative that proposed developing some
sort of biomedical imaging standard about 4 years ago.

"Clemens" wrote in message
news:1110963529.278728.246210@g14g2000cwa.googlegr oups.com...
> Thanks for your reaction and information.
> We investigate the possibility to be able to use some kind of standard
> for 'images' with a wide range of detail. From light microscopy for
> cells down to the atomic level with x-ray diffraction, 1mm to 0.1nm.
> See our project description, www.cyttron.org
> Because DICOM combines the metadata and the actual image data with each
> other, it might be a good candidate. The RAW data from the different
> acquisition instruments are no DICOM data (so far we know), so we need
> to convert the RAW data towards a DICOM like image before we can
> present it.
> Our goal is to be able to present the data of the different instruments
> in a uniform way using a uniform image format, probably DICOM, but if
> you have suggestions for another format please let me know.
> So our goal is quit different from the normal uses of DICOM. For now we
> don't want to store the images or obtain them from a PACS; we mainly
> want to use it as an intermediate format to present images.
> The project goes beyond the bio-microscopy and enters the chemistry
> world, this might also a problem to DICOM, it is not possible to
> determine, for instance, the patient of the molecule shown in the
> image. From our point of view it would be nice to have a modality
> without some modules, which are mandatory to all modalities at the
> moment.
> Please let me know if you have suggestion how we might implement this.
>