> It seems you came far into this libraw implementation. Would be of big interest to have this working with enfuse or align_image_stack. How would it handle tonemapping code though? My proposal is simply about reading image files into the program. it's to replace use of libvigraimpex for image import, that's all. Everything else remains just the same. This is why it was so easy to 'slot it in' to cpfind and pto_gen: I just looked for vigra::ImageImportInfo and replaced it with a struct which uses OIIO data internally, then I looked for vigra::importImage and replaced it with calls to an equivalent routine using OIIO. Apart from a bit of glue code to mimick the vigra::ImageImportInfo structure and to map parameters originally passed to vigra::importImage to the code using OIIO there were no changes. I already had the glue code, because I use it in lux. Tonemapping etc. is not in the scope of this proposal. That's the beauty of it: all code can remain as it is, only image import is re-routed to a powerful, modern library with lots of interesting features. The glue code resides in a small pair of .cc and .h files, and inside the code being transformed, all it takes is an include statement and the replacement of vigra::ImageImportInfo and vigra::importImage with calls into the glue code. It's minimally invasive. The down side is that OIIO is a large library. But it's very available - I found it on all platforms lux supports - various linux distros, macports, mingw and freeBSD.
-- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/c4909668-09ce-4f8e-8846-a64ff81b3702n%40googlegroups.com.
