kfj schrieb am Freitag, 23. Februar 2024 um 08:35:28 UTC+1:

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:


Sorry for kill the joy. But when taking the full Hugin workflow into 
account and take all advantage of the raw format it becomes fast more 
complicated.

It's not so easy to just replace the load routines, the whole ecosystem 
around have to be adopted.
Just to mention some things to considers:
* The colorspace of the image data has to controlled, ideally a linear 
colorspace with a wide gamut and not default gamma corrected sRGB of OIIO.
* Disable all automatic changes/adoption by libraw (auto brightness, …).
* Control the white balance, so that all images get the same wb.  (e.g. 
reading from the first one and apply this then to the other images)
* Take care of the cropping of the raw images (they often contain black 
borders).
* Take care of rotation of the images.
* Allow the user to change some parameters (debayer algorithm, noise, …). 
Then the user want a GUI to change them interactive and fast preview. These 
would mean to implement a crude raw converter GUI into Hugin.(Just out of 
curiosity, OIIOs raw import has at least 24! different user settings for 
the raw import.)

These are only the first issues came me into consideration - these are 
simply ignored by your proposal. 

(There may be some program parts which would also work without take all 
this considerations. But it needs to be taken into consideration the whole 
workflow.)

Taking all together would mean to extend the file format to save the new 
settings and the load routine would needs to update to take care of them.

Converting a raw image takes also some run time. How does this affect the 
responsivity of the GUI, especially when loading several images or when the 
caching of the images is needed?

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.

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.

-- 
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/34049e94-853e-4c6c-9abc-8f3ef0a5be28n%40googlegroups.com.
              • ... dudek53
              • ... Bruno Postle
              • ... 'kfj' via hugin and other free panoramic software
              • ... dudek53
              • ... 'kfj' via hugin and other free panoramic software
              • ... dudek53
              • ... 'kfj' via hugin and other free panoramic software
              • ... dudek53
              • ... 'kfj' via hugin and other free panoramic software
              • ... 'kfj' via hugin and other free panoramic software
          • Re... 'T. Modes' via hugin and other free panoramic software
            • ... 'kfj' via hugin and other free panoramic software
              • ... dudek53
              • ... 'T. Modes' via hugin and other free panoramic software
              • ... 'kfj' via hugin and other free panoramic software
      • Re: [hugin... David W. Jones
  • Re: [hugin-ptx] cre... dudek53

Reply via email to