I need some command-line tool to create dds (dxt5 format) from two .png files -- one with rgb channels and one with alpha. It's because I have a waste amount of images to process -- I can't do it manually. It's no problem for me to create script for generating batch file to process all images one by one, but I need tool to create dds from two png-s.
Anyone known such command-line tool ?
Thanks.
P.S. nvDXT.exe is very good but it can't combine rgb and alpha from different files.
If you have Photoshop, you could always use Batch Script (see Batch Scripting Tutorial for an example) to merge the channels (with NVidea plug in installed, you could probably even do the DDS conversion too). Just a thought.
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.
Hi I have 430 files i need to analyse which are in a folder tree
The plugin i am using is this one: http://dev.mri.cnrs.fr/projects/imagej-macros/wiki/Intensity_Ratio_Nuclei_Cytoplasm_Tool
the files before being analysed need to be converted to 16 bit greyscale image, then a specific threshold applied on some of them (all have the same file start name eg, DAPI.tif, DAPI 2.tif)
Then each DAPI X.tif turned into a mask and analysed using the plugin is analysed with two other files (TRITC X.tif and FITC X.tif) then the results saved.
What is the best way to do this, as it would take me several hours to do this manually?
Btw I am a beginner when it comes to imageJ so detailed instructions would be useful.
Thanks guys
Please take a look at this page of the ImageJ wiki:
https://imagej.net/Batch
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.
I am assembling image sequences, each sequence consisting of 1-5K png images. Each sequence is then subject to a large number of image manipulations. These manipulations are identical for each image, though may be slightly different from sequence to sequence. I wish to automate this whole operation. I can automate all the image manipulations using tools I have (PaintShop Photo Pro, IrfanView32, among others). The problem I have is automating the first step - the assembly of the images initially.
The images are produced from a tool, written in Java. There is no access to the source for this tool. In addition the tool was written in a GUI style derived in the Unix world. The implications of this are that normal Windows shortcuts are not necessarily recognised by the tool (eg Alt-F for the file menu; some buttons do not have shortcuts; etc). The tool provides two windows - a control window and an image window.
The sequence of actions I need to carry out to derive the images is as follows:
Initial steps (no automation needed).
Run tool
Load an initialisation file from the control window
Use the image window to setup the image full screen at the required magnification
Load a log file from the control window (format not available outside the tool)
The repetitive steps are:
Press a button in the image window to generate the image
Enter a file name in the resultant dialog box. This file name will need to have a root applicable to the sequence plus a unique increasing number (5 digit in string form) specific to the image.
Press a button in the control window to advance the log file
One final twist - the only way of determining the end of the sequence is that the tool indicates the end of log file by disabling the button on the control window. There is no other indication of EOF readily available.
My first thought was to use Microsoft's Powershell, but my limited understanding of that tool suggests that the Unix/Windows/GUI incompatibilites and the lack of availability of the java objects, precludes this approach.
My environment is Windows 7 Ultimate 64; development tools available to me are Delphi XE, 2006, 7; there are a number of other languages installed (Java, Python, Haskell).
What approaches and/or tools will enable me to automate this task. As a sole developer, my preference is for free or cheap tools.
AutoHotkey is a powerful tool which can fit your needs.
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.