/*=========================================================================
-
+
Program: gdcm
Module: $RCSfile: gdcmPixelReadConvert.cxx,v $
Language: C++
- Date: $Date: 2005/06/30 14:50:05 $
- Version: $Revision: 1.73 $
+ Date: $Date: 2005/10/26 07:15:31 $
+ Version: $Revision: 1.90 $
Copyright (c) CREATIS (Centre de Recherche et d'Applications en Traitement de
l'Image). All rights reserved. See Doc/License.txt or
LutRedData = 0;
LutGreenData = 0;
LutBlueData = 0;
+ RLEInfo = 0;
+ JPEGInfo = 0;
+ UserFunction = 0;
+ FileInternal = 0;
}
/// Canonical Destructor
YSize = file->GetYSize();
ZSize = file->GetZSize();
SamplesPerPixel = file->GetSamplesPerPixel();
- PixelSize = file->GetPixelSize();
+ //PixelSize = file->GetPixelSize(); Useless
PixelSign = file->IsSignedPixelData();
SwapCode = file->GetSwapCode();
- std::string ts = file->GetTransferSyntax();
- IsRaw =
- ( ! file->IsDicomV3() )
- || Global::GetTS()->GetSpecialTransferSyntax(ts) == TS::ImplicitVRLittleEndian
- || Global::GetTS()->GetSpecialTransferSyntax(ts) == TS::ImplicitVRLittleEndianDLXGE
- || Global::GetTS()->GetSpecialTransferSyntax(ts) == TS::ExplicitVRLittleEndian
- || Global::GetTS()->GetSpecialTransferSyntax(ts) == TS::ExplicitVRBigEndian
- || Global::GetTS()->GetSpecialTransferSyntax(ts) == TS::DeflatedExplicitVRLittleEndian;
-
- IsMPEG = Global::GetTS()->IsMPEG(ts);
- IsJPEG2000 = Global::GetTS()->IsJPEG2000(ts);
- IsJPEGLS = Global::GetTS()->IsJPEGLS(ts);
- IsJPEGLossy = Global::GetTS()->IsJPEGLossy(ts);
- IsJPEGLossless = Global::GetTS()->IsJPEGLossless(ts);
- IsRLELossless = Global::GetTS()->IsRLELossless(ts);
+
+ if (! file->IsDicomV3() ) // Should be ACR-NEMA file
+ {
+ IsRaw = true;
+ // Don't loose time checking unexistant Transfer Syntax !
+ IsPrivateGETransferSyntax = IsMPEG
+ = IsJPEG2000 = IsJPEGLS = IsJPEGLossy
+ = IsJPEGLossless = IsRLELossless
+ = false;
+ }
+ else
+ {
+ std::string ts = file->GetTransferSyntax();
+
+
+// if ( ts == GDCM_UNKNOWN )
+// {
+// gdcmErrorMacro( "Could someone tell me how in the world could this happen !" );
+// -->
+//--> on ALL acr-nema images ! JPRx
+//-->
+// abort(); // DO NOT REMOVE. WE SHOULD NEVER READ SUCH IMAGE EVER (only gdcm can write such broekn dicom file)
+// }
+
+ IsRaw =
+ ( ! file->IsDicomV3() ) // Should be ACR-NEMA file
+ || Global::GetTS()->GetSpecialTransferSyntax(ts) == TS::ImplicitVRLittleEndian
+ || Global::GetTS()->GetSpecialTransferSyntax(ts) == TS::ImplicitVRBigEndianPrivateGE
+ || Global::GetTS()->GetSpecialTransferSyntax(ts) == TS::ExplicitVRLittleEndian
+ || Global::GetTS()->GetSpecialTransferSyntax(ts) == TS::ExplicitVRBigEndian
+ || Global::GetTS()->GetSpecialTransferSyntax(ts) == TS::DeflatedExplicitVRLittleEndian;
+
+ IsPrivateGETransferSyntax =
+ ( Global::GetTS()->GetSpecialTransferSyntax(ts) == TS::ImplicitVRBigEndianPrivateGE );
+
+ IsMPEG = Global::GetTS()->IsMPEG(ts);
+ IsJPEG2000 = Global::GetTS()->IsJPEG2000(ts);
+ IsJPEGLS = Global::GetTS()->IsJPEGLS(ts);
+ IsJPEGLossy = Global::GetTS()->IsJPEGLossy(ts);
+ IsJPEGLossless = Global::GetTS()->IsJPEGLossless(ts);
+ IsRLELossless = Global::GetTS()->IsRLELossless(ts);
+ }
PixelOffset = file->GetPixelOffset();
PixelDataLength = file->GetPixelAreaLength();
if ( HasLUT )
{
// Just in case some access to a File element requires disk access.
- LutRedDescriptor = file->GetEntryValue( 0x0028, 0x1101 );
- LutGreenDescriptor = file->GetEntryValue( 0x0028, 0x1102 );
- LutBlueDescriptor = file->GetEntryValue( 0x0028, 0x1103 );
+ LutRedDescriptor = file->GetEntryString( 0x0028, 0x1101 );
+ LutGreenDescriptor = file->GetEntryString( 0x0028, 0x1102 );
+ LutBlueDescriptor = file->GetEntryString( 0x0028, 0x1103 );
+ // The following comment is probabely meaningless, since LUT are *always*
+ // loaded at parsing time, whatever their length is.
+
// Depending on the value of Document::MAX_SIZE_LOAD_ELEMENT_VALUE
// [ refer to invocation of Document::SetMaxSizeLoadEntry() in
// Document::Document() ], the loading of the value (content) of a
// \TODO Reading a [Bin|Val]Entry directly from disk is a kludge.
// We should NOT bypass the [Bin|Val]Entry class. Instead
// an access to an UNLOADED content of a [Bin|Val]Entry occurence
- // (e.g. BinEntry::GetBinArea()) should force disk access from
+ // (e.g. DataEntry::GetBinArea()) should force disk access from
// within the [Bin|Val]Entry class itself. The only problem
// is that the [Bin|Val]Entry is unaware of the FILE* is was
// parsed from. Fix that. FIXME.
LutRedData = (uint8_t*)file->GetEntryBinArea( 0x0028, 0x1201 );
if ( ! LutRedData )
{
- gdcmWarningMacro( "Unable to read Red Palette Color Lookup Table data" );
+ gdcmWarningMacro("Unable to read Red Palette Color Lookup Table data");
}
// //// Green round:
LutGreenData = (uint8_t*)file->GetEntryBinArea(0x0028, 0x1202 );
if ( ! LutGreenData)
{
- gdcmWarningMacro( "Unable to read Green Palette Color Lookup Table data" );
+ gdcmWarningMacro("Unable to read Green Palette Color Lookup Table data");
}
// //// Blue round:
LutBlueData = (uint8_t*)file->GetEntryBinArea( 0x0028, 0x1203 );
if ( ! LutBlueData )
{
- gdcmWarningMacro( "Unable to read Blue Palette Color Lookup Table data" );
+ gdcmWarningMacro("Unable to read Blue Palette Color Lookup Table data");
}
}
+ FileInternal = file;
ComputeRawAndRGBSizes();
}
if ( PixelDataLength != RawSize )
{
gdcmWarningMacro( "Mismatch between PixelReadConvert : "
- << PixelDataLength << " and RawSize : " << RawSize );
+ << PixelDataLength << " and RawSize : " << RawSize );
}
if ( PixelDataLength > RawSize )
{
}
else if ( IsRLELossless )
{
- if ( ! RLEInfo->DecompressRLEFile( fp, Raw, XSize, YSize, ZSize, BitsAllocated ) )
+ if ( ! RLEInfo->DecompressRLEFile
+ ( fp, Raw, XSize, YSize, ZSize, BitsAllocated ) )
{
gdcmWarningMacro( "RLE decompressor failed." );
return false;
{
//gdcmWarningMacro( "Sorry, MPEG not yet taken into account" );
//return false;
- //ReadMPEGFile(fp, Raw, PixelDataLength); // fp has already been seek to start of mpeg
+ // fp has already been seek to start of mpeg
+ //ReadMPEGFile(fp, Raw, PixelDataLength);
return true;
}
else
ConvertReorderEndianity();
ConvertReArrangeBits();
ConvertFixGreyLevels();
+ if (UserFunction) // user is allowed to Mirror, TopDown, Rotate,...the image
+ UserFunction( Raw, FileInternal);
ConvertHandleColor();
return true;
}
/**
- * \brief Build Red/Green/Blue/Alpha LUT from File
- * when (0028,0004),Photometric Interpretation = [PALETTE COLOR ]
- * and (0028,1101),(0028,1102),(0028,1102)
- * - xxx Palette Color Lookup Table Descriptor - are found
- * and (0028,1201),(0028,1202),(0028,1202)
- * - xxx Palette Color Lookup Table Data - are found
+ * \brief Build Red/Green/Blue/Alpha LUT from File when :
+ * - (0028,0004) : Photometric Interpretation == [PALETTE COLOR ]
+ * and
+ * - (0028,1101),(0028,1102),(0028,1102)
+ * xxx Palette Color Lookup Table Descriptor are found
+ * and
+ * - (0028,1201),(0028,1202),(0028,1202)
+ * xxx Palette Color Lookup Table Data - are found
* \warning does NOT deal with :
- * 0028 1100 Gray Lookup Table Descriptor (Retired)
- * 0028 1221 Segmented Red Palette Color Lookup Table Data
- * 0028 1222 Segmented Green Palette Color Lookup Table Data
- * 0028 1223 Segmented Blue Palette Color Lookup Table Data
+ * - 0028 1100 Gray Lookup Table Descriptor (Retired)
+ * - 0028 1221 Segmented Red Palette Color Lookup Table Data
+ * - 0028 1222 Segmented Green Palette Color Lookup Table Data
+ * - 0028 1223 Segmented Blue Palette Color Lookup Table Data
* no known Dicom reader deals with them :-(
* @return a RGBA Lookup Table
*/
void PixelReadConvert::BuildLUTRGBA()
{
+
+ // Note to code reviewers :
+ // The problem is *much more* complicated, since a lot of manufacturers
+ // Don't follow the norm :
+ // have a look at David Clunie's remark at the end of this .cxx file.
if ( LutRGBA )
+
{
return;
}
a16 += 4;
}
/* Just to 'see' the LUT, at debug time
+// Don't remove this commented out code.
a16=(uint16_t*)LutRGBA;
for (int j=0;j<65536;j++)
void PixelReadConvert::ConvertSwapZone()
{
unsigned int i;
+ uint16_t localSwapCode = SwapCode;
+
+ // If this file is 'ImplicitVR BigEndian PrivateGE Transfer Syntax',
+ // then the header is in little endian format and the pixel data is in
+ // big endian format. When reading the header, GDCM has already established
+ // a byte swapping code suitable for this machine to read the
+ // header. In TS::ImplicitVRBigEndianPrivateGE, this code will need
+ // to be switched in order to read the pixel data. This must be
+ // done REGARDLESS of the processor endianess!
+ //
+ // Example: Assume we are on a little endian machine. When
+ // GDCM reads the header, the header will match the machine
+ // endianess and the swap code will be established as a no-op.
+ // When GDCM reaches the pixel data, it will need to switch the
+ // swap code to do big endian to little endian conversion.
+ //
+ // Now, assume we are on a big endian machine. When GDCM reads the
+ // header, the header will be recognized as a different endianess
+ // than the machine endianess, and a swap code will be established
+ // to convert from little endian to big endian. When GDCM readers
+ // the pixel data, the pixel data endianess will now match the
+ // machine endianess. But we currently have a swap code that
+ // converts from little endian to big endian. In this case, we
+ // need to switch the swap code to a no-op.
+ //
+ // Therefore, in either case, if the file is in
+ // 'ImplicitVR BigEndian PrivateGE Transfer Syntax', then GDCM needs to switch
+ // the byte swapping code when entering the pixel data.
+/* //Let me check something.
+ //I wait for the Dashboard !
+ if ( IsPrivateGETransferSyntax )
+ {
+ // PrivateGETransferSyntax only exists for 'true' Dicom images
+ // we assume there is no 'exotic' 32 bits endianess!
+ switch (localSwapCode)
+ {
+ case 1234:
+ localSwapCode = 4321;
+ break;
+ case 4321:
+ localSwapCode = 1234;
+ break;
+ }
+ }
+*/
if ( BitsAllocated == 16 )
{
uint16_t *im16 = (uint16_t*)Raw;
- switch( SwapCode )
+ switch( localSwapCode )
{
case 1234:
break;
uint16_t high;
uint16_t low;
uint32_t *im32 = (uint32_t*)Raw;
- switch ( SwapCode )
+ switch ( localSwapCode )
{
case 1234:
break;
// nmask : to propagate sign bit on negative values
int16_t nmask = (int16_t)0x8000;
nmask = nmask >> ( BitsAllocated - BitsStored - 1 );
-/*
-std::cout << "BitsStored " << BitsStored
- << " BitsAllocated " << BitsAllocated
- << std::endl;
-std::cout << std::hex << "pmask " << pmask
- << " smask " << smask
- << " nmask " << nmask
- << std::endl;
-*/
+
for(int i = 0; i<l; i++)
{
*deb = *deb >> (BitsStored - HighBitPosition - 1);
//-----------------------------------------------------------------------------
} // end namespace gdcm
-// NOTES on File internal calls
-// User
-// ---> GetImageData
-// ---> GetImageDataIntoVector
-// |---> GetImageDataIntoVectorRaw
-// | lut intervention
-// User
-// ---> GetImageDataRaw
-// ---> GetImageDataIntoVectorRaw
+// Note to developpers :
+// Here is a very detailled post from David Clunie, on the troubles caused
+// 'non standard' LUT and LUT description
+// We shall have to take it into accound in our code.
+// Some day ...
+
+/*
+Subject: Problem with VOI LUTs in Agfa and Fuji CR and GE DX images, was Re: VOI LUT issues
+Date: Sun, 06 Feb 2005 17:13:40 GMT
+From: David Clunie <dclunie@dclunie.com>
+Reply-To: dclunie@dclunie.com
+Newsgroups: comp.protocols.dicom
+References: <1107553502.040221.189550@o13g2000cwo.googlegroups.com>
+
+> THE LUT that comes with [my] image claims to be 16-bit, but none of the
+> values goes higher than 4095. That being said, though, none of my
+> original pixel values goes higher than that, either. I have read
+> elsewhere on this group that when that happens you are supposed to
+> adjust the LUT. Can someone be more specific? There was a thread from
+> 2002 where Marco and David were mentioning doing precisely that.
+>
+> Thanks
+>
+> -carlos rodriguez
+
+
+You have encountered the well known "we know what the standard says but
+we are going to ignore it and do what we have been doing for almost
+a decade regardless" CR vendor bug. Agfa started this, but they are not
+the only vendor doing this now; GE and Fuji may have joined the club.
+
+Sadly, one needs to look at the LUT Data, figure out what the maximum
+value actually encoded is, and find the next highest power of 2 (e.g.
+212 in this case), to figure out what the range of the data is
+supposed to be. I have assumed that if the maximum value in the LUT
+data is less than a power of 2 minus 1 (e.g. 0xebc) then the intent
+of the vendor was not to use the maximum available grayscale range
+of the display (e.g. the maximum is 0xfff in this case). An alternative
+would be to scale to the actual maximum rather than a power of two.
+
+Very irritating, and in theory not totally reliable if one really
+intended the full 16 bits and only used, say 15, but that is extremely
+unlikely since everything would be too dark, and this heuristic
+seems to work OK.
+
+There has never been anything in the standard that describes having
+to go through these convolutions. Since the only value in the
+standard that describes the bit depth of the LUT values is LUT
+Descriptor value 3 and that is (usually) always required to be
+either 8 or 16, it mystifies me how the creators' of these images
+imagine that the receiver is going to divine the range that is intended. Further, the standard is quite explicit that this 3rd
+value defines the range of LUT values, but as far as I am aware, all
+the vendors are ignoring the standard and indeed sending a third value
+of 16 in all cases.
+
+This problem is not confined to CR, and is also seen with DX products.
+
+Typically I have seen:
+
+- Agfa CR, which usually (always ?) sends LUTs, values up to 0x0fff
+- Fuji CR, which occasionally send LUTs, values up to 0x03ff
+- GE DX, for presentation, which always have LUTs, up to 0x3fff
+
+Swissray, Siemens, Philips, Canon and Kodak never seem to send VOI LUTs
+at this point (which is a whole other problem). Note that the presence
+or absence of a VOI LUT as opposed to window values may be configurable
+on the modality in some cases, and I have just looked at what I happen
+to have received from a myriad of sites over whose configuration I have
+no control. This may be why the majority of Fuji images have no VOI LUTs,
+but a few do (or it may be the Siemens system that these Fuji images went
+through that perhaps added it). I do have some test Hologic DX images that
+are not from a clinical site that do actually get this right (a value
+of 12 for the third value and a max of 0xfff).
+
+Since almost every vendor that I have encountered that encodes LUTs
+makes this mistake, perhaps it is time to amend the standard to warn
+implementor's of receivers and/or sanction this bad behavior. We have
+talked about this in the past in WG 6 but so far everyone has been
+reluctant to write into the standard such a comment. Maybe it is time
+to try again, since if one is not aware of this problem, one cannot
+effectively implement display using VOI LUTs, and there is a vast
+installed base to contend with.
+
+I did not check presentation states, in which VOI LUTs could also be
+encountered, for the prevalence of this mistake, nor did I look at the
+encoding of Modality LUT's, which are unusual. Nor did I check digital
+mammography images. I would be interested to hear from anyone who has.
+
+David
+
+PS. The following older thread in this newsgroup discusses this:
+
+"http://groups-beta.google.com/group/comp.protocols.dicom/browse_frm/t hread/6a033444802a35fc/0f0a9a1e35c1468e?q=voi+lut&_done=%2Fgroup%2Fcom p.protocols.dicom%2Fsearch%3Fgroup%3Dcomp.protocols.dicom%26q%3Dvoi+lu t%26qt_g%3D1%26searchnow%3DSearch+this+group%26&_doneTitle=Back+to+Sea rch&&d#0f0a9a1e35c1468e"
+
+PPS. From a historical perspective, the following may be of interest.
+
+In the original standard in 1993, all that was said about this was a
+reference to the corresponding such where Modality LUTs are described
+that said:
+
+"The third value specifies the number of bits for each entry in the
+LUT Data. It shall take the value 8 or 16. The LUT Data shall be stored
+in a format equivalent to 8 or 16 bits allocated and high bit equal
+1-bits allocated."
+
+Since the high bit hint was not apparently explicit enough, a very
+early CP, CP 15 (submitted by Agfa as it happens), replaced this with:
+
+"The third value conveys the range of LUT entry values. It shall take
+the value 8 or 16, corresponding with the LUT entry value range of
+256 or 65536.
+
+Note: The third value is not required for describing the
+ LUT data and is only included for informational usage
+ and for maintaining compatibility with ACRNEMA 2.0.
+
+The LUT Data contains the LUT entry values."
+
+That is how it read in the 1996, 1998 and 1999 editions.
+
+By the 2000 edition, Supplement 33 that introduced presentation states
+extensively reworked this entire section and tried to explain this in
+different words:
+
+"The output range is from 0 to 2^n-1 where n is the third value of LUT
+Descriptor. This range is always unsigned."
+
+and also added a note to spell out what the output range meant in the
+VOI LUT section:
+
+"9. The output of the Window Center/Width or VOI LUT transformation
+is either implicitly scaled to the full range of the display device
+if there is no succeeding transformation defined, or implicitly scaled
+to the full input range of the succeeding transformation step (such as
+the Presentation LUT), if present. See C.11.6.1."
+
+It still reads this way in the 2004 edition.
+
+Note that LUTs in other applications than the general VOI LUT allow for
+values other than 8 or 16 in the third value of LUT descriptor to permit
+ranges other than 0 to 255 or 65535.
+
+In addition, the DX Image Module specializes the VOI LUT
+attributes as follows, in PS 3.3 section C.8.11.3.1.5 (added in Sup 32):
+
+"The third value specifies the number of bits for each entry in the LUT
+Data (analogous to ìbits storedî). It shall be between 10-16. The LUT
+Data shall be stored in a format equivalent to 16 ìbits allocatedî and
+ìhigh bitî equal to ìbits storedî - 1. The third value conveys the range
+of LUT entry values. These unsigned LUT entry values shall range between
+0 and 2^n-1, where n is the third value of the LUT Descriptor."
+
+So in the case of the GE DX for presentation images, the third value of
+LUT descriptor is allowed to be and probably should be 14 rather than 16.
+
+*/