I appreciate this insight. I can see this proposal presents some serious challenges. I'm not yet daunted, either by the expense or difficulty, without more specifically assessing COS files particularly. Perhaps I could fund a discovery assessment?
I'm studying the structure of COS files and Capture One already, but don't have the expertise needed and certainly don't know ufraw internals. Suggestions on how to proceed are welcome! My motivation is simply that Capture One 6.1 doesn't offers a reasonable scripting or headless architecture and therefore doesn't suit our needs of server-side processing of raw files, but many photographers use it. -J On Apr 21, 2011, at 4:27 AM, Martin Ling <[email protected]> wrote: > 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 > ------------------------------------------------------------------------------ Fulfilling the Lean Software Promise Lean software platforms are now widely adopted and the benefits have been demonstrated beyond question. Learn why your peers are replacing JEE containers with lightweight application servers - and what you can gain from the move. http://p.sf.net/sfu/vmware-sfemails _______________________________________________ ufraw-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ufraw-devel
