On Friday, February 23, 2024 at 5:01:45 PM UTC+1 T. Modes wrote:
when taking the full Hugin workflow into account and take all advantage of the raw format it becomes fast more complicated. ... These are only the first issues came me into consideration - these are simply ignored by your proposal. I am offering a proof of concept to demonstrate what's possible. But of course your concerns are valid. As I already pointed out to Gnome Nomad, OIIO's raw plugin is highly configurable. It offers roughly the same functionality as libRAW upon which it is based, which in turn offers roughly the same functionality as dcraw. OIIO is quite good at taking in parameters from outside. In lux, I simply pass parameters to OIIO and it's plugins through as strings, and OIIO parses them and passes the plugin-specific ones on to the plugin. Look at it in a different way: OIIO opens TIFFs just fine. There's noone stopping you from using the same workflow as ever, but you *could* also try and work from RAW directly. It's a new possibility to play with, to see if it opens up avenues which weren't possible before. It's an experiment. You're sure not killing the joy, and if you insist on keeping hugin the way it has always been - go ahead. My proposal - using a toolchain with modified pto_gen and cpfind, then autoopitimser and finally lux to stitch - doesn't even use hugin - it was dud...@gmail.com who proposed changing all of hugin. Modifying cpfind was the missing link for me to get a toolchain together which works in RAW entirely. A lot of my photography is in RAW, and I throw away the TIFFs after stitching because they take up a lot of space. With the oiio branch of lux I can now simply replace .tiff with .CR2 in the PTOs and stitch from RAW, because I used dcraw in the first place. And for my Samyang fisheye, I can even pass through chromatic aberration parameters... I find that a remarkable achievement. So it's not done with simply replacing the load image call with another library. The whole ecosystems needs to be adopted and you have to implement a lot of functions of a raw converter. No, you don't. They are already all there, and you simply pass the parameters you want. Again, here's the link to OIIO's libRAW plugin <https://openimageio.readthedocs.io/en/v2.5.8.0/builtinplugins.html#raw-digital-camera-files> , you'll see it's pretty much all there. And in lux you can simply pass these args on e.g. on the command line, like --oiio_arg=raw:user_flip=0 IMHO there are dedicated raw converter better suited for these task. Hugin can already take care of some of them. This I consider a better solution, than to open Pandoras box and implement a lot of RAW converter features into Hugin. What the better solution is will show in time. I find a quick and easy option to work directly from RAW is a bonus, even if it takes some extra time to decode the images. If any of this turns out to be a good solution to adopt throughout the hugin codebase can't be decided now, but I wanted to show a path forward. Or will you go ahead and implement vigraimpex import plugins for e.g. HEIF and WEBP, to name but a few? Lux uses a fair bit of vigra, but I feel stuck now that nothing is happening with vigra anymore. My proposal is also about opening up an avenue to a large number of modern image file formats which vigra can't handle because noone there kept abreast of new developments. -- 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 hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/837730dc-542c-4405-b8a4-5ad9eb171825n%40googlegroups.com.
