The title says it all. What is the difference between dcm2pnm (http://support.dcmtk.org/docs/dcm2pnm.html), dcmj2pnm (http://support.dcmtk.org/docs/dcmj2pnm.html) and dcml2pnm (http://support.dcmtk.org/docs/dcml2pnm.html) commands of dcmtk toolkit (http://support.dcmtk.org/docs/pages.html)? They all seem to convert dicom images to other formats. Are there any special situations where one should be preferred over others?
Edit: It seems dcml2pnm supports more formats. Why not use that for all purposes? What are the advantages of other commands?
I am the DCMTK developer.
The difference between the three DCMTK command line tools is: support for compressed DICOM images and output formats.
dcm2pnm was the original tool that has been developed more than 20 years ago and which originally only supported the image format PNM/PGM for output (that's also why the tool is called "dcm2pnm" and not "dcm2img" or the like). And, because at that time the DCMTK did not support any encapsulated transfer syntaxes (i.e. compression), only uncompressed DICOM images can be read.
dcmj2pnm is located in DCMTK's submodule "dcmjpeg" and adds support for JPEG-compressed DICOM images (based on the IJG library) as well as the JPEG image format for output.
dcml2pnm is located in DCMTK's submodule "dcmjpls" and adds support for JPEG-LS-compressed DICOM images (based on the CharLS library). It does not support conventional JPEG.
All this is probably more obvious from the source code package than from the binary package but it is also mentioned in the above referenced documentation (see "Description" section).
If you'd ask why there are three different tools (in fact, there is also a fourth one for JPEG-2000 support but that not part of the public DCMTK), my answer would be: this is mainly for historical reasons but also for reason of keeping dependencies between the various DCMTK modules as simple as possible.
Furthermore, we consider the command line tools as a kind of sample applications of the underlying C++ class library. So, if you'd need a tool that supports all image compression schemes available in the DCMTK, it should be easy to write such a tool.
dcmj2pnm adds JPEG codecs to the dcm2pnm functionality. Thus, it is capable of handling JPEG compressed DICOM data and produce JPEG output images. So it is a superset of dcm2pnm's functionality.
I think this is, because dcmtk offers different compile options which allow to include / exclude libjpeg. Just reflects the toolkit's options to the accompanying command line tools. Confirmed by the list of file formats when you start with option -h
For dcml2pnm I am not sure, but this is a good guess: Same as for JPEG but includes the JPEG-LS encoder which is another optional 3rd party toolkit for dcmtk.
Related
I am using Ghostscript to convert pdf1.3 to pdf/a-1b using this command:
gs -dPDFA -dBATCH -dNOPAUSE -dNOOUTERSAVE -sColorConversionStrategy=sRGB -sDEVICE=pdfwrite -sOutputFile=output.pdf PDFA_def.ps input.pdf
The PDFA_def.ps is customized to use the srgb icc profile. Except that change it is the standard def file which comes with GS 9.26.
Now comes the tricky part:
1- running this conversion locally on a ubuntu 18.10, GS 9.26 it works fine an i get a valid pdf/a
2- running the same command in a docker container (ubuntu 18.10. GS 9.26) creates a pdf/a as well, which is considered to be valid
However, in the first scenario I can process the file using mustang (https://github.com/ZUGFeRD/mustangproject) to create a valid electronic invoice. In the second scenario (docker container) this fails, since the file is not considered to be valid pdf by mustang.
checking both pdf files I would have expected them to be identical since i am running the same converison on it. However they are not. The PDF create in the dockerfile is 10 bytes smaller and shows some different metainformation in the file itself.
I suspect that there must be some "hidden depdencies" that make GS to act different on my host system compared to a docker container, but it feels entirely wrong and I am running out of means to debug further.
Does anyone know, wether GS has some more depdencies that might cause the same command to produce different results?
The answer is 'maybe'. It depends on how Ghostscript was built for starters.
I assume you are using a package, and not building from source yourself. In which case there are a number of dependencies including; FreeType, LibJPEG, JBIG2dec, LibTIFF, JPEG-XR, LCMS2, LibPNG, OpenJPEG, Expat, zlib, potentially IJS, CUPS and X-Windows, depending on what devices were built in.
Any or all of these could be system shared libraries instead of being built using the specific version shipped by Artifex. They could also be different versions on the two systems.
That said, I think its 'unlikely' that this is your problem. However, without seeing the PDF files I can't tell you why there is a difference. Differences in the metadata are to be expected, since that includes a date/time stamp.
I'd really need to see examples of the original and the two output PDF files to be able to comment further.
[Edit]
Looking at the files they have been produced compressed (unsurprisingly) which can obviously lead to differences in size if there are small differences in the input streams. So the first task was to decompress the files.
That done I see there are, essentially, no differences between them. One of the operating systems is using a time zone 7 hours behind UTC, the other is in UTC so where one of the systems is time stamping with (eg)
2019-04-26T19:49:01Z
The other is using
2019-04-26T12:51:35-07:00
So instead of Z (for UTC) you get -07:00 which is where the extra 10 bytes are coming from. Other than that, the Unique IDs are (as you would imagine) different, the Length values for the streams are different for the streams containing dates, and the startxref is different because the streams are different lengths.
Both files claim to be compatible with PDF/A-1b. In short I can see no real differences between them. Since you are using a tool to further process the files, I'd suggest you try taking the PDF file from your working system and try processing it on the non-working system, and vice versa, it seems to me that the problem may be the later processing rather than the PDF file itself. Perhaps you have different versions of that tool on the two systems.
For what it may be worth, Ghostscript can be induced into creating a ZUGFeRD file directly, see this bug report and this commit to the repository.
When I was learning Portable Executable (PE) file format for windows, tools like PE-Explorer and PEView helped me in learning things quickly and nicely. Now, I need to learn and understand the apple quick time file format. Are there any
Tools with which I can browse the quick time format?
Export sections of the file?
Any additional resources other than the specifications?
PS: I'm on windows and I don't have mac/macOS
Tools with which I can browse the quick time format?
On Windows you can use MP4 Explorer, and since it is open source you can also learn from it. Since MP4 uses a similar structure to QuickTime you can use it for both.
There is also the old Dumpster tool from Apple. There is an old version of this tool for Windows, but I could not find it in the Apple developer site. This forum post has a copy that you can try. This is very old though, I'm not sure if it'll work with recent QT files.
If you can obtain access to a Mac running OS X, then you can use Dumpster or Atom Explorer.
Export sections of the file?
I don't know of any public tool for this. Your best bet is to extend MP4 Explorer to do this, or write your own parser. Parsing the atoms is actually pretty simple, things start to get complicated when you need to interpret the content of the atoms and cross-reference them to, for example, locate where the frame data is.
Any additional resources other than the specifications?
The QuickTime file format specification is the best resource for Apple generated QuickTime files, but you may need to do some reverse engineering, as the spec is not very complete in some areas, like the handling of MPEG-2 and MPEG-4 video. If you have access to ISO specs, then ISO/IEC 14496-12 is a standardized version of the QuickTime format (or better said, of a subset of it). The ISO/IEC 14496-15 specification builds on top of 14496-12 and defines a specific implementation of this format for the H.264 format. This is the so called MP4 format.
With the above three documents you should be pretty good in terms of documentation.
The MPEG4 (.MP4) file format is based on the QuickTime file format. You should be able to use the MPEG4IP tools to examine .MOV files. You can find windows binaries here.
Media Box Viewer does exactly this and much more. In addition to Quicktime, it can also open mp4, 3gp, etc. It runs on all platforms, Windows, Mac, Linux, etc.
It can be downloaded from www.jdxsoftware.org.
Is there any way to convert odt documents to doc or rtf on linux without openoffice or any library that relies on having openoffice installed ?
OpenOffice.org and its derivatives (LibreOffice, Symphony, etc) currently have one of the best converters between ODF and the Microsoft formats (besides the ODF support built into MS Office).
If those converters are not an option for you, you can choose between some alternatives: Foremost you might want to check out the KOffice project which also offers command line tools for file conversion:
KOffice - File Filters
Then there is another open source project with a free BSD license available on SourceForge:
OpenXML/ODF Translator
This project offers not only add-ins for Microsoft Office, but also a stand-alone command line version which also runs on Linux.
Then there would also be a different approach: You can automate Google Docs using command line tools:
googlecl: Command line tools for the Google Data APIs
Google Docs file conversion have internally been based on the OpenOffice.org file filters, but as far as I know they have been replaced by Aspose, a library for document formats.
Aspose is available in several versions, and as you have a Linux dependency you might want to check out their Java version.
Aspose.Words for Java
The library has its price, but you won't find another library that is not a full office suite with that quality.
If you don't want to use OpenOffice, Google Docs is your best bet. Cross-platform, web-based, and free, it takes about 2 minutes. You would upload the file, and check convert, then redownload as a doc or pdf (depends on what you want).
http://docs.google.com/
You could try this freeware (Docx2Rtf) and run it under WINE.
Checkout unoconv. It relies on OpenOffice.org its core, but it doesn't rely on any GUI packages. I assume this is what you want?
Use http://zamzar.com/ It has great support for all those formats. And is not reliant on any other installed program.
And of course, being a web page, it will work on any OS.
I am using ImageMagick from Commandline in .Net? Although a .Net wrapper (ImageMagick.Net in codeplex) is available but it is still in alpha and does not have implementation for all the command line options e.g Distort, Montage. Therefore I am using System.Diagnostics.Process class to invoke the ImageMagick command line.
What are the Pros/Con of this approach? I can see a performance issue if I have to perform multiple transformation on the same image and if I invoke the command twice then the commandline will load the Image twice. Is there a way I can chain the commands so that output of the first transformation is feed into the second command?
It will definitely be slower, and when you chain commands, you are going to be encoding and decoding the image into a format unnecessarily -- if you do this, make sure you use a lossless format like PNG for intermediate formats. To speed it up, use one without compression.
Two other choices
Use ImageMagick.NET and then wrap anything else you need from imagemagick yourself, probably by contributing to the project
My company, Atalasoft, has a free .NET imaging SDK with a lot of overlap with ImageMagick. You can download here: http://atalasoft.com/photofree -- Montage is basically the same as our Overlay commands and Distort is a 2D transformation, which are all included. If ImageMagick.NET can accept and produce .NET Bitmap objects, then you can use both together fairly easily.
Creating a ruby on rails site that uses RMagick to create thumbnails for many types of images. RMagick cannot read dwg files however.
I've tried a few things, looked into the Java library JDWGLib, which would probably allow me to write a converter, but it would be a total from the ground up solution, where I just need a thumbnail.
Also considered using a viewer program to open the file in a remote X session and do a screen capture, however I'm not sure how I could ever guarantee that the viewer had completed opening when I took the screenshot.
I'm not concerned with being able to manipulate the file other than to create the thumbnail. It is going to be used for commercial purposes, so any libraries used need to be compatible.
cad2svg is a simple Linux command-line utility that automatically converts AutoCAD files (both dwg and dxf) to SVG.
the link
I could not find any command-line-able tool for making thumbnails, on either windows or linux.
I guess you could download the DWGdirect lib (C++) wich allows the exportation of a DWG to a bitmap... but this requires purchasing a membership license on the """Open""" Design Aliance.
I would recommend adding an additional file input on your form that says "thumbnail". And let the users provide the screenshots.