Today I downloaded Adobe's latest DNG converter. It is failing with both .NEF and .CR2 files when run in command-line mode. It does appear to work in GUI mode. The switches+arguments I've used for my tests are:
-u -e -p1 filename.CR2
With an older (CS2) version of the converter, the above arguments produce a .DNG output file as expected (with .CR2 files; I didn't try it with D3 .NEF files; surely that older version doesn't support the D3's format).
With the very latest version, running the program with the above command produces no output. There's no error message.
The 'readme' file that comes with the converter doesn't include any information about command-line usage, but I did find a PDF file covering this (adobe.com/products/dng/pdfs/dng_commandline.pdf). The switches+arguments shown in the PDF file appear to be exactly the ones I used in the past.
I'm sure I'll need to use the most recent version to convert D3 RAW files. Is there something wrong with how I'm specifying its command-line switches/arguments?
"I verified that I am in fact passing the fully qualified path. But, oddly, the app fails silently if I pass _any_ parameter (even -p1) between the EXE name and the source file path. Something must be wrong.
> I neglected to mention that I'm using WinXP--what platform are you on? I ask because the Windows executible is just called "Adobe DNG Converter.exe"--no version.
> I saw your earlier message on processing a folder full of NEF files and that you've considered using a for loop to accomplish this. I can get the converter to launch by pointing at a folder and not individual files, and the converter parses the entire contents of the folder and subfolders (provided you've checked the box). I still have to hit the "convert" button, though.
I'm using XP SP2. I tried a miminalist converter command just now (again, this would normally be on a single line):
think I know what's wrong: If I open a command prompt (not using a script this time), navigate to the directory that the converter is in, and type:
C:\UTIL> "Adobe DNG Converter.exe" -c
...it won't launch. Same with any parameter. If I omit the parameters and pass a source path, it's fine. This happens with -p1 or -d, as well--all of the supported parameters.
Right. Using "-c" alone causes the program simply to terminate. I tried it with some non-supported switches, such as "-a" and "-b" -- with nothing else on the command line -- and that launched the app in its GUI mode.
I write a ton of command-line tools for use in-house at work, and I do have opinions about these things. 🙂 The use of a non-supported switch should cause the app to print usage information (it has none that I know of, though). At the least, for it to open its main window in some of these cases is a clear enough signal that you didn't give it a correctly formed command line. Its doing
nothing when "-c" alone appears on the command line...methinks that qualifies as a bug. The same thing seems to happen if you use any of its supported command-line switches as the sole arguments: the program simply closes with nary a whimper. Other (equally nonsensical) command-line arguments cause it to open its main window.
It struck me silly that I've been running tests with v.3.3 when 5.2 is the latest, so I downloaded it. The setup "wizard"...hmm, why is it a "wizard"? It provides no choice of installation path. I didn't realize this because immediately after I'd launched it, I knocked something onto the floor, reached down to pick it up ... and looked back up just in time to see the "wizard" complete the installation...but where, I didn't know. It didn't display any information about where it had installed the app. Adventures In Discoverability. 🙂 I hunted around on the hard drive until I found it (C:\Program Files\Adobe -- well, at least you can launch it if you think to look for it in the 'Start' menu). So ... that needs a bit of work. Anyway, I copied the app into a directory of my choice -- one that's in my system's %PATH%, replacing spaces in the name with underscores. It works fine in that directory -- no problem with the name-change as far as I can tell. Now back to the fun stuff...
This version doesn't seem to require a fully qualified path to the input file or to the output directory when "-d" is used. That's an improvement. IOW, this worked:
converter -p1 -d DNG filename
where "converter" is the program's name, "DNG" is the name of a subdirectory of the directory where I'm running the test, and "filename" is the name of a RAW file in that directory.
The program still doesn't know how to create a directory (or ask about creating one if it doesn't exist). Fails silently if "-d" is used and the specified directory doesn't exist. But at least this version returns an exit code of 1 due to the failure -- better than returning 0.
Still doesn't understand wildcards. Hope done sprang eternal there for a moment, but oh well. Back to "for" loops...
Still fails silently, returning exit code 0 (oops), if a nonsensical command-line is used (e.g., using "-c" as the only argument).
Hey, how about a truly silly command-line error -- a command line including both "-c" and "-u". What happens? It "consumes" the first of the two mutually exclusive switches, ignoring the second -- you get a compressed DNG file. Swap the order of the switches, and you get an uncompressed file. (I'd vote for a syntax-error message in that case, m'self.)
Interestingly strange little program...If I run it from the command line, it drops back to the command line immediately after I press ENTER. That makes it appear to have failed. But it hasn't -- it's running in the background, and a few seconds later the DNG file is created. But, if I run it from within a batch file, it does NOT return control to me until it has completed writing the output file. Wonder what's up with that.
Back in my application development days, it was glaring obvious when a command
line geek wrote a GUI app and when a GUI geek wrote a command line app. This was
especially true in Unix-land where there are defacto standards for stuff like
error messages and exit codes.
> But what is the big deal about running the DNG converter in command line mode?
The question is not quite precise, so I'll give you two answers.
1) It's a big deal (big problem) because it doesn't follow the conventions used
by the vast majority of command line programs.
2) ACR is not scriptable in any meaningful sense (unless you open docs in PS and
toss your performance out the window), where as DNG converter kinda-sorta is, at
least for the task of converting raw files to DNG files, which is a big deal for
those of us who like to construct highly automated work flows.
The question is not quite precise, so I'll give you two answers.
What you said. 🙂 I place a high value on reliable automated processes; it's what I do at work all day long. With converter 5.2 not supporting wildcards, I'm beginning to wonder if I should resurrect my little project to create a command-line wrapper for the thing, "faking" batch processing. Figuring out a way to ensure that the app is visible to/discoverable by the "wrapper" script on every possible machine would be a challenge -- likewise, devising a CLI that'd work for just about everyone wanting to use such a tool.
> With converter 5.2 not supporting wildcards, I'm beginning to wonder if I should resurrect my little project to create a command-line wrapper for the thing, "faking" batch processing.
shortcomings of various CLI apps, include the DNG Converter.
> Figuring out a way to ensure that the app is visible to/discoverable by the "wrapper" script on every possible machine would be a challenge
You would have to make it a configuration setting. Prior to this last release,
there was no standard installation folder for the converter. And a lot of people
move it to their desktop anyway as a drop target.
> likewise, devising a CLI that'd work for just about everyone wanting to use such a tool.
I've thought about implementing one, but I'd end up scripting in Bash. My
primary platform is a Mac Pro and I have cygwin installed on WinXP and Vista.