From: dmg <dm...@uv...> - 2006-10-25 18:07:09
|
This is my plan for release 3.0.0. I'd like to hear comments and possible things I have missed. "DESIRABLE FEATURES" are those features that I'd like to have in 3.0.0, but are not show stoppers. Any outstanding bugs? If so, we need to classify them and determine those that need to be fixed. MAIN GOAL IN THE SHORT FUTURE: * Create callbacks that hugin can use (and add them to pano13), for all the processing done in panotools, so it does not to run the programs. SHORT TERM: Release 3.0.0 ---------------------------------------------------------------------- PTmender: PTmender should be a lightweight, simple stitching program and nothing else. That means it will only do mapping of the panoramas. In terms of the old PTsticher scripts it means it will only create TIFF_m, cropped, no colour correction. It will be up to the caller application to take these files and create the desired output (apply colour correction, cropping, uncropping, conversion to other formats). This will simplify testing, and improve stability. TODO: - Remove postprocessing logic from it. DESIRABLE FEATURES: - Insert script into the TIFF comment field. - Cleanup command line options, and add a -h option - Process fisheye lenses. - If somebody wants full compatibility with PTstitcher, a new program can be added that does all the work. It will be a "superset" of many of the current pano tools. ---------------------------------------------------------------------- PTblender: It will split into 2 programs: - PTblender. It will do colour correction _only_. - PTroller. It will flatten an image. It will take a set of TIFFs and create only one TIFF TODO: - Split the programs DESIRABLE: - (PTblender) Create photoshop curves and maps for HSV colour corrections - (PTblender) Ignore areas with mask != 255 during computation of the curves, but transform them if mask > 0 - (PTroller) Add the ability to stack and add composing images. ---------------------------------------------------------------------- PTuncrop: - No major changes, except that it will support images without full size tags. TODO: - Add support for images without full size tags --this will affect all panotools) and make sure all tools are compatible with TIFFs output by nona and fulla. ---------------------------------------------------------------------- PTtiff2psd: TODO: - Nothing DESIRABLE: - Specify blending mode for layers ---------------------------------------------------------------------- PTestimate (old PToptimizer) TODO: - Nothing ---------------------------------------------------------------------- DESIRABLE new tools: PTcrop: - Two options: crop to bounding rectangle, and crop to inner rectangle (I think that were the names Pablo gave them). ---------------------------------------------------------------------- LONGER TERM: * Allow tools to read their parameters from the PTstitcher script. * Add support to all the tools for 16 bit, and 32 bit images (it is kind of mixed at this point) -- Daniel M. German "You could wind up belivin' that paradise is nothin' more than a feelin' Marillion -> that goes on in your mind." http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Max L. <max...@ve...> - 2006-10-26 01:54:49
|
> PTmender should be a lightweight, simple stitching program and nothing > else....it means it will only create TIFF_m, > cropped, no colour correction. It will be up to the caller application > to take these files and create the desired output (apply colour > correction, cropping, uncropping, conversion to other formats)... > - If somebody wants full compatibility with PTstitcher, a new program > can be added that does all the work. It will be a "superset" of many > of the current pano tools. I think that the idea of creating small utility programs for subsets of the stitching process is a reasonable idea, but I'd suggest leaving PTMender as the "superset" program. There is about of year's worth of written material on internet forums, web sites, discussion groups, e-mail lists (etc.) describing PTMender as a replacement for PTStitcher. Stripping out a big chunk of its feature set at this point would end up confusing a lot of people. Not to mention those of us who have written a lot of code (GUI programs) and documentation around PTMender. In fact, I've been thinking along these lines, and already created a "PTFinalize" program (mentioned in my posting yesterday) that takes the TIFF_M format and converts it to whatever format (jpg, psd, png, tif, etc.) the user specifies. I did this by reworking the panoCreatePanorama function in PTCommon.c into two functions and writing a new program to take command line arguments and call the new function that converts the TIFF_m images into their final format. I'm happy to contribute this to the repository if folks will find it useful. If this won't fit into the general plan, then I won't contribute it. On a more general level, I'd suggest trying to make as few external changes as possible. Not only does this end up confusing folks, but it probably lessens the chances of adoption. Programs that change names, remove features (and so on) probably don't end up endearing themselves to the average user. In my opinion, of course. Max |
From: Daniel M. G. <dm...@uv...> - 2006-10-27 05:10:39
|
Hi Max, Max> In fact, I've been thinking along these lines, and already created a Max> "PTFinalize" program (mentioned in my posting yesterday) that takes the TIFF_M Max> format and converts it to whatever format (jpg, psd, png, tif, etc.) the user Max> specifies. I did this by reworking the panoCreatePanorama function in Max> PTCommon.c into two functions and writing a new program to take command line Max> arguments and call the new function that converts the TIFF_m images into their Max> final format. I'm happy to contribute this to the repository if folks will Max> find it useful. If this won't fit into the general plan, then I won't Max> contribute it. PTroller (extracted from PTblender) will take a set of TIFFs and create a single TIFF, so PTfinalize should not duplicate this functionality. I think it is a good idea to have a PTfinalize that would: * Take one single TIFF image, and convert it to a desired format: JPEG, PSD, PNG or any obscure format. Hopefully one day we can generate QTVRs. But I'd like to see panotools metadata being preserved in JPEGs. Otherwise imageMagick does a better job at creating JPEGs from TIFFs, and we don't need to waste our time recreating what others do. Max> On a more general level, I'd suggest trying to make as few Max> external changes as possible. Not only does this end up Max> confusing folks, but it probably lessens the chances of Max> adoption. Programs that change names, remove features (and so Max> on) probably don't end up endearing themselves to the average Max> user. In my opinion, of course. This is one of the reasons that I want to do this before the major release. -- Daniel M. German "When asked whether or not we are Marxists, our position is the same as that of a physicist or a biologist who is asked if he is a `Newtonian', or if Che Guevara -> he is a `Pasteurian'" http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Pablo d'A. <pab...@we...> - 2006-10-26 19:34:48
|
Hi all, Daniel M. German schrieb: > This is my plan for release 3.0.0. I'd like to hear comments and > possible things I have missed. > > > MAIN GOAL IN THE SHORT FUTURE: > > * Create callbacks that hugin can use (and add them to pano13), for > all the processing done in panotools, so it does not to run the > programs. While in general, this is a good idea, the question is what functionality needs to be available in hugin? Do we need a complete, real life preview with the effect of color correction etc? Maybe the main question is if hugin should call the external programs for final rendering, or should it use the routines in libpano13 directly. I still don't have a real feeling for what should be better. Most end-users would probably like don't care how its done, if it only works, while some experts will probably remap the panos or just write out a panotools script and then use the commandline or their own scripts for further processing. Also, on the hugin side, some work is needed, because I do not use the sometimes strange libpano12 internal data structures for storing the panorama state and images (Instead hugin uses own classes, which also have become bloated over time..). I have a function to fill the data structures so far that I can create the coordinate transforms, but currently, thats it. > SHORT TERM: Release 3.0.0 > > ---------------------------------------------------------------------- > PTmender: > > > DESIRABLE FEATURES: > > - Insert script into the TIFF comment field. > > - Cleanup command line options, and add a -h option > > - Process fisheye lenses. > > - If somebody wants full compatibility with PTstitcher, a new program > can be added that does all the work. It will be a "superset" of many > of the current pano tools. Hmm, as Max has noticed, changing the interface of the tools extensively has to be well thought out. While I personally don't have a problem with a bare bones PTmender, some people might be surprised. Hmm, maybe renaming the stripped down PTmender to PTremap, and providing some shell script/frontend application with a superset of PTmenders and PTStitchers functionality, if possible? > ---------------------------------------------------------------------- > > PTblender: > > DESIRABLE: > > - (PTblender) Create photoshop curves and maps for HSV colour > corrections For people without photoshop or if somebody wants to run enblend on them, it might be a good idea to provide an option to write out the recolored images. > - (PTroller) Add the ability to stack and add composing images. I assume this will then just apply the curves file created by PTblender, right? > DESIRABLE new tools: > > PTcrop: > > - Two options: crop to bounding rectangle, and crop to inner rectangle > (I think that were the names Pablo gave them). I'm not sure if inner rectangle was a good description. ;-) Some of that functionality would be a good thing to have. > ---------------------------------------------------------------------- > LONGER TERM: > > * Allow tools to read their parameters from the PTstitcher script. Actually I think the PTstitcher scripts are a bit messy to parse, and especially they are hard to extend nicely. Switching to some better formated alternative, like an windows .ini file, or maybe even an xml document might also be something that should be considered for the future. > * Add support to all the tools for 16 bit, and 32 bit images (it is > kind of mixed at this point) I assume with 32 bit you mean float? That might be a bit tricky for PTblender. ciao Pablo |
From: Max L. <max...@ve...> - 2006-10-27 04:12:58
|
> Max wrote: > I think that the idea of creating small utility programs for subsets of > the stitching process is a reasonable idea, but I'd suggest leaving > PTMender as the "superset" program. There is about of year's worth of > written material on internet forums, web sites, discussion groups, e-mail > lists (etc.) describing PTMender as a replacement for PTStitcher. > Stripping out a big chunk of its feature set at this point would end up > confusing a lot of people. > Pablo wote: > Hmm, as Max has noticed, changing the interface of the > tools extensively has to be well thought out. While I personally don't > have a problem with a bare bones PTmender, some people might be > surprised. > Daniel wrote: > So PTmender is deprecated, PTremap will take its place. Is this the final consensus that we've reached, or is this still open for discussion? When you say deprecated, what does that mean? Will it be removed, and I should get ready to rewrite all the documentation and PTAssembler code to deal with some other program? Or, will it just languish in a state of neglect until it becomes so outdated as to be useless/incompatible with newer code? Or, will PTMender continue to exist as the superset program that calls PTRemap and PTFinalize (or whatever the individual utility programs are called)? Or, something else? My own suggestion for a "roadmap" is as follows: Take the logic in PTCommon and break it into two functions...one that does the remapping, and one that does the image finalization (flattening, feathering, etc.). Create two new programs (PTRemap and PTFinalize) that call each of these two functions. Then, restructure PTMender so that it calls the remapping and the finalizing code in sequence. This way, PTMender would retain its existing features (and not confuse anyone or break existing code that depends on it), and we'd have two new utility programs as suggested in Daniel's earlier message. Max |
From: Daniel M. G. <dm...@uv...> - 2006-10-27 05:10:39
|
Max Lyons twisted the bytes to say: >> Daniel wrote: >> So PTmender is deprecated, PTremap will take its place. Max> Is this the final consensus that we've reached, or is this still open for Max> discussion? It is still open for discussion. Max> When you say deprecated, what does that mean? Will it be Max> removed, and I should get ready to rewrite all the documentation Max> and PTAssembler code to deal with some other program? Are you talking as the open source developer or as a tawbaware developer? I am paraphrasing you. Perhaps it will be important to clarify. In my opinion, if you want PTstitcher compatibility there is nona. If you want features found in PTblender then call nona, then PTblender. If you really need PTremap, well, you can call it too. If you really want a PTmender, would you be willing to maintain it? Max> Or, will it just languish in a state of neglect until it becomes Max> so outdated as to be useless/incompatible with newer code? Open source tools languish only when no open source developer cares for them. Here is where you can make a difference. You can continue to maintain a tool for as long as you (or tawbaware) want. pano12 or PTmender will not languish if you keep maintaining them, for instance. Max> Take the logic in PTCommon and break it into two functions...one Max> that does the remapping, and one that does the image Max> finalization (flattening, feathering, etc.). Create two new Max> programs (PTRemap and PTFinalize) that call each of these two Max> functions. Then, restructure PTMender so that it calls the Max> remapping and the finalizing code in sequence. This way, Testing PTmender has always being a pain to maintain, and almost nobody (including you) seem to care to contribute to the creation of a test suite. The number of potential execution traces grows dramatically as we add more features to it. dmg -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Max L. <max...@ve...> - 2006-10-27 12:51:12
|
> >> Daniel wrote: > >> So PTmender is deprecated, PTremap will take its place. > > Max> When you say deprecated, what does that mean? > Are you talking as the open source developer or as a tawbaware > developer? I am paraphrasing you. > In my opinion, if you want PTstitcher... > If you really want a PTmender, would you be willing to maintain it? > Open source tools languish only when no open source developer cares > for them. Here is where you can make a difference. You can continue... > Testing PTmender has always being a pain to maintain, and almost > nobody (including you) seem to care to contribute... Yes. However, I'm not sure I saw an answer to my original question in there. Would it be fair to say that the answer to what you had in mind when you declared that PTMender would be "deprecated" is that you won't rework PTMender into something different than it is now (i.e. remove existing features), but you will stop further development on it in favor of other tools (PTRoller, PTRemp, etc.)? Thanks, Max |
From: Jim W. <jwa...@ph...> - 2006-10-27 13:33:05
|
Max Lyons wrote: > Would it be fair to say that the answer to what you had in mind when you declared > that PTMender would be "deprecated" is that you won't rework PTMender into > something different than it is now (i.e. remove existing features), but you > will stop further development on it in favor of other tools (PTRoller, PTRemp, > etc.)? > > Thanks, > > Max > I have been out of the loop of things for too long. I do like the idea of the individual tools to do things. But I we also need the PTStitcher replacement. When the replacement was started I was imaging something not much more complicated than what PTOptimizer. It just takes the script and calls the right functions in the pano12 library. I do not want to see duplicated code everywhere for similar tools. I would like to see most of the code in the library. I have not had a chance to look at the code in a long time and this may be the case. The difference between tools that knows how to do one thing or a tools that can do many things in sequence should not be that different. I would also like all the tools released statically linked to PanoTools. If this is the case then it should be fairly easy to maintain all the tools. It is true that PanoTools library may need some of the code separated into a different library for file handling but this is a different discussion. -- Jim Watters jwatters @ photocreations . ca http://photocreations.ca |
From: Daniel M. G. <dm...@uv...> - 2006-10-27 16:13:13
|
Max Lyons twisted the bytes to say: >> >> Daniel wrote: >> >> So PTmender is deprecated, PTremap will take its place. >> Max> When you say deprecated, what does that mean? >> Are you talking as the open source developer or as a tawbaware >> developer? I am paraphrasing you. >> In my opinion, if you want PTstitcher... >> If you really want a PTmender, would you be willing to maintain it? >> Open source tools languish only when no open source developer cares >> for them. Here is where you can make a difference. You can continue... >> Testing PTmender has always being a pain to maintain, and almost >> nobody (including you) seem to care to contribute... Max> Yes. Max> However, I'm not sure I saw an answer to my original question in there. Would Hi Max, Neither you answer my questions. Max> it be fair to say that the answer to what you had in mind when you declared Max> that PTMender would be "deprecated" is that you won't rework PTMender into Max> something different than it is now (i.e. remove existing features), but you Max> will stop further development on it in favor of other tools (PTRoller, PTRemp, Max> etc.)? As of today, PTmender does not do any post-processing. It will be modified to print a notice to direct users to use PTremap. I will continue the development of the rest of the tools. In terms of features, the only cumulative loss is that PTtools will not generate JPEgs or PNG. If you (or tawbaware) are serios about maintaining PTmender create a branch in SVN, and add the code there (or hire somebody to do it--not me). Create a framework that supports testing of all the combinations (not necessarily tests for it) and then we will discuss its inclusion back into the tools. It would also be nice if you add fisheye support and feathering too (not that difficult, really). dmg -- Daniel M. German "there is nothing more to know; but in a scientific pursuit Mary Shelley (Frankenstein) -> there is continual food for discovery and wonder." http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Daniel M. G. <dm...@uv...> - 2006-10-26 23:35:05
|
Pablo> Maybe the main question is if hugin should call the external programs for Pablo> final rendering, or should it use the routines in libpano13 directly. I Pablo> still don't have a real feeling for what should be better. Most end-users Pablo> would probably like don't care how its done, if it only works, while some Pablo> experts will probably remap the panos or just write out a panotools script Pablo> and then use the commandline or their own scripts for further processing. I agree, for that reason I think that using nona is good enough for non-case users. PTtools is really intended for powerusers. Pablo> Hmm, as Max has noticed, changing the interface of the tools extensively has Pablo> to be well thought out. While I personally don't have a problem with a bare Pablo> bones PTmender, some people might be surprised. Hmm, maybe renaming the Pablo> stripped down PTmender to PTremap, and providing some shell script/frontend Pablo> application with a superset of PTmenders and PTStitchers functionality, if Pablo> possible? I agree with Pablo and Max and I think I made a mistake on renaming PToptimizer. I am going to undo that change. So PTmender is deprecated, PTremap will take its place. >> ---------------------------------------------------------------------- >> >> PTblender: >> >> DESIRABLE: >> >> - (PTblender) Create photoshop curves and maps for HSV colour >> corrections Pablo> For people without photoshop or if somebody wants to run enblend on them, it Pablo> might be a good idea to provide an option to write out the recolored images. Sorry, I meant to say that PTblender will continue processing cropped TIFFs and generating cropped TIFFs as it does today. I am not removing any feature of it. PTBlender will: * Compute colour correction and/or * It will compute stitching masks >> - (PTroller) Add the ability to stack and add composing images. Pablo> I assume this will then just apply the curves file created by PTblender, right? No. that will be done in PTblender. PTroller will create one single output TIFF from a set of TIFFs. * It will flatten the images * It will output one single cropped TIFF per job. >> DESIRABLE new tools: >> >> PTcrop: >> >> - Two options: crop to bounding rectangle, and crop to inner rectangle >> (I think that were the names Pablo gave them). Pablo> I'm not sure if inner rectangle was a good description. ;-) Pablo> Some of that functionality would be a good thing to have. >> ---------------------------------------------------------------------- >> LONGER TERM: >> >> * Allow tools to read their parameters from the PTstitcher script. Pablo> Actually I think the PTstitcher scripts are a bit messy to parse, and Pablo> especially they are hard to extend nicely. Switching to some better formated Pablo> alternative, like an windows .ini file, or maybe even an xml document might Pablo> also be something that should be considered for the future. >> * Add support to all the tools for 16 bit, and 32 bit images (it is >> kind of mixed at this point) Pablo> I assume with 32 bit you mean float? That might be a bit tricky for PTblender. Yeap. I totally agree it might be difficult to do with PTblender. -- Daniel M. German "The best computer is a man, and it's the only one that can be mass-produced W. Von Braun -> by unskilled labor." http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Daniel M. G. <dm...@uv...> - 2006-10-27 00:47:03
|
Daniel> I agree, for that reason I think that using nona is good enough for Daniel> non-case users. PTtools is really intended for powerusers. Sorry, I meant to say: "nona is good enough for casual users". -- dmg |