Computers in the darkroom

[jhultquist]

I've created a software based darkroom timer that uses a PC and a little extra hardware to automate several functions of darkroom enlarging. (Like note taking, test strips, resetting the timer for each part of an exposure, etc.)

I originally created the program just for my use but I have now decided to market the package of hardware and software and I was hoping to get a lot of input from other darkroom photographers who might be willing to help me test the software. More information about the program and a download link for the beta version of the software an be found at: www.pachydermdarkroom.com.

Because this is APUG, I would like to note that I am a darkroom photographer and the vast majority of my work is black and white. (see www.jhld.com) Programming is currently a hobby.

I would really appreciate any of you taking the time to review the software and offer your comments, insights, and of course tell me about any bugs you might find.

Thanks,
Jim

 

[Kino]

Interesting. Is this strictly for b&w? If not, how will you handle the screen blanking AND allow functionality?

 

[Alex Bishop-Thorpe]

From a programming standpoint this is pretty interesting stuff in itself, but with the screen filters, are they sealed around the edges? Would a Mac version be possible? Looking at all the old iBooks going on eBay these days (with those huge 15GB harddrives), it might be good for those of us without notebook PC's on hand. This is definately an interesting project though.

 

[jhultquist]

Re: Color Work - I think it could work for color with a few modifications. I have never printed color before so I would need to understand what additions would be needed to make it work. Blanking the screen is easy to do so that is not a problem. I wouild just need to know when you want the screen blanked out.

Re: Screen Filter - The Screen filter consists of a heavy mat board cut to the dimensions of your screen with a red filter (Rosco 26 Gel) over the viewing area. The screen filter is attached to a black felt backing that creates a light-tight sleave that fits over a lap top screen. I have been using this in my darkroom for some time without any fogging issues.

Re: Mac - I plan on making a Mac version after I get the current package off the ground.

Would either of you be interested in being a beta tester?

 

[roteague]

Would a Mac version be possible?

It is extremely difficult to port a program from on platform to another.

 

[Bob Carnie]

Jim I am going away for a couple of weeks but I am very keen on this idea.
I work with multiple enlargers, on any given day, 4condensor omegas, 8x10 and 11x14 deveere, 2 diffusion . All these are withing 25 feet of each other.
as well I want to de automate a Jobo system but still be able to store up to 15 film developer combinations and their times.

Ques.
-Is it possible to hub all these to the one computer with seperate start buttons on each individual enlarger. or do I have to run back and forth from a central computer to start each enlarger?
-can your system hold split filter , multiple exposure data?
-can this system work with other types of systems, like nuarc exposing systems and a modified Jobo?

I would be very interested in your thoughts on this as it sounds like an amazing idea that is worth persuing.

 

[Photo Engineer]

At Kodak, our darkroom monitors were B&W green on black with a dim illumination. No color or white was allowed. Other than that, we never developed a good method for screening the illumination.

Most computers were in a separate workroom outside of the darkroom. They were connected to the green screen monitor in the DR by cables and process control could be effected from either station.

PE

 

[Bob F.]

I've been using a laptop with a filter over the screen for B&W for a couple of years. Works well. The major advantage to using a laptop comes if you integrate it with hardware to drive the enlarger and safelights etc as is the intention here. My current enlarger does not really work with external timers as it has its own so I just use this software.

Random observations: One point about the website: I'm finding the red text on a dark grey background very difficult to read. 200 USD does not sound too expensive for the hardware. Your description of the screen filter sounds like exactly what I have done (drat - should have patented it! ). I would want to know that any hardware is optically (or otherwise) physically isolated from my PC's electronics before I plugged it in. Does it run from an external low voltage power supply or is mains voltage fed to the box?

Porting to a Mac depends on the language used: Java = easy, Visual BASIC .NET = serious pain...

Cheers, Bob.

 

[roteague]

Porting to a Mac depends on the language used: Java = easy, Visual BASIC .NET = serious pain...

Microsoft used to sell a program, Visual C++, which would make programs for both Mac and Windows. But, the program wasn't updated (and no longer supported); there really isn't much call for cross-platform applications.

I agree with your assessment. Java is relatively easy, but doesn't work well on Windows. ANSI C++ is better, but the learning curve is a bit long. VB.NET - I wouldn't even attempt it.

 

[jhultquist]

Thanks for your responses let me try to answer all the questions:

"-Is it possible to hub all these to the one computer with seperate start buttons on each individual enlarger. or do I have to run back and forth from a central computer to start each enlarger?"

This has come up recently and it is possible to run several enlargers off of one software package. Several interface boxes (which is a USB controlled relay) can be connected to a single computer using multiple USB ports or a USB splitter. The software will need to be modified a bit.

"can your system hold split filter , multiple exposure data?"

The system is designed for multiple exposures. Every single photograph can have several steps (say one for the base exposure, another for the a burn, etc.) Each step is stored in a list and as one time is complete, the next time is loaded into the active timer. Download the software (at Dead Link Removed) and play it for a bit and let me know if it meets your needs.

