On Thu, Apr 21, 2011 at 02:14:01AM -0700, Jeff Harmon wrote: > > Exchanging "settings" between advanced imaging processing packages is > > often extremely difficult or impossible, simply because they all work > > differently (internally). > > Thanks for your sensible reply. This is a solid general point to > raise; however, I am curious how true it is in this exact case? > Perhaps it is a tall hill, but one that could be climbed? We are open > to funding such an effort.
Some of the basic settings could be mapped in a quite straightforward manner, e.g. exposure and colour temperature where probably most software uses the same units (EV and K), or some other scale with a clear linear or otherwise simple relation. Others would be a little harder, e.g. many packages give a contrast control, whereas UFRaw lets you input an arbitrary curve as a way to adjust contrast more flexibly. Such a curve could be generated from a contrast value (and indeed there was a patch a while back that did this in UFRaw), but it would be hard to define the right way to generate that curve such that it acheived the same results as the other software, especially when the target is a closed source package meaning everything would have to be done by trial and error. That trial and error process could be automated to some degree - optimizing to find the input on a given control in UFRaw which gives the closest matching output image to the result of a corresponding control input in the other package. But that assumes you can even get the two packages to produce closely matching output images in the first place at "neutral" settings. And that each control in UFRaw maps clearly to one control in the target package. These assumptions probably aren't true, which means it becomes a multi-parameter optimisation problem, probably quite non-linear, and expensive to evaluate. And it's not clear what the cost function would be, i.e. how do you define how "wrong" a given output image is. That comes down to being a subjective question. If the intent is just to get some roughly reasonable settings for UFRaw from an existing collection of .cos files, then that might be practical based on some rules of thumb for mapping parameters, depending what combination of controls have been used and whether UFRaw can duplicate their functionality. But it would be highly dependent on subjective judgement, so it may not be something you can usefully fund somebody else to do. Martin ------------------------------------------------------------------------------ Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev _______________________________________________ ufraw-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ufraw-devel
