dcamprof - a new camera profiling tool

Hi folks -

Anders Torger has been developing a labor of love called "dcamprof" and has been discussing and documenting the development of this utility over at the Luminous Landscape, in this thread:

http://forum.luminous-landscape.com/index.ph​p?topic=100015.0

This is a tool that is aimed at producing highly customizable DCP and ICC camera profiles based on spectral data from test targets (Color Checker, Passport, QP, etc.) that you image with your camera. The details of the utility and the instructions for building and using it are available at:

http://www.ludd.ltu.se​/~torger/dcamprof.html

This is not a GUI-driven, drag-and-drop profile maker, it is a command line interface utility that is highly flexible and constantly evolving as users give the author feedback. Not for the casual user, but for the user that would like to explore and customize the production of their own camera profiles.

Anders is also the author of LumaRiverHDR:

http://www.lumariver.c​om/Products/LumariverH​DR/

Enjoy, and take your time to absorb the herculean effort that went into developing this utility.

Kirk

I followed the LuLa thread up to about page 6 then gave up. But the experience made me curious about a couple things.

One is why a guy with the talent to program something this sophisticated either can't or won't wrap it in a GUI interface in order to reach a much wider audience. Made me wonder:

1. What is the total audience for profiling? I'm sure it's very small, but is it big enough to make a market? Will it grow?


2. What fraction of that audience is willing and able to deal with the complexity of dcamprof and a command line interface?

3. Why are the major players not putting any effort into profiling? Xrite has not updated their software since version 1, made years ago. Adobe updates DNG PE for new cameras, but has not improved the base function in years. DXO and PhaseOne have nothing.

4. Printer makers and most paper makers provide profiles for their products. Why do Canon, Nikon, Sony not provide raw conversion profiles for their high end cameras?

I consider myself an advanced photographer with well above average computer literacy. I'm "able" to deal with complex programs and command line interfaces, but I'm not "willing". I assume that such a significant effort would yield an insignificant gain. In the LuLa thread I saw no "proof of concept". No examples, no images showing the superiority of dcamprof. Nothing to motivate me to consider the effort.

Redcrown wrote in post #17556252
I followed the LuLa thread up to about page 6 then gave up. But the experience made me curious about a couple things.

One is why a guy with the talent to program something this sophisticated either can't or won't wrap it in a GUI interface in order to reach a much wider audience.

He is a programmer who writes code to get things done. It appears that he wanted to make a profiling tool for himself that would emphasize accurate color, and decided to make it available for others in a cross-platform way. A GUI is unnecessary. In the minimum, the user can type 4 or 5 lines of commands and generate a DCP or ICC profile for their specific application. You could even write a shell script to automate the process and type one command at the shell.

Who knows? Probably small.

Probably a pretty small fraction of that small fraction. But there are a few of us in that thread that find it interesting and are willing to test the functionality and experiment with it, after encountering situations where out of the box or canned profiles have failed miserably. I think this appeals to people who like to understand what is going on under the hood, even if it makes insignificant differences in our everyday photography most of the time. The fact that Anders has made his work freely available is a significant contribution to those looking for such a utility.

Raw converters come with camera profiles of varying complexity. People use these canned profiles with few complaints, mostly I would think because they do not expect or know better. If you buy expensive cameras, expensive lenses and expensive software to run on your expensive computer and display on your expensive display and print on your expensive printer, I would guess that the tendency for most people would be to think that the end result can only be "Great!" or "Awesome!"

It is like buying a new, expensive bicycle - you can buy a really expensive, top of the line off the shelf carbon road bike with all of the bling and ride it - most people would do this and think that it is "awesome!" And it may be. But for the same amount of money, you could have had a custom built bike made specifically for you and you might realize that the one-size-fits all approach may seem awesome until you have been show otherwise. That is, if you are discriminating enough to know or care about the differences. If it doesn't matter all that much, then it is probably not worth it.

They do - how else would a raw file get converted to an image? DPP comes with your camera, for an example of Canon. What would be more useful is if Canon shipped each camera they made with a digital file containing the spectral sensitivity function of that specific camera. Then, in theory, one could make one's own profile for specifically for that camera for any raw conversion platform.

The proof of concept is left to the user. That is the whole point - you can use the utility and even modify the code if you want, to make it do specifically what you want it to do. You are the one that needs to decide if your camera and the raw conversion profiles you use give you "good" color or not. If they do, then there is no need to use this utility. If they don't, then maybe this utility is useful. You can find out for yourself by shooting a target, measuring the target's spectra and then feeding that data to dcamprof to make a profile - DCP **or** ICC.

You make perfectly sound points. It depends on the user and their desire to invest the time and effort.

kirk

While it's always great to see people playing around with this stuff and I'll probably have a look / compare at some stage when I have time, I'm not sure I understand any advantage over the x-rite profile tool.