can this system work with other types of systems, like nuarc exposing systems and a modified Jobo?

I am not familiar with these systems (I am self taught photographer with a home darkroom). I'll need to do further research to answer this question.

"Does it run from an external low voltage power supply or is mains voltage fed to the box?"

The enlarger interface uses a USB port, and the electronics within the box are powered from the USB port. The electronics signal then triggers the relay which passes current from the wall outlet to the enlarger. The high and low voltage is isolated at the relay.

 

[Photo Engineer]

If you interface with any hardware, you need an interface card with switching hardware such as digital and analog converters. You also need a driver that will allow any program to connect to the hardware device controller.

A good method is to use a Burr Brown board with A to D and D to A converters and etc... There is a DLL for Windows and Mac that will allow use of this controller to turn things on or off, turn intensity up or down and etc.

PE

 

[Kino]

Would either of you be interested in being a beta tester?

Well, I have Linux on my laptop; I might be able to get it to work under Wine or another emulator, but thats touchy.

Thanks for the offer, though!

Frank

 

[donbga]

It is extremely difficult to port a program from on platform to another.

Not if you write it in Perl/Python.

 

[Photo Engineer]

If you wish to control hardware directly from a multitasking OS, you need a piece of software that runs at the Kernel level or level zero. This can communicate with the program and hardware both without violating protection.

You also should not try to control hardware from scripting type languages or interpreted languages such as HTML, XML or Java. Perl falls into that class as well IIRC.

Burr Brown offers their boards with software drivers for all major OSs including Windows, OSX, Linux, Unix and QNX as well.

PE

 

[Bob F.]

Robert, I just realised I sounded annoyingly pedantic (again)... Sorry - I meant that if this uses Visual Studio.NET as I suspected, it would indeed be a pig to port to the Mac as I can't think of any language other than Java that will port without a more or less complete re-write of the user interface and it didn't look like Java from the screen shots.

Speaking of which... Jim, I just tried it and it wants me to install .NET 1.1 before it will install but I already have 2.0 installed (I would have had earlier versions but this particular machine is a new install as of 4 days ago). There is no problem with having V1.1 and V2.0 apps running on the same PC but it is a pain to toddle off and find 1.1 and install it.

Perhaps a re-compile under V2.0 might be on the cards at some point - or check MS's forward compatibility lists and if there are no issues, allow it to run under 2.0. Also helpful would be to include a version of the required framework in the install package which should save a lot of end-user confusion. One of the (many) annoying things about MS is the way they keep changing things (often for no apparent good reason) and trying to keep up with them is a full time occupation in itself!

Writing windows (or even Linux) kernel level drivers is strictly for the gurus (or at least, it used to be - not looked at it for a few years). It's far easier to use existing facilities such as multiple USB ports or a serial port for which drivers are already installed. IrDA is another option which has the advantage of total isolation between the PC and external hardware (but the disadvantage of being line of sight and only a 1 to 2 metre range).

I'm currently doing some paid work writing for an Atmel microcontroller - a whole 8 kilobytes of memory... Bliss compared to writing for a PC - the compiler (gcc) works without fuss and the Atmel AVR has a nice clean architecture (did someone mention Pic? )...

Cheers, Bob.

 

[donbga]

If you wish to control hardware directly from a multitasking OS, you need a piece of software that runs at the Kernel level or level zero. This can communicate with the program and hardware both without violating protection.

You also should not try to control hardware from scripting type languages or interpreted languages such as HTML, XML or Java. Perl falls into that class as well IIRC.

Burr Brown offers their boards with software drivers for all major OSs including Windows, OSX, Linux, Unix and QNX as well.

PE

To make a long answer short PERL can do anything and unfortunately is erroneously thought of as just a scripting language. It can easily be used with other modules written in middle level and low level languages such as C, C++, Java, or even assembler.

Pick your poison!

 

[roteague]

Robert, I just realised I sounded annoyingly pedantic (again)... Sorry - I meant that if this uses Visual Studio.NET as I suspected, it would indeed be a pig to port to the Mac as I can't think of any language other than Java that will port without a more or less complete re-write of the user interface and it didn't look like Java from the screen shots.

No worries Bob. I understood what you were trying to get to, and didn't take it any other way. You are correct in your statements, as far as I know. The version of Visual Studio that supported the Mac was 4.1 (a long time ago).

Generally, accessing a USB device would require a device driver (which would normally be written in C/C++ - assembler in the old days). Device drivers are about the only thing I haven't written for Windows, but I rarely write low level programs anymore - these days, I mostly write VB.NET.

 

[Photo Engineer]

Guys;

Just FYI, for 15 years, this was my specialty at EK. Automation and scaling of emulsion making. I worked heavily in the emulsion arena designing the software for use in the darkroom for emulsion makers who wanted a robust emulsion to scale.

While this is not exactly the same as what is being discussed here, it is closely related and I have a lot of experience in the area. If I can help, let me know.

PE

 

[leeturner]

