wow, I did not expect such big and aggressive response :) I did not meant to offend hugin hardcore fans :)
I know that PTGui is using dcraw, and there is nothing wrong with it. It is also not true that dcraw will strip all dynamic range data. You can check its possibilities here (https://www.cybercom.net/~dcoffin/dcraw/) All I am asking is why not give such ability to Hugin? I don't think that would strip anyone from control. It would just add simple yet handy feature to Hugin. My point being: I needed simple software that gives me good result, fast for my own simple task: create HDR panorama from raw photos (for my personal purposes, not at work). I was checking few softwares on the market like gigapano, ptgui, hugin and few others. Without knowing neither of them, I wanted to give a try to each one of software ans see which one will give me best results. I ended up being torn apart between ptgui and hugin. While Hugin is a free package, I was forced to deal with conversions, transferring exif infos, dealing with color spaces during conversion and stitching was giving me unwanted artifacts which I have tried to fix with different tools and settings but after few hours i gave up. Ptgui on other is not available on linux so I had to run it via wine and it payed software so two strikes on beginning. But I was able to throw at him my raw photos directly and i got expected result without touching a single setting, no artifacts, just worked with single button, got expected dynamic range. Simplicity when needed. Ended with paying for PTGui license. Stitching HDR panoramas should be really 1-2-3 click, simple task. There is no brainier here (from Artistic point of view). In a large company I work for, they ended up writing own software to stitch HDR panos automatically (as we use them for work purposes) I am Linux user, and I work in quite complicated software on everyday basics but If we could simplify and make some steps easier - why not? On Wed, Jul 11, 2018 at 9:36 AM Vladimir Nadvornik <nadvor...@suse.cz> wrote: > On 07/11/2018 11:17 AM, Marcel Brouillet wrote: > > 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 ? > > I was thinking about something similar to "Bayer drizzle" algorithm > (soory, right now I can't find any good explanationon fof it, the > information on google is rather fragmented) > > The input is bayer data, output is normal RGB image. > > > > 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 ? > > > > I see no advantage in saving output as Bayer data. For example > Rawtherapee handles tif files almost the same as raws. > > > Vladimir > > > > > 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 > >>> TTTTTT > >>> RTRTRT > >>> > >>> TGTGTG > >>> GTGTGT > >>> TGTGTG > >>> > >>> TTTTTT > >>> TBTBTB > >>> TTTTTT > >>> > >>> > >>> 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/170638c5-34f5-ca21-b638-e84225acebb0%40suse.cz > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CAFLAP745j1UjY9-oj6XrLfKsLE63b6hS6h-Oq2JM7VwbUpU2Ww%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
