Re: [hugin-ptx] Re: RAW support with hugin ?
I read about demosaic-ing and did my RAW-101 class :-). I'm still a noob on this. I understand the process would involve a RAW sticher, the PTO being generated on some initial set of (rough) converted files. Yet... Vladimir, why do you have the need to separate the colors ? Can't the stitching be done on the array of Bayer data ? Care has to be taken that red values be distorted and only put in red positions in the resulting array, before mixed with other red values from other distorted arrays. But then the resulting array is a giant RAW array, a panoramic RAW, that needs to be de-mosaic'ed, white-balanced, noise-reduced, etc... The advantage (quite certainly not worth the development, but theoretical) being that you handle the RAW processing on the entire pano, afterwards. In other words, programmatic care has to be taken that « *The next problem is that after remapping the Bayer pattern is destroyed* » be avoided. I foresee a possible objection, that raw values only have sense in relative values within a single shot, and that two shots do not share the same numeric conversion origins (i.e. measurement offset, inconsistent calibration of the A-to-N converter). Is that so ? Le lundi 9 juillet 2018 20:53:52 UTC+2, T. Modes a écrit : > > Am Montag, 9. Juli 2018 16:02:06 UTC+2 schrieb nadv...@suse.cz: >> >> It might be possible to convert the mosaic data to independent channels >> with transparency: >> >> source: >> >> RGRGRG >> GBGBGB >> RGRGRG >> >> to: >> >> RTRTRT >> TT >> RTRTRT >> >> TGTGTG >> GTGTGT >> TGTGTG >> >> TT >> TBTBTB >> TT >> >> >> I don't see any principal problem with processing such images with nona >> and enblend. >> > > > If you do it this way each color will get different interpolation for each > color (because different alpha channels) and this will results in color > seams. > The next problem is that after remapping the Bayer pattern is destroyed. > With the destroyed Bayer pattern it because impossible (or at least very > difficult) for the RAW converter to demosaic the data now to get the final > image. > > (An alternative approach would be to demosaic the image data, then remap > the data and then mosaic the data again to get the RAW again. But then you > will loose resolution. So this is a no go.) > -- 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/e13f5acf-bc1a-403e-a663-ac1c70e30b58%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Re: RAW support with hugin ?
It shows my ignorance on what is in the raw format and what tasks the raw processor does. This being out of scope (not hugin related) let's not clutter this list, but I'd appreciate a recommended reading to understand what I'm missing, if you have a good one. Thanks you either way. Le lundi 9 juillet 2018 15:18:21 UTC+2, bugbear a écrit : > > How (on earth) does one perform spatial interpolation on raw data that > hasn't been de-mosaic'd ?! > -- 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/ca7dc5af-dfb7-4aca-952c-2914ea19b01b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[hugin-ptx] Re: RAW support with hugin ?
All the answers to this post assumed the raw processing is done before the stitching (which would work on TIFF/JPG… files). I totally agree on the objections. However, does it make sense to* combine raw files into a raw output*, that can further be processed in rawtherapy ? Distortions, stitching, etc could presumably be done on raw data arrays in an equal manner as they would be done on pixels. Not ? In practice, there could be a prior-conversion into jpeg with fixed (low-relevant) processing parameters, just to get the stitching parameters (PTO) and previsualisation, but the stitcher would work on RAW files. Would absolute data values for one shot not have the same reference as for a different shot, and consequently merging files has no sense ? I understood that precisely RAW format leave the normalizing to the processor, recording brute sensor data, so merging RAW files seems to have sense to me. My question is just theoretic and blunt curiosity. I'm not spending, nor asking anyone to spend time on this. It seems like a huge work to rewrite a stitcher, especially ending up writing one for as many different raw formats as exist (re-using rawtherapy file-opening library, presumably). Does it make sense at all ? (Brings me to the question to start with : *why do people want RAW support in Hugin* ? because they find the workflow a pain ? or for technical and image quality reasons ?) Regards, Marcel. Le mardi 3 juillet 2018 09:14:43 UTC+2, Albert Szostkiewicz a écrit : > > I saw similar topic from 4 years ago without any conclusion. Is where a > reason why Hugin is not supporting RAW formats? Any plans for near future ? > > -- 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/25bdb15a-6758-4de3-a231-48820ad2a91c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
