Is there anyone from Adobe who might have the time to respond to this question? Given the command-line switches and arguments shown in the previous message, does it look as if I am giving the commands incorrectly?

> Macintosh or Windows? What command line shell are you using?

I'm running the converter under Windows XP service pack 2.

After seeing your reply I realized I had not tried running the program in a cmd.exe console window -- I'd been using only the 4NT version 5 command shell (meaning JP Software's command shell product 4nt.exe). For this latest attempt, I used both shells. The arguments/switches were:

-u -e -p1 -o _MG_0972.CR2 _MG_0972.dng

This time I added an explicit switch/arg for the output file to see if that would make any difference.

Result in both the cmd.exe shell and the 4NT shell:

I got output with the DNG converter that was released at about the time Photoshop CS2 was released, but no output with the one I downloaded most recently from Adobe's web site.

Variations: 1) omitted "-o filename" -- same results. 2) omitted "-o" and used "*.cr2" for the input filename; in that case neither converter version produced output; 3) omitted "-o" and used ".\" for the input file, in case the converter would accept that for "all raw files in the current directory" -- again neither converter version produced any output.

> "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):

C:\PhotoshopCS2\DNG_converter\version_3.3\Adobe_DNG_Converter_3.3.exe -p1 filename.cr2

(I renamed it to get rid of the spaces in the name -- gets around the need to double-quote the command.)

This did write an output file. Hmm...I don't know why it wouldn't be working when you have "-p1" between the executable's name and the input file's name.

I've been able to process a directory's-worth of RAW files via the GUI, but not with the command line -- unless I use a loop to do it. The program doesn't seem to support wildcards.

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.

Fun stuff. :)

> 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.

>> 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.

Yep. So it'd be: 1) insist upon having it in the %path%. Nice, but not an entirely realistic expectation. A lot of people don't know what the %path% is, let alone how to edit it. Sad. :) 2) Insist upon having its location be stored in some environment variable. Not friendly; failure-prone; kludge-y. 3) Insist upon having its location stored in some config file. Ok...so where's the config file? %systemroot%? %systemroot%\system32? Etc. etc.

> 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.

The one I use here is a 4NT script (the command processor being shipped nowadays as "TakeCommand"). Better I should re-do it in Perl. 4NT scripting is great, but the Perl solution, though it wouldn't have all the pretty colors, would be way more robust.

Hmm. Tiny light went on. I wonder if recent versions of ExifTool can write DNG. I think that app can read DNG. Whether it can write it (with or without the bells and whistles of Adobe's converter), I don't know. Worth checking out. Then all you have to do is learn yet more about the ExifTool command line. EEEEK! :) (Insanely great tool with a long learning curve, that one.)

... a moment later ... well, so it can. I'll have to mess with it a bit...