Brian Sweeney said:
Jaap,
Lucky are those who do not understand computer-speak. I've worked with computers for 30 years and digital imaging for 25. In 1992, I talked to Kodak about using a CCD without the IR cutoff filter in it. It was from knowing the spectral response of the CCD and asking why the off-the-shelf camera did not work with IR. The Army later asked for the same thing and Kodak came out with an Infrared version of the then new Kodak DCS200.
I've been trying to catch up with this thread, and will jump in here... wow, and I thought "double-dutch" jump roping was difficult!(Oh, and for those of us Dutch, I refer to a game where two ropes are spun between two persons, while others attempt to keep their bodies from catching either... I do not know where the term "double dutch" originates, and will leave this for PMs)...
Brian Sweeney said:
I've written "emulator" and "simulation" software for a long time, and I thought the conversation on the difference was funny. I had to throw the computer terms in, just to try to lighten it. Apple is about to switch processors "again" and will come out with an emulator to allow old programs to run on the new machines. If the past is any indication, the software will be so slow and "buggy" that it will be virtually unusable on the new machines. Intel CPU's have "modes" in them that execute old software in hardware, and emulators are not required. So I can run my 1984 DOS software on a new Pentium 4 without problems. I used some 20-year old software tools to read the RAW images from the Kodak DCS200 to convert them to a new file format that Photoshop could read. In doing so, I found the images were larger (more pixels) than what the original Kodak software provided and that the range from black to white (pixel values) had a greater range. My software produced a larger image with more grey-scale values than what the Kodak software could do. I think it was trying to apply some sort of response curve to the image to mimic what you would get with film.
OK, thanks Brian for the clarification, but did you address the "emulate/simulate" toipc? I understand the Apple, or any computer issues with emulating old instruction sets, but you did not take the "emulate/simulate" discussion further... particularly with respect to the discussion of the hardware(CCD, sensor) and software(camera OS, PhotoShop).
Hardware CCDs or sensors may be engineered for sensitivity to *types* of light which reaches them; however, the signals one may connect to via the hardware interface is only part of the process(ing of the data). As you(Brian)state, companies produce CCDs and CMOS devices optimized for light conditions, including IR filters. This engineering is not dissimalar to chemists designing film emulsions. The difference is that a COTS RF camera(Fed, Canon, Leica or CV,etc) may *load* any type of film meeting its mechanical capabilities, and thus escapes the "hardwired/softcoded" digital aparatus's programming. This, I think, is what the "nothing looks like Tri-X" folk are commenting.
[COTS is "Common Off The Shelf"]
Thus, a digital camera--and its OS and sensor sub-system--may emulate only certain types of film behaviors. PhotoShop, its plugins or The Gimp may only simulate a visual effect from the camera data it receives as if, say, a red filter had *been applied* when the data was recorded. It's this last bit that has digital folks running at the mouth about RAW files: RAW files are not *pure*, but the data left-over after the camera OS has had its way with the sensor's I/O. You, Brian, know that this RAW file is always the data of the algos which created it, whether Kodak, Canon, or others... that's why you jumped in and hacked some FORTRAN... to make your own RAW(sic) file!
From a cost-benefit analysis, digital camera manufacturers will ship primarily color-sensitive sensor sub-systems, and then offer "professional models" with *emulators* of B/W. Now, here's the tricky part: do you, dear photogs(Bertram?)
want the camera to emulate B/W, or give you a larger data-set(aka file) with which to later simulate B/W when you, ah, want *that kind* of image? Think: Winogrand not having left 300+ rolls of film, but 300(x36?)+ RAW files un-simulated at his passing...
When Tom, and others, state that "digital is a whole new ballgame," they refer not to the image the camera "captures," but the light effects captured and the simulations they may run with this data to produce an *image*. Double-dutch redux, ad infinitum!
B/W is a result/function of the chemist's emulsion(emulation), not the light--oh, yea, light!--through the lens. Programmers, not chemists, are constrained by the data they are presented... digital can do the "Tri-X look," eventually, but why? Just give us the data--say the PhotShop/Gimp capable--I'll do the rest.
For me, I'll take the digi-cam that provides the least non-emulated, full of light reading on the sensor: color is in the eye of the manipulator in this digital medium. Problem is, cameras are "optimized/priced" for those who want that "film-effect" these days.
Brian, you have that FORTRAN code public? It's the new developer recipie
😉 Or, have you worked something out wih Kodak and it's under NDA? Yup, new ballgame, a whole lot of extra ropes to jump through, maybe... it is the image, not the medium!
with kind rgds,
Dave