From: Jim W. <jim...@ro...> - 2005-10-22 04:25:35
|
Newsworthy changes in 2.7.0.11 ------------------------------ Do not process unchanged color channels for CA correction. Correctly open BMP files created with rows in reverse order. Added antialiasing filters. Added support for 32bit float files ( but not with PTStitcher) I have committed the above changes to to SourceForge. More details below. I have only built on 32bit Windows so test on other platforms. -------------------------------------------------------------- Robart Pratt's - Do not process unchanged color channels for CA correction. Lets consider a,b,c,d radial correction parameters for colors RGB. If R==G==B, then clearly we can do the transform for all 3 colors at the same time. This is unchanged. If R!=G, G!=B, R!=B, then we clearly need to run the transform 3 times: once for each color. This is also unchanged. However, for CA correction, it may be enough to change the parameters of just 1 color to be different rom the other 2 channels. This gives several cases: - 2 of the 3 color channels have a,b,c,d == {0,0,0,1}. That is, there is NO CHANGE to those two color channels AT ALL. The 3rd color channel has a,b,c,d != {0,0,0,1}, and therefore requires remapping. In this case, we only need to run the transform ONCE to remap the one channel. - 2 of the 3 color channels have the exact same a,b,c,d parameters, and the 3rd channel has a,b,c,d == {0,0,0,1}. Again, we can run the transform just once, transforming the two identical colors simultaneously. The 3rd channel has no change at all. A more common case is when we are removing barrel/pincushion/mustache distortion at the same time as CA: - none of the 3 channels have a,b,c,d=={0,0,01}, however 2 of the 3 color channels have the exact same a,b,c,d paras. The third channel as different a,b,c,d paras. In this case we need to do just 2 transformations: once to transform two colors exactly the same, once to transform the 3rd (different) color. Thomas Rauscher,s antialiasing filters. http://www.pano2qtvr.com/dll_patch/ Antialiasing filters now support 8, 16 and 32!!! bit and filters for different color channels. I tried some improvements (cached filter values...), but they all messed up the code, and didn't make it much faster (~3%) so I kept the original code. I also added a list of all filters to the "QueryFeatures". Maybe I have some ideas in the future, but for now I think the filters are ready to be released! Thomas Rauscher,s 32bit float. http://www.pano2qtvr.com/dll_patch/ I also patched the tiff.c to support 32bit float files within the PanoTools. The major problem is, that no other software can use this! It would be also hard to modify the old filters, to match the 32bit format. I am not sure, if this make sense. It looks like, that PTStitcher has the memory allocation hard coded, because it always crashes, when I try to use it. Pano2QTVR works fine without modifications, so I think PTStitcher is the problem. Also PTGui doesn't use the pano12.dll any more, so this is also not an improvement. queryfeature has been updated to reflect above additions/changes. Also added NumPanoTypes and PanoType# to return the number of types of output formats that panotools supports and their names to allow current apps to use future formats. -- Jim Watters Graphic Software Developer http://photocreations.ca |
From: Bruno P. <br...@po...> - 2005-10-24 14:15:25
|
On Sat 22-Oct-2005 at 00:25 -0400, Jim Watters wrote: > > I have committed the above changes to to SourceForge. More details > below. I have only built on 32bit Windows so test on other platforms. It builds ok on linux x86_64 and win32 MinGW. Seems to work as before though I haven't tested the new functionality. -- Bruno |
From: Bruno P. <br...@po...> - 2005-10-25 22:49:23
|
On Mon 24-Oct-2005 at 14:49 +0100, Bruno Postle wrote: > > It builds ok on linux x86_64 and win32 MinGW. Seems to work as > before though I haven't tested the new functionality. ..and it builds ok on i386 linux (fedora fc4). The new library doesn't seem to break PTOptimizer, PTStitcher, hugin or nona. I tried one of the new antialiasing filters with the old linux PTStitcher binary and it works nicely, though very slow. So I've tagged CVS with 'release-2-7-0-11' and uploaded archives to sourceforge: http://sourceforge.net/project/showfiles.php?group_id=96188 Jim, are you going to build a fresh PANO12.DLL? This is the file that people actually want to download. -- Bruno |
From: Thomas R. <pa...@at...> - 2005-10-25 23:36:28
|
Hello Bruno, on Wednesday, October 26, 2005, 00:49:16 you wrote: BP> I tried one of the new antialiasing filters with the old BP> linux PTStitcher binary and it works nicely, though very slow. Yes, I know they are very slow... they work with brute force, but I had about 150 downloads for the DLL on my site, so I thought, this should go now into the official DLL, because I don't like to make a branch out of this... I have some ideas to make it faster, but this would take time, and I am very busy right now with other things. MfG, Thomas. |
From: Jim W. <jwa...@ph...> - 2005-10-26 02:06:20
|
Not sure if it was quite ready to release. - I also want to include Rob Platt's changes for multiprocessor support. - There is still more that can be done to support 32bit floating point - I did not get some recent (minor) changes from Thomas Rauscher committed to just now. I (Thomas) added the dual-color modes to the transform_aa (and cleaned the code, I rename 4 variables...) - The Change Log file did not get updated. - I still have not found out why some are having problems with my .10 release but .9 is ok. I have updated the image librarys I am building with, and maybe it will go away. But maybe most of that should all wait for .12. The multiprocessor may cause problems and take time to implement a cross platform solution. The plugins will also need to be updated if they are to support 32bit floating point. I tried the last two days creating huge tiff projects to recreate the crash people are having. Both times I ended up with only a 8 byte tiff file. No error messages or crashes. My machine with .75GB of memory. Windows automaticaly increased the paging size to 1.7GB to handle it. 16 images to create 15000 X 7500 worked fine. 10 plus hours mostly in Enblend. 8 images to create 26000 X 13000 did not. 2.5 hours Currently I have turned off Enblend and trying 6 images to create 22000 X 11000 and see what happens. This time I get Error allocating 945312 KB of memory when starting the "Preparing Stitching Masks" stage, which is the size of the temporary tiff files created. Gave me time to build a release build and test it quickly. http://photocreations.ca/panolools/pano12-2.7.11.zip Also uploaded it to SourceForge. My build includes Thomas changes. Now to work on ver .12 ..... ( multi processor and 32bit floating point here we come) .... As soon as I update my web page I will post a message on the panotools email list. Jim Watters Graphic Software Developer http://photocreations.ca Bruno Postle wrote: >On Mon 24-Oct-2005 at 14:49 +0100, Bruno Postle wrote: > > >>It builds ok on linux x86_64 and win32 MinGW. Seems to work as >>before though I haven't tested the new functionality. >> >> > >..and it builds ok on i386 linux (fedora fc4). > >The new library doesn't seem to break PTOptimizer, PTStitcher, hugin >or nona. I tried one of the new antialiasing filters with the old >linux PTStitcher binary and it works nicely, though very slow. > >So I've tagged CVS with 'release-2-7-0-11' and uploaded archives to >sourceforge: > > http://sourceforge.net/project/showfiles.php?group_id=96188 > >Jim, are you going to build a fresh PANO12.DLL? This is the file >that people actually want to download. > > > -- Jim Watters Graphic Software Developer http://photocreations.ca |
From: Bruno P. <br...@po...> - 2005-10-26 20:13:57
|
On Tue 25-Oct-2005 at 22:05 -0400, Jim Watters wrote: > Not sure if it was quite ready to release. Oops, it seemed like a good idea at the time. If it turns out to be flakey then we can always release a 2.7.0.12 soon after. I just tried uploading the unzipped pano12.dll file, but sourceforge doesn't seem to be happy today. -- Bruno |
From: Florent B. <fl...@sa...> - 2005-10-24 14:56:42
|
Le Samedi 22 Octobre 2005 06:25, Jim Watters a =E9crit : [...] > I have committed the above changes to to SourceForge. More details > below. I have only built on 32bit Windows so test on other platforms. [...] Build ok on x86 with Debian sid (gcc/g++ 4.0). I haven't tested yet if it=20 works. =2D-=20 =46lorent |