I am trying to read the DICOM files from a Philips Gemini PET/CT scanner, but the function dicomread gives me the following error:

??? Error using ==> dicomread>newDicomread at 241
Unsupported data encoding.
Error in ==> dicomread at 81
[X, map, alpha, overlays] = newDicomread(msgname, frames);

The function dicominfo works fine, and I can see that the TransferSyntaxUID is 1.3.46.670589.33.1.4.1.

I've tried to apply the fix suggested in http://www.mathworks.com/matlabcentral/newsreader/view_thread/298483, even though it is a different TransferSyntaxUID, but it didn't work.

I can provide samples of the DICOM files if needed.

I hope someone can help. 

"Jonas Hermansen" <jonas.s.hermansen@gmail.com> wrote in message <imv6f5$to$1@fred.mathworks.com>...
> I am trying to read the DICOM files from a Philips Gemini PET/CT scanner, but the function dicomread gives me the following error:
> 
> ??? Error using ==> dicomread>newDicomread at 241
> Unsupported data encoding.
> Error in ==> dicomread at 81
> [X, map, alpha, overlays] = newDicomread(msgname, frames);
> 
> The function dicominfo works fine, and I can see that the TransferSyntaxUID is 1.3.46.670589.33.1.4.1.
> 
> I've tried to apply the fix suggested in http://www.mathworks.com/matlabcentral/newsreader/view_thread/298483, even though it is a different TransferSyntaxUID, but it didn't work.
> 
> I can provide samples of the DICOM files if needed.
> 
> I hope someone can help. 

Jonas sent me a couple of image-less files that contain the transfer syntax, which is a private Philips explicit little-endian syntax (for anyone who cares about such things).  Because it's private, there's technically nothing incorrect with how DICOMREAD is behaving; all readers have the option to reject transfer syntaxes that they don't know about, including all private transfer syntaxes.  But that's not very satisfying, I know.

If the resolution is more difficult than simply adding the private transfer syntax UID to the first block of UIDs in DICOMREAD's getTxfrSyntaxDetails() function, then it might be something that takes a while to fully support.  Philips hasn't documented the details of this private transfer syntax as far as I can tell, and I don't have full confidence that treating it exactly the same as the default explicit little-endian transfer syntax is correct.

I'll keep y'all posted once I hear back that this does or does not allow DICOMREAD to import the images correctly.

Jeff Mather
Image Processing Group
MathWorks

p.s. - For the curious, the block of code in dicomread.m that I referred to above would look like this.  (This may or may not work.)

        case {'1.2.840.10008.1.2'
              '1.2.840.10008.1.2.1'
              '1.2.840.10008.1.2.2'
              '1.2.840.113619.5.2'
              '1.3.46.670589.33.1.4.1'}

            details.EncodingSupported = true;
            details.DataCompressed = false;
            details.DecompressFcn = internalErrorFcn;
            details.RequiresColorspaceConversion = true;

"Jeff Mather" <jeff.mather@mathworks.com> wrote in message <in2lnr$cqj$1@fred.mathworks.com>...
> "Jonas Hermansen" <jonas.s.hermansen@gmail.com> wrote in message <imv6f5$to$1@fred.mathworks.com>...
> > I am trying to read the DICOM files from a Philips Gemini PET/CT scanner, but the function dicomread gives me the following error:
> > 
> > ??? Error using ==> dicomread>newDicomread at 241
> > Unsupported data encoding.
> > Error in ==> dicomread at 81
> > [X, map, alpha, overlays] = newDicomread(msgname, frames);
> > 
> > The function dicominfo works fine, and I can see that the TransferSyntaxUID is 1.3.46.670589.33.1.4.1.
> > 
> > I've tried to apply the fix suggested in http://www.mathworks.com/matlabcentral/newsreader/view_thread/298483, even though it is a different TransferSyntaxUID, but it didn't work.
> > 
> > I can provide samples of the DICOM files if needed.
> > 
> > I hope someone can help. 
> 
> Jonas sent me a couple of image-less files that contain the transfer syntax, which is a private Philips explicit little-endian syntax (for anyone who cares about such things).  Because it's private, there's technically nothing incorrect with how DICOMREAD is behaving; all readers have the option to reject transfer syntaxes that they don't know about, including all private transfer syntaxes.  But that's not very satisfying, I know.
> 
> If the resolution is more difficult than simply adding the private transfer syntax UID to the first block of UIDs in DICOMREAD's getTxfrSyntaxDetails() function, then it might be something that takes a while to fully support.  Philips hasn't documented the details of this private transfer syntax as far as I can tell, and I don't have full confidence that treating it exactly the same as the default explicit little-endian transfer syntax is correct.
> 
> I'll keep y'all posted once I hear back that this does or does not allow DICOMREAD to import the images correctly.
> 
> Jeff Mather
> Image Processing Group
> MathWorks
> 
> p.s. - For the curious, the block of code in dicomread.m that I referred to above would look like this.  (This may or may not work.)
> 
>         case {'1.2.840.10008.1.2'
>               '1.2.840.10008.1.2.1'
>               '1.2.840.10008.1.2.2'
>               '1.2.840.113619.5.2'
>               '1.3.46.670589.33.1.4.1'}
> 
>             details.EncodingSupported = true;
>             details.DataCompressed = false;
>             details.DecompressFcn = internalErrorFcn;
>             details.RequiresColorspaceConversion = true;


Hi 
I have the same problem with the philips ingenuity PETMR system which uses the gemini PET component and has the same UID when reading the DICOM info. Have you found any solution to the problem that i am not aware of?

Dear Jeff, 

Though this thread has being inactive for a while, I was wondering if there is something new about the above-mentioned issue.

I'm trying to import some PET/CT data from a Philips Gemini equipment with negative result. I've already gone through your previous suggestions (TransferSyntaxUID and 'deblank'); and what I eventually get is an empty matrix as dicomread output.

I've been playing around for a while and it seems to me that when calling the subfunction      
                data = getAttributeData(attrs, allGroups, allElements, ...
                              dictionary(p), swapAttrBytes);
the 'idx' value cannot be assigned because there is no positive match between the dictionaryEntry.Group and the dictionaryEntry.Element, so the 'idx' var remains empty and the program runs to
                  data = dictionaryEntry.Default
instead of  
                  data = getData(attrs(idx), dictionaryEntry, swapAttrBytes);

I wonder if there's a simple solution to this problem by updating the newMiniDictionary or similar.

Thank you in advance and greetings from beautiful Seville!

the same error message I get when I try to read CD written by GE machine (ultrasound) from the station of Impax 'Agfa

convert the files on the CD with dicomwork exporting the same files on another cd written by dicomwork in iso format and DICOM standard

the message does not appear and the files are read correctly

best regards 

francesco loiodice

radiology pediatric 
bari
italy