With regard to .Net applications there is the mono project http://www.mono-project.com/Main_Page
which has been underway for a couple of years. This enables .Net applications to run on Linux, BSD and Mac. As with the Wine project some of it is not pretty but it's getting there.
For Linux use I've had a lot of success with VMWare which lets me run several different Windows operating systems on one machine, each with it's own workspace.

 

[edz]

If you wish to control hardware directly from a multitasking OS, you need a piece of software that runs at the Kernel level or level zero.

Realtime UNIX is not a good idea--- back in the old days we even had realtime computers to control our multitasking machines. That's why in the PC-era GM and others used to use a lot of OS/2 boxes for CAM and the point of QNX. Windows can be eased into RealTime modus..

You also should not try to control hardware from scripting type languages or interpreted languages such as HTML, XML or Java. Perl falls into that class as well IIRC.

You sure can control hardware using interpreted languages.

-----

I would not bother doing realtime to make a darkroom controller but instead just write a simple wxPython or other little GUI script to send messages to a contoller that does the stuff.. in other words.. I don't turn the lights on and off but send a message to a piece of hardware to say.. "Turn the lights on and after XX ms turn them off". At the end of the day this is not only easier but also probably cheaper.. I can put the controller right up into the devices and controll them via bluetooth or other LAN interface..

 

[Photo Engineer]

You sure can control hardware using interpreted languages.

-----

I would not bother doing realtime to make a darkroom controller but instead just write a simple wxPython or other little GUI script to send messages to a contoller that does the stuff.. in other words.. I don't turn the lights on and off but send a message to a piece of hardware to say.. "Turn the lights on and after XX ms turn them off". At the end of the day this is not only easier but also probably cheaper.. I can put the controller right up into the devices and controll them via bluetooth or other LAN interface..

You are right in this if that is your only task, but if you need to control the intensity of the light during that period of time, the scripted or interpreted language is too slow unless the control box itself has a feedback loop. Especially if the number of lights goes up into the hundreds. This is juat a made up example however.

In my experience, most everything is too slow except compiled code or assembly code. I guess that is the price I paid for learning to control a large number of high speed very precise events. The things going on here are very slow speed and imprecise. I think you can see that.

Perhaps I've been wrong to point out those things from my POV.

I will say that it is less expensive to have one central controller with software rather than a 'black box' controlling each item. We priced that out long ago. It has not changed.

PE

 

[edz]

I will say that it is less expensive to have one central controller with software rather than a 'black box' controlling each item. We priced that out long ago. It has not changed.

I'm not sure. Have you had a look at the new chips going into the "smart houses" stuff? They've come down to--- a company doing some devices had their stand right next to us a few weeks ago--- a lot and are intended to be used to control per-item. The application is different but at the code the technology is the same--- just a little different code.

To get a computer "real-time" to run a bunch of switches is much more difficult and the demands are not trivial. One can run a sophisticated controlling application with loads of bells and whistles on a little embeded machine. I can run 1000s of "black boxes" using a little Geode box running Unix--- in fact at the show we had the entire http://www.ibu.de site including search, running on such a system (runs on 10watts and is small enough to fit in an overcoat's pockets), ran X-Windows and have firefox running and performance was great so.. Managing 1000s of slaves is an easy task.. its running 1000s of channels that's difficult..

 

[Photo Engineer]

Ed;

We had to control small prototype processes, intermediate processes and production. The equipment was all automated using 3 different computers due to scale, but required a lot of A to D and D to A converters just to control the equipment. The whole thing ran at high speed and each size process had to duplicate all of the others.

The control algorithms had to be different for just about ever situation, and the 1000 slaves were more expensive than 1000 channels. In some cases we had 1000 channels where 100 of them drove 100 slaves, but only when the rate of change was not too dramatic. The smaller slaves didn't have the capacity or speed.

I'm sure though that in recent years, the capacity of slaves and their speed have increased a lot while prices have dropped, but the labor and cost of changing may be too much to bear in the decreasing analog market as machines are shut down.

In any event, I've been there and done that. Everything we did was in C or C++ with a VB front end. The C and C++ did the fast calculations, and some code ran drivers. The fast drivers were in assembly. Oh how I hate Intel assembly code, but any code for the WDPF (a Westinghouse process control computer) was a real monster as it was all proprietary. The Taylor was not much better.

Virtually all of the research scale process control equipment has been scrapped. I sure wish I had one!

PE

 

[lee]

this all sounds like my dad can beat up your brother talk. How exactly does having all this computing power in the darkroom actually help you make a blankety blank print?

lee\c

 

[Photo Engineer]

Lee;

To quote myself: "Perhaps I've been wrong to point out those things from my POV".

The bottom line IMHO is that the average person does not need a computer in the darkroom.

But, when the tasks become more complex and the volume goes up, you do, and by then you better have good equipment and good software. Most minilabs have quite complete computer equipment with process control as do the printers.

There is a dividing line between these two extremes and that can only be determined by the individual who is doing the DR work. I have worked in both environments, small scale manual and photofinishing and large scale rapid production and find that computers are not needed in small scale except for special purposes in emulsion making. Otherwise, I keep the computer out of my darkroom.

PE