Some users find that they get poor quality text, lines etc. when printing images to DICOM printers, especially when printing intrinsically small images, such as 256x256 MRIs or PET images.

This happens because DICOM only allows such annotations to be “burnt-in” to the pixel data, and the annotations cannot be sent directly to the printer as text (this is a DICOM rule, and is not unique to DicomObjects). Therefore, DicomObjects puts labels onto the image using the “Pixel grid” of the image itself, and the printer then scales that to match the space available. Moreover, in order to keep printed out text the same size, DicomObjects scales the font to match the size of the image.

So for a 512 x 512 images, a reasonably sized text label (18 pt) text is about 10 pixels high – this is easily readable. For a 256x256 image however, the text height is only about 5 pixels – that is not legible. Note that both sets of text will print out the same size due to printer scaling, but they will be different resolution - hence the problem.

The only solution is the scale up the image itself before printing (by a factor you choose, called “Zoom” in the code below), to give the text renderer a finer grid to “draw on”. The alternatives are:

• Use SubImage to make a larger copy and then print that conventionally – like this:

   
  BigImage = OriginalImage.SubImage(0,0,image.SizeX*Zoom, image.SizeY*Zoom, Zoom, 1)
  ' ... add labels to BigImage
  PrintObject.PrintImage(BigImage,False,True)

• You could use PrinterImage to do the scaling up immediately prior to the printing, using that to do all the work (scaling, windowing and drawing annotations in one go!) then sending the resulting pre-prepared image to the PrintImage method, setting the “raw” property to true to prevent a second use of PrinterImage internally.

 	
  OriginalImage BigImage = OriginalImage.PrinterImage(Bits, Planes, True, Zoom, 0, 0, 0, 0)
  ' ... add Labels to BigImage
  PrintObject.PrintImage(BigImage,True,True)	

• Bits and Planes are matched to the printer (normally 8 or 12 for Bits and 1 or 3 for Planes, depending on whether the images are monochrome or colour)
• This is actually more efficient, but the difference is probably not great !

The value of Zoom needs to be chosen empirically, so that the final size approximates ot the true resolution of the printer - setting it too high will make unreasonably large images which will take a long time to send to the printer and may overload its memory, but a value too low will not cure the resolution problem. It would be sensible to make it an integer. The value may in fact need to be greater than 4, and the best way to experiment is to make copies using the PrinterImage method and put them into a DicomViewer with StretchMode set to NoStretch, then inspect the results by scrolling around the image.

A side effect of these changes is that interpolation (smoothing) is now done by DicomObjects as well as or instead of by the printer (which does not need to scale the image up as much), so there might be some change in the appearance of the image, but this is unavoidable….DicomObjects cannot add fine annotations to a coarse grid!