Program: gdcm
Module: $RCSfile: gdcmPixelReadConvert.cxx,v $
Language: C++
- Date: $Date: 2005/07/30 18:27:00 $
- Version: $Revision: 1.75 $
+ Date: $Date: 2005/11/28 16:50:32 $
+ Version: $Revision: 1.105 $
Copyright (c) CREATIS (Centre de Recherche et d'Applications en Traitement de
l'Image). All rights reserved. See Doc/License.txt or
namespace gdcm
{
-//bool ReadMPEGFile (std::ifstream *fp, void *image_buffer, size_t lenght);
+//bool ReadMPEGFile (std::ifstream *fp, char *inputdata, size_t lenght);
bool gdcm_read_JPEG2000_file (void* raw,
char *inputdata, size_t inputlength);
//-----------------------------------------------------------------------------
//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);
+
+ IsPrivateGETransferSyntax = IsMPEG
+ = IsJPEG2000 = IsJPEGLS = IsJPEGLossy
+ = IsJPEGLossless = IsRLELossless
+ = false;
+
+ if (! file->IsDicomV3() ) // Should be ACR-NEMA file
+ {
+ IsRaw = true;
+ }
+ else
+ {
+ std::string ts = file->GetTransferSyntax();
+
+ IsRaw = false;
+ while (true) // short to write than if elseif elseif elseif ...
+ {
+ // mind the order : check the most usual first.
+ if( IsRaw = Global::GetTS()->GetSpecialTransferSyntax(ts) == TS::ExplicitVRLittleEndian) break;
+ if( IsRaw = Global::GetTS()->GetSpecialTransferSyntax(ts) == TS::ImplicitVRLittleEndian ) break;
+ if( IsRaw = Global::GetTS()->GetSpecialTransferSyntax(ts) == TS::ExplicitVRBigEndian) break;
+ if( IsRaw = Global::GetTS()->GetSpecialTransferSyntax(ts) == TS::ImplicitVRBigEndianPrivateGE) break;
+ if( IsRaw = Global::GetTS()->GetSpecialTransferSyntax(ts) == TS::DeflatedExplicitVRLittleEndian) break;
+ break;
+ }
+ // cache whether this is a strange GE transfer syntax (which uses
+ // a little endian transfer syntax for the header and a big endian
+ // transfer syntax for the pixel data).
+ IsPrivateGETransferSyntax =
+ ( Global::GetTS()->GetSpecialTransferSyntax(ts) == TS::ImplicitVRBigEndianPrivateGE );
+
+ IsMPEG = IsJPEG2000 = IsJPEGLS = IsJPEGLossy = IsJPEGLossless = IsRLELossless = false;
+ if (!IsRaw)
+ {
+ while(true)
+ {
+ // mind the order : check the most usual first.
+ if( IsJPEGLossy = Global::GetTS()->IsJPEGLossy(ts) ) break;
+ if( IsJPEGLossless = Global::GetTS()->IsJPEGLossless(ts) ) break;
+ if( IsRLELossless = Global::GetTS()->IsRLELossless(ts) ) break;
+ if( IsJPEG2000 = Global::GetTS()->IsJPEG2000(ts) ) break;
+ if( IsMPEG = Global::GetTS()->IsMPEG(ts) ) break;
+ if( IsJPEGLS = Global::GetTS()->IsJPEGLS(ts) ) break;
+ gdcmWarningMacro("Unexpected Transfer Syntax :[" << ts << "]");
+ break;
+ }
+ }
+ }
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 );
+ // FIXME : 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;
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;
// fp has already been seek to start of mpeg
- //ReadMPEGFile(fp, Raw, PixelDataLength);
+ //ReadMPEGFile(fp, (char*)Raw, PixelDataLength);
return true;
}
else
// Default case concerns JPEG family
if ( ! ReadAndDecompressJPEGFile( fp ) )
{
- gdcmWarningMacro( "JPEG decompressor failed." );
+ gdcmWarningMacro( "JPEG decompressor ( ReadAndDecompressJPEGFile()"
+ << " method ) failed." );
return false;
}
}
ConvertReorderEndianity();
ConvertReArrangeBits();
ConvertFixGreyLevels();
- if (UserFunction) // user is allowed to Mirror, TopDown, Rotate, .. the image
+ if (UserFunction) // user is allowed to Mirror, TopDown, Rotate,...the image
UserFunction( Raw, FileInternal);
ConvertHandleColor();
return false;
}
- gdcmWarningMacro( "--> BuildRGBImage" );
+ gdcmDebugMacro( "--> BuildRGBImage" );
// Build RGB Pixels
AllocateRGB();
return true;
}
// wow what happen, must be an error
+ gdcmWarningMacro( "gdcm_read_JPEG2000_file() failed ");
return false;
}
else if ( IsJPEGLS )
}
/**
- * \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;
}
gdcmWarningMacro( "Wrong Blue LUT descriptor" );
}
- gdcmWarningMacro(" lengthR " << lengthR << " debR "
- << debR << " nbitsR " << nbitsR);
- gdcmWarningMacro(" lengthG " << lengthG << " debG "
- << debG << " nbitsG " << nbitsG);
- gdcmWarningMacro(" lengthB " << lengthB << " debB "
- << debB << " nbitsB " << nbitsB);
+ gdcmDebugMacro(" lengthR " << lengthR << " debR "
+ << debR << " nbitsR " << nbitsR);
+ gdcmDebugMacro(" lengthG " << lengthG << " debG "
+ << debG << " nbitsG " << nbitsG);
+ gdcmDebugMacro(" lengthB " << lengthB << " debB "
+ << debB << " nbitsB " << nbitsB);
if ( !lengthR ) // if = 2^16, this shall be 0 see : CP-143
lengthR=65536;
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;
-
+
+ // 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.
+
+ int tempSwapCode = SwapCode;
+ if ( IsPrivateGETransferSyntax )
+ {
+ gdcmWarningMacro(" IsPrivateGETransferSyntax found; turn the SwapCode");
+ // PrivateGETransferSyntax only exists for 'true' Dicom images
+ // we assume there is no 'exotic' 32 bits endianess!
+ if (SwapCode == 1234)
+ {
+ tempSwapCode = 4321;
+ }
+ else if (SwapCode == 4321)
+ {
+ tempSwapCode = 1234;
+ }
+ }
+
if ( BitsAllocated == 16 )
{
uint16_t *im16 = (uint16_t*)Raw;
- switch( SwapCode )
+ switch( tempSwapCode )
{
case 1234:
break;
}
break;
default:
- gdcmWarningMacro("SwapCode value (16 bits) not allowed.");
+ gdcmWarningMacro("SwapCode value (16 bits) not allowed."
+ << tempSwapCode);
}
}
else if ( BitsAllocated == 32 )
uint16_t high;
uint16_t low;
uint32_t *im32 = (uint32_t*)Raw;
- switch ( SwapCode )
+ switch ( tempSwapCode )
{
case 1234:
break;
}
break;
default:
- gdcmWarningMacro("SwapCode value (32 bits) not allowed." );
+ gdcmWarningMacro("SwapCode value (32 bits) not allowed." << tempSwapCode );
}
}
}
// 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);
// - [Planar 1] AND [Photo C] handled with ConvertYcBcRPlanesToRGBPixels()
// - [Planar 2] OR [Photo D] requires LUT intervention.
- gdcmWarningMacro("--> ConvertHandleColor"
- << "Planar Configuration " << PlanarConfiguration );
+ gdcmDebugMacro("--> ConvertHandleColor "
+ << "Planar Configuration " << PlanarConfiguration );
if ( ! IsRawRGB() )
{
// [Planar 2] OR [Photo D]: LUT intervention done outside
- gdcmWarningMacro("--> RawRGB : LUT intervention done outside");
+ gdcmDebugMacro("--> RawRGB : LUT intervention done outside");
return;
}
if ( IsYBRFull )
{
// [Planar 1] AND [Photo C] (remember YBR_FULL_422 acts as RGB)
- gdcmWarningMacro("--> YBRFull");
+ gdcmDebugMacro("--> YBRFull");
ConvertYcBcRPlanesToRGBPixels();
}
else
{
// [Planar 1] AND [Photo C]
- gdcmWarningMacro("--> YBRFull");
+ gdcmDebugMacro("--> YBRFull");
ConvertRGBPlanesToRGBPixels();
}
return;
if (IsRLELossless)
{
- gdcmWarningMacro("--> RLE Lossless");
+ gdcmDebugMacro("--> RLE Lossless");
ConvertRGBPlanesToRGBPixels();
}
//-----------------------------------------------------------------------------
} // 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.
+
+*/