As far a the lack of a GUI, I am certain that there are a lot of folks out there that are perfectly happy writing code to solve technical/scientific problems, who are otherwise not coders and have no interest in trying to wrap a GUI around their problem solving. I would say that i fall into that group as I am perfectly happy programming solutions but have not bothered to figure out wrapping it in a GUI. I even at one point wrote a whole Complex Number library for JAVA with the thought that I could bring a C++ solution over to JAVA so that I could wrap it in a cross platform GUI. I got the solution written in JAVA, and it was actually quite efficient, as there were lots of recursive loops, which allowed the JAVA environment to compile on the fly. I never though got the GUI working, as it was just more work than I needed. It was very simple to just run the program from the command line, and then drop the output results into Matlab or even just Excell to to the 3D graphing of the array outputs. My project was modeling acoustic propagation in a 2D slice of water (although it would work for any wave propagation in any medium). I could have done the modeling in 3D, but back in 1995 even the university did not have access to a supercomputer that would have run it with the necessary speed. At the time I was working on Digital Alpha Unix workstations with 64MB RAM, and I was pretty much limited to data arrays with around ten thousand nodes or the machine would max out the HDD trying to do memory management.

Sorry for the rambling, but it is a good example of why people don't write GUI's for scientific/engineering problem solving, it's often a wasted effort, in an area that is unfamiliar.

Alan

BigAl007 wrote in post #17558439
As far a the lack of a GUI, I am certain that there are a lot of folks out there that are perfectly happy writing code to solve technical/scientific problems, who are otherwise not coders and have no interest in trying to wrap a GUI around their problem solving. I would say that i fall into that group as I am perfectly happy programming solutions but have not bothered to figure out wrapping it in a GUI. I even at one point wrote a whole Complex Number library for JAVA with the thought that I could bring a C++ solution over to JAVA so that I could wrap it in a cross platform GUI. I got the solution written in JAVA, and it was actually quite efficient, as there were lots of recursive loops, which allowed the JAVA environment to compile on the fly. I never though got the GUI working, as it was just more work than I needed. It was very simple to just run the program from the command line, and then drop the output results into Matlab or even just Excell to to the 3D graphing of the array outputs. My project was modeling acoustic propagation in a 2D slice of water (although it would work for any wave propagation in any medium). I could have done the modeling in 3D, but back in 1995 even the university did not have access to a supercomputer that would have run it with the necessary speed. At the time I was working on Digital Alpha Unix workstations with 64MB RAM, and I was pretty much limited to data arrays with around ten thousand nodes or the machine would max out the HDD trying to do memory management.

Sorry for the rambling, but it is a good example of why people don't write GUI's for scientific/engineering problem solving, it's often a wasted effort, in an area that is unfamiliar.

Alan

Thanks, now I have a headache. Lol

ThreeHounds wrote in post #17558479
Thanks, now I have a headache. Lol

Sorry

Alan

ThreeHounds wrote in post #17558479
Thanks, now I have a headache. Lol

What? Finite elements don't make you float on rainbows? Come on!

kirkt wrote in post #17558541
What? Finite elements don't make you float on rainbows? Come on!

Kirk I wasn't using finite elements, I did it using Transmission Line Modeling. Much simpler mathematics, as long as you are able to keep everything real, which was actually not a big problem when it came to the simulation. The real issue was that the data object for each node on the two dimensional array used something like eight doubles, plus a few other status items etc. Hence why RAM was such an issue. On a 486 DX2 66 with 8MB RAM using Linux I could maybe run a 1000×100 matrix, without it going nuts on the swop disk. Not very useful when trying to model the acoustic effects out in the North Sea, for the low frequency signals that we were interested in the nodes were spaced at about 1m. It would have helped if it could have been easy to make it run on multiple processors, the stumbling block was that each node was dependent on the existing and new values of each of its four surrounding nodes for each time iteration. If you move it to a 3D model you are then dependent on six surrounding nodes in a rectilinear array.

Oh and sorry to take the thread a bit (or maybe a lot) off topic.

Alan

Oh and if you are interested here is a link to the Wiki on TLM modeling. I was doing this back in 95, before it's use in acoustics had been considered. It was my BEng degree final project.

Um, I fixed my washing machine.

Left Handed Brisket wrote in post #17558842
Um, I fixed my washing machine.

Now they're just messing with us.

I spent part of today re-working three lens hoods to make one "perfect hood" for each of three sensor sizes. (Full frame, APS-H and APS-C)

Now my 10 year old 17-40mm f4 has a "perfect hood" for all three (I Did the first one for APS-C way back in 2004 or so)

It's sort of like a profile for the lens? sort of? Anyone.. ?


I actually find this software tool very intriguing. If the demand increases, my bet is that Anders will make a GUI for it,. and sell a license as he does for his HDR tool.