Oh, I've forgot to mention that once cage tool is released, you lose the 
cage...

On Thursday, August 8, 2019 at 10:02:44 AM UTC+3, Mihai Dobrescu wrote:
>
> Probably the vanishing of the cage is a bug and after tuning and waiting 
> it's so frustrating.
> Working on a full image is truly difficult anyway. This is not the right 
> thing to do.
> I have 24GB of RAM, BTW, so I think is not the memory, but the 
> calculations.
> Probably GIMP should implement a preview mode for this.
>
> On Thursday, August 8, 2019 at 9:27:47 AM UTC+3, GnomeNomad wrote:
>>
>> Hi, Mike! 
>>
>> Hmm, on my present i7 (2.4GHz laptop processor, 16GB memory), it was 
>> fast. But you're working with the full-size image, I wasn't. 
>>
>> Twisted and swirled: You didn't have enough points. 
>>
>> You need more than 8 points. On the smaller one I did, I put a point on 
>> every place where the curve of the image edge changed. I probably had 
>> 12-20 points each across the top and bottom. Plus one on each 'corner' 
>> of actual image. 
>>
>> You'd probably need more points across on the full size image. The more 
>> points you have, the more calculation it has to do for every pixel in 
>> the image. I think using more points also reduces the distortion that 
>> results from such transformations. 
>>
>> Maybe use the cage tool to change just the top part of the image. Save 
>> it as a native GIMP image. Then use the tool to change just the bottom 
>> part. I think doing each part separately will speed up the calculation 
>> process. 
>>
>> It might also make it easier. With points on both top and bottom, I 
>> noticed that tweaking a bottom point would also change things at the top. 
>>
>> I also somehow made the cage vanish the first time I tried it. I have no 
>> idea why that happened. Also only using mouse. 
>>
>> On 8/7/19 7:38 PM, Mihai Dobrescu wrote: 
>> > Hi all, I have tried GIMP cage. Not successful. 
>> > First, I've tried 8 points, one per corner, one per side middle. Does 
>> > not do as expected, somehow the image was twisted and swirled. 
>> > I've tried to add many, like following the irregular shape with a lasso 
>> > tool. That was absolutely odd. 
>> > Took many minutes, on my old i7, about a quarted of an hour, just to 
>> > calculate something after closing the cage. 
>> > Then each move took another painful time. An to be absolutely 
>> > discouraging, out of the blue, the cage disappeared and the image got 
>> > back to the original shape. 
>> > Don't get what happened, as long as I've used the mouse only. Weird. 
>> > 
>> > I think this might do, eventually, but it does not have the advantage 
>> of 
>> > working with some light preview, like ACR and Hugin. 
>> > A tool like this should be added for such processing. 
>> > 
>> > Just my thoughts... 
>> > 
>> > Regards, 
>> > Mike 
>> > On Wednesday, August 7, 2019 at 11:28:03 PM UTC+3, Mihai Dobrescu 
>> wrote: 
>> > 
>> >     [I paste my answer here. Mike] 
>> > 
>> >     Hi, I am a software developer myself. I imagine it's not simple. 
>> >     The code I was referring to is morph-to-fit script and related. 
>> > 
>> >     As a side note, ACR and PS use a script to stitch, I imagine the 
>> >     analysis and refinement to implement the whole process... They have 
>> >     managed to make a simple to use tool that fulfills a lot of people 
>> >     needs with a few clicks. 
>> >     I am not saying it's perfect or to steel the idea from it, but it's 
>> >     a good example. 
>> > 
>> >     Too bad the discussion was split by writing directly to my inbox, 
>> as 
>> >     now I've got two opposite answers... 
>> >     Of course, I wouldn't come to force anybody to do it or accept some 
>> >     code for it, nor having hard feelings for refusing that. Here might 
>> >     come some fork, that makes FOSS so flexible, but also a pain for 
>> the 
>> >     users, no wonder they blame it so much... 
>> > 
>> >     ACR would be my tool of choice, as I am not looking for something 
>> >     free, but, you know, I have embraced Linux, due to much pain 
>> induced 
>> >     by using Windows (privacy invasion and lack of support for certain 
>> >     VT-d implementations that renders it not bootable for years, and 
>> >     other inconsistencies and situations that broke my workflow). So I 
>> >     have found several gems like RawTherapee, Darktable, Inkscape, 
>> >     Krita, GIMP, Blender, along with their fine and responsive teams. 
>> >     And the DE's on Linux are stellar wonderful and well usable, that 
>> >     lead me to a true dilemma of what to chose, I'd peek at least two 
>> at 
>> >     once. The only thing left would have been a good panorama tool, 
>> >     which Hugin is. 
>> > 
>> >     Kind Regards, 
>> >     Mike 
>> > 
>> >     PS: Often, the simpler the UI, the more complex the code is. 
>> > 
>> >     On Wednesday, August 7, 2019 at 11:14:47 PM UTC+3, Bob Bright 
>> wrote: 
>> > 
>> > 
>> >         On 2019-08-07 11:38 a.m., Mihai Dobrescu wrote: 
>> >>         [Hi all, I continue the discussion here. Mike] 
>> >> 
>> >>         Thank you! The discussion began when I've tried to get more 
>> >>         out of that middle-bottom bush. In your first attempt, you've 
>> >>         got the same crop as me and the bush was cropped too much too. 
>> >>         I find the process of that tuning exactly the same as you do. 
>> >>         Somehow, I've got a similar image. 
>> >> 
>> >>         As for the second attempt, indeed, I think Gimp might be the 
>> >>         solution, but Hugin should be able to apply this process 
>> >>         itself as it seems to be a necessary step in some cases and 
>> >>         mght be useful in panoramas. 
>> >>         I think the code is there, because Hugin morphs individual 
>> >>         images in order to synchronize the control points. 
>> >> 
>> >>         Best Regards. 
>> > 
>> >         Sorry, but as I explained to you in email, the code is _not_ 
>> >         there. Hugin is a dedicated panorama stitcher. It doesn't work 
>> >         by "morphing" individual images. What it does is apply certain 
>> >         global transformations to the input images, using a well 
>> >         established model, in order to match control points in the 
>> >         images as closely as possible. There's no code in there to 
>> >         perform arbitrary transformations of groups of pixels within 
>> the 
>> >         input images, or within the resulting panorama. 
>> > 
>> >         ACR works exactly the same way Hugin does when it comes to 
>> >         stitching: it matches features in the input images by applying 
>> >         global transformations to them. But unlike Hugin, ACR contains 
>> >         additional code which allows it to distort specific parts of 
>> the 
>> >         result. It looks to me like the additional code is basically a 
>> >         limited (and therefore fairly easy to automate) version of 
>> >         Gimp's cage transform tool, dedicated to this one task of 
>> >         filling in empty space around the edges of a stitched image. 
>> > 
>> >         Could the necessary code be added to Hugin? Of course it could! 
>> >         But that would be an enormous amount of work, and I can't see 
>> >         that it would be worth anyone's while to put the effort in. 
>> >         You're probably going to want to edit your panorama in the Gimp 
>> >         or some other general purpose editor, anyway, to fix minor 
>> >         stitching/blending errors, do some color correction, add a bit 
>> >         of sharpening, etc. So why not fix the corners of your panorama 
>> >         while you're at it? 
>> > 
>> >         My advice is to embrace the unix/linux philosophy of using 
>> >         collections of smaller, focused tools to accomplish what you're 
>> >         after. Hugin and the Gimp are both very good at what they do. 
>> >         You can think of them, if you like, as a single combined 
>> >         program: Hugin+Gimp. It's a very powerful combination. Sure, 
>> >         it's a bit less convenient to use than ACR in some respects. 
>> But 
>> >         that's a small price to pay for the freedom to be able to avoid 
>> >         the inflexible and invasive operating systems that companies 
>> >         like Adobe cater to. 
>> > 
>> >         Cheers, 
>> >         BBB 
>> >         -- 
>> >                 Bob Bright 
>> >         Vancouver Island Digital Imaging 
>> >         +1 250 857 9887 
>> >         [email protected] 
>>
>>
>> -- 
>> David W. Jones 
>> [email protected] 
>> wandering the landscape of god 
>> http://dancingtreefrog.com 
>>
>

-- 
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/494b961a-7ff9-4172-81b3-dd3704f24b65%40googlegroups.com.

Reply via email to