DICOM @ OFFIS

Hi,

I cannot see this from the snippet you provided (One guess: don't you have to allocate and free the "buffer" yourself?). But the best way to solve this yourself is to write a minimal test program and to throw into a memory checker like valgrind.

Best regards,
Michael

Ah, of course, my mistake, of course Planar Configuration is not permitted if Samples Per Pixel = 1 but Samples per Pixel is required anyway Sry

Mh, this is trial and error then. Invent values for Rescale Slope (1) and Intercept (0), if it does not help then maybe values for Window Center and Window Width, ... i.e. try fixing pixel related attributes that are reported by dciodvfy. Also, if dcmj2pnm prints warnings, fix those problems first. ...

After a first look, I would remove Samples Per Pixel from the dataset, the value 2 is never used in any color model. Probably the machine "means" 1 (one color=grayscale channel) instead. Just remove Samples Per Pixel, e.g. by calling dcmodify -e SamplesPerPixel <input_file> Just curious: T...

Hi,

as far as I can see this error is only produced in case of serious problems, e.g. Planar Configuration is not present in the dataset, memory is exhausted or no pixel data is present.

Probably you should check the image with a DICOM validator, e.g. dciodvfy.

BR, Michael

Hm, this sounds like a weird problem. Using a DCMTK tool to re-write the file (dcmconv, or dcmcjpeg+dcmdjpeg, or dcmscale) should rule out any simple encoding errors (like odd length) already. Maybe you need to talk to the vendor support of the target location or get better logs from the server. BR,...

Nope, good idea, I never used dcmscale myself actually

Hey Jörg, the issue was not whether it is appropriate or not but that it might be reason that the PACS does not digest it. Also OP noted that the PACS only supports LEE and JPEG Baseline. Cmerrick: You understood correctly, I dont have any other tool in mind. But, since Jörg brought this up, I also ...

Hi, yes the OW/OB issues points at some unusual pixel data setup used. You can try the following to fix it: Use dcmcjpeg <input_file> <output_file> to create JPEG lossless, and then dcmdjpeg <output_file> <result_file> to decompress it again (thus not loosing quality). IIRC DCMTK will then use only ...

Hi, setting quality factor to 100 will not make JPEG Baseline lossless. Probably it's better to fix the source image. Also maybe the problem in the image is just disguised by applying JPEG Baseline transfer syntax, so you might store "garbage" to your PACS as well. Does dcmcjpeg gives some...

P.S: Well, I tried this and actually in dcmodify this does not work (loads fully into memory instead). Anyway, maybe Jörg or Marco know the best way to handle your problem.

Hi, unfortunately there is no such class in DCMTK. However, I think you could use DcmElement::createValueFromTempFile() in order to insert pixel data from a pixel data file stored on disk. This means you would write all your pixel data to disk in the format that it will later have inside the Pixel D...

Hi,

no, there is no specific IOD for this task. In DICOM there is so far: Encapsulated PDF, Enc. CDA, Enc. STL, Enc. OBJ and Enc. MTL. The only way to encapsulate a ZIP file would be private data, and/or using the Raw Data IOD.

Best regards,
Michael

As Jörg said, it is all "said" in dcm2pnm. By including diregist.h support of color images is automatically enabled. The API calls stay the same as without diregist.h.

You only have to follow the lines dcm2pnm::905 ff.

Hi Jingkun,

some general info how to insert private data can be found in our Howtos: https://support.dcmtk.org/redmine/proje ... rivateData

Best regards,
Michael