Wish List for APP1.4 #2  

Got some great idea or a feature request? Post it here and discuss it. The most requested concepts are usually implemented, as Autopano Pro / Giga is very community driven.
no avatar
touristguy87
Member
 
Topic author
Posts: 234
Likes: 0 post
Liked in: 0 post
Joined: Mon Feb 09, 2009 9:45 pm
Info

Wish List for APP1.4 #2

by touristguy87 » Tue Feb 17, 2009 5:16 am

Ok after some consideration and discussion, my personal wish-list for APP has been whittled down a bit but still retains a number of core items:

with regard to the pano autodetection routine
Which is really the main reason to use APP in my estimation

these are mostly related to the autodetection routine but there are some "bugs" in the implementation of the editor, I'll get to that shortly
but first...


*******it's important to be able to do this globally as much as possible, not to have to go into the editor for each pano and set the options there***********

also the global settings should take precedence over the same settings in the pano-config file, otherwise the global settings are meaningless,
and then of course one has to actually double-check ALL the settings before rendering the pano...for each pano rendered,
instead of just checking the global settings once
It is bad enough that I have to tell it to go ahead and render the pano for each pano even if I click the global render button,
to have to check the settings each time I render each pano each time I render panos in APP
is quite tedious and defeats the purpose of both the global-settings and the pano-config file

...It's not even clear if saving the batch configuration and just rerunning *that* will get past this...

1-APP will not automatically scan across multiple folders for files to put into one pano-group. At least on cursory examination, all of the files in a group will be from one folder.

2-it would be nice if it would consider the whole tree as one group, short of some UI option to base groups on individual folders.
Or have some way to include multiple folders in a scan, by picking them manually. Some combination of this would be great, that way I wouldn't have to resort my files just to make it possible for APP to find panos that span files that were originally in different folders.

3-in general it simply adds too many files to a pano. In this regard I would like to see
a: a switch to keep it from "stacking" exposures
'b: a switch to make it not use longer focal length shots when a shorter focal-length shot will do
c: likewise for shots at higher shutter speeds at a given focal length
-I would prefer for it to calculate a shutter-time*focal length product and use that as the selection criteria, when shots of slightly different exposures are available that cover
the same part of the pano, likewise it should not use shots with blown-out highlights or high-ISO noise when a shot with a better exposure and/or less noise is available
d: some sort of user-priority chart for ISO, FL, shutter-speed and exposure would be great
e: it should be smart enough to not end up with panos that use 60 shots when only a handful are necessary to cover the FOV
(maybe this is a "feature" of smartblend, but still, if nothing is "moving" in the shots then drop the redundant images...imagine how painful it is to do this by hand in the editor)

4 a global control that would set the minimum MP of the panos that it finds, relative to the largest source image used.
it should be smart enough to not make panos that are barely any bigger than any of the original images, in terms of FOV

5 a control that will limit the *maximum* MP of the source-files used for panos, so that it will not try to make panos out of panos.
(if the file name contains the word 'pano' it won't try to use that file to make a pano, of course one could select *only* files with the word pano in them etc)

6 some sort of exclusion logic so that you can put flags in the file names and it won't use those files for making panos.
Also a filter for file type

7: some way to turn off the "contrast optimization" logic globally (right now that can't be done, the AL can be disabled but not the "contrast-optimization")

8: raise the maximum MP limit and rate it as a percentage of system ram, right now it seems to be limited to about 1/3rd of total system ram.
I want APP to use as much memory as it needs to autodetect and render panos quickly, if I want it to, it should be allowed to grow as large as possible to use up the available memory
and avoid any unnecessary disk i/o which will slow it down (and not rely on the system cache to do this)
Please make the slider 0-100% of real memory not 0-100% of the amount of system ram that you will allow APP to use

9 make it so that it has an internal ramdrive for smartblend cache, so that I don't have to set up one for APP to use as a temp folder
(which is much faster than using raid0 and works fine for panos of moderate MP)

10 fix it so that it doesn't double-prerender the pano when loading the pano config file and again when opening the editor.
Also it re--prerenders if the level control is open and closed...even if nothing was done there.
It will re-prerender if a file is unchecked and then rechecked immediately, so there is no delay-time that it waits before re-prerendering
Likewise there is no way to abort the prerender if one clicks on the editor button by mistake or merely wishes to close the editor window without saving the changes.
Or just stops the prerender for some reason, like they don't need to see it before saving the pano config file or they want to make additional changes and *then* prerender
(please don't tell me that that has to be done after each change, it doesn't, and even if it should be done there are times when I don't want it to be done
again please do not assume that the hardware will be capable of running the GPU prerender and doing it in 0.1s or even that "it will just take a few seconds even in cpu mode"...
if I want it to prerender I will be happy to tell it to prerender and when I want it to stop prerendering I want it to stop right that instant, not 2 minutes later)

11 just a concern at the moment the 1.9alpha doesn't have a global way to reduce the quality of the prerender, that definitely needs to be in the production version.
Not everyone will have graphics cards that can support the GPU prerendering and reducing it to the min quality halves the prerender time on my machine

11a put in a slider to control the size of the thumbnails in the editor (globally) whoever designed the editor, it looks like it was done at 1MP resolution or smaller maybe
11b please add the file date& time to the exif info listed in the editor
11c in the alpha there is an option to group the files by FL, this is nice but the groupings are too tight. The delta is very small. Why not make this a global option...percent maybe.
Or...look for large variations in FL and group them in clusters.
That way if there is a continuous spacing of FL they would all be in one group not in 32 different groups each with 2 or 3 images.

12 fix the batch renderer so that jobs can be added to the batch without actually running the batch.
12a please fix the kill buttons so that they actually kill the batch without requiring me to go into TM and kill it manually

13 some sort of command-line mode would be nice, so that panos can be rendered automatically from config files without firing up the APP software in a window

14 it would be nice to be able to scale the panos by MP not by percent or by dimensions and/or dpi...to simply be able to fix the dpi and the maximum MP for all the panos
14a please fix it so that I don't have to restart APP for it to take the configuration options
14b likewise it should not "automatically" switch the temp *drive* just because it doesn't see the specified temp *folder*...just have it remake the folder & switch the temp drive
only as a last resort (if it isn't actually available) and switch it back if it *becomes* available later
14c ...why can't it use more than one temp folder, so if the first one fills up it can run the batch on the 2nd one, instead of aborting the batch and sitting there stupidly?

15 why can it not automatically close the groups when autodetecting panos with the auto config & save box checked? Once the pano config files are made that pano is gone
from the system. Only modifying the groups and re-detecting would change the results, and that would be saved in a new pano file. But there is no way to save the groups.
In this mode the groups should be saved (and automatically closed) as well as the pano-config files.

16 it would be very nice to have a global setting so that the panos are created and stored in the same folder that the source files were in. (with a /pano subdirectory, maybe)...right now I just copy both the config files and the panos to the source directory after they are done

17 it is possible to have the pano config file automatically include the dimensions but not the resolution in MP, this would be very nice so that one can quickly see the size
of the pano that is produced with that pano config file.

18: ...is there no way to have the smartblend fix straight lines in the non-planar perspectives? If an image-processor can do barrel and pincushion corrections, why can't APP
do that for the perspectives which will distort straight lines? Yes I know that non-planar projections tend to not produce straight lines but it seems that this is something
that can be corrected.

18b the auto-horizon tool doesn't seem to work very well. It seems that if one starts with lines in the original images it shouldn't be too hard to make sure that those
same lines have the same orientation relative to each other in the final pano. It's not bad but the panos all seem to need *slight* modification in this regard, the horizon
is slightly bowed one way or the other, if the whole pano isn't slightly rotated. Getting it 90% right 90% of the time is useful but hardly consistent with the whole theory that
"quality comes first".

Put all these together and APP is sort of like using a pipe-wrench to tighten a nut. You can get them tight but they're going to be slightly stripped and you're going to have to come back with a torque wrench and do it right, and of course you can't actually put the nuts *on* with a pipe-wrench, either. But it's better than using your fingers or a pair of pliers.

Other than that I'm pretty happy with APP. It's just not very efficient and requires quite a bit of file moving around, hand-sorting of images, weeding of the autodetected pano config files, to get it to work well. But at least it does autodetect panos and saves their configurations in individual files, which is a big step.

thanks & good luck with all this :)
Last edited by touristguy87 on Tue Feb 17, 2009 6:16 am, edited 1 time in total.

no avatar
touristguy87
Member
 
Topic author
Posts: 234
Likes: 0 post
Liked in: 0 post
Joined: Mon Feb 09, 2009 9:45 pm
Info

by touristguy87 » Tue Feb 17, 2009 5:45 am

ps

no "haters"

please

and to you "sysadmins"

please do not move my thread out of this group before anyone who actually *writes* APP code has had a chance to read it

like you did the last time
Last edited by touristguy87 on Tue Feb 17, 2009 5:46 am, edited 1 time in total.

User avatar
AlexandreJ
Kolor Team
 
Posts: 5987
Likes: 7 posts
Liked in: 10 posts
Joined: Mon Nov 14, 2005 4:56 pm
Location: Francin, France
Info

by AlexandreJ » Tue Feb 17, 2009 11:10 am

Great ! a resume. I was a bit worried to read the full previous thread :(

touristguy87 wrote:*******it's important to be able to do this globally as much as possible, not to have to go into the editor for each pano and set the options there***********
also the global settings should take precedence over the same settings in the pano-config file, otherwise the global settings are meaningless,
and then of course one has to actually double-check ALL the settings before rendering the pano...for each pano rendered,
instead of just checking the global settings once
It is bad enough that I have to tell it to go ahead and render the pano for each pano even if I click the global render button,
to have to check the settings each time I render each pano each time I render panos in APP
is quite tedious and defeats the purpose of both the global-settings and the pano-config file

This is not the way the settings works in autopano. It has another spirit, but the results are just the same. Let me explain :
Global settings are in fact "Default values". Every new panorama will have those values as startup value.
So if you change anything in the global settings, it will be used in any new group or panorama created but not on the currently opened one.

You can then decide to override any settings on an individual group for example.

touristguy87 wrote:1-APP will not automatically scan across multiple folders for files to put into one pano-group. At least on cursory examination, all of the files in a group will be from one folder.

True. I seems logical for me because if images are in different folder, there must be a good reason.
Now, we can imagine to create checkbox that says if a folder is a separator for groups or not.

touristguy87 wrote:2-it would be nice if it would consider the whole tree as one group, short of some UI option to base groups on individual folders.
Or have some way to include multiple folders in a scan, by picking them manually. Some combination of this would be great, that way I wouldn't have to resort my files just to make it possible for APP to find panos that span files that were originally in different folders.

Complicate to code the selection of a tree hierarchie. Solution, drag'n'drop the right selection from explorer ( or finder ) to APP.

touristguy87 wrote:3-in general it simply adds too many files to a pano. In this regard I would like to see
a: a switch to keep it from "stacking" exposures
b: a switch to make it not use longer focal length shots when a shorter focal-length shot will do
c: likewise for shots at higher shutter speeds at a given focal length
-I would prefer for it to calculate a shutter-time*focal length product and use that as the selection criteria, when shots of slightly different exposures are available that cover
the same part of the pano, likewise it should not use shots with blown-out highlights or high-ISO noise when a shot with a better exposure and/or less noise is available
d: some sort of user-priority chart for ISO, FL, shutter-speed and exposure would be great
e: it should be smart enough to not end up with panos that use 60 shots when only a handful are necessary to cover the FOV
(maybe this is a "feature" of smartblend, but still, if nothing is "moving" in the shots then drop the redundant images...imagine how painful it is to do this by hand in the editor)

That part is really not something for the detection stage, but for the rendering. I talked already about that, but we are rewritting smartblend to something really better
that is able make such decision ( pixels from long focal have a higher priority than those from shoter focal length ).
The decision of taking or not an image during detection is just not possible, it's really at the end of the process that we can do something clever.

touristguy87 wrote:4 a global control that would set the minimum MP of the panos that it finds, relative to the largest source image used.
it should be smart enough to not make panos that are barely any bigger than any of the original images, in terms of FOV

I didn't get this one.

touristguy87 wrote:5 a control that will limit the *maximum* MP of the source-files used for panos, so that it will not try to make panos out of panos.
(if the file name contains the word 'pano' it won't try to use that file to make a pano, of course one could select *only* files with the word pano in them etc)
6 some sort of exclusion logic so that you can put flags in the file names and it won't use those files for making panos.
Also a filter for file type

feature proposal : "an exclude filter based on name for the browse dialog box" ?

touristguy87 wrote:7: some way to turn off the "contrast optimization" logic globally (right now that can't be done, the AL can be disabled but not the "contrast-optimization")

I don't agree. Contrast optimization is called "auto level" ( not a good term in fact ) and we'll keep the constrat of original pictures ( except perhaps for 1/255 pourcentage, we
found a bug and the value can slide of one 1/255 ).

touristguy87 wrote:8: raise the maximum MP limit and rate it as a percentage of system ram, right now it seems to be limited to about 1/3rd of total system ram.
I want APP to use as much memory as it needs to autodetect and render panos quickly, if I want it to, it should be allowed to grow as large as possible to use
up the available memory and avoid any unnecessary disk i/o which will slow it down (and not rely on the system cache to do this)
Please make the slider 0-100% of real memory not 0-100% of the amount of system ram that you will allow APP to use

Memory managment is not that easy and just changing the limits of the max memory won't help much if the algorithms are not designed for.
This part is definitively related to the new smartblend I talked before.

touristguy87 wrote:9 make it so that it has an internal ramdrive for smartblend cache, so that I don't have to set up one for APP to use as a temp folder
(which is much faster than using raid0 and works fine for panos of moderate MP)

=> Smartblend 2

touristguy87 wrote:10 fix it so that it doesn't double-prerender the pano when loading the pano config file and again when opening the editor.
Also it re--prerenders if the level control is open and closed...even if nothing was done there.
It will re-prerender if a file is unchecked and then rechecked immediately, so there is no delay-time that it waits before re-prerendering
Likewise there is no way to abort the prerender if one clicks on the editor button by mistake or merely wishes to close the editor window without saving the changes.
Or just stops the prerender for some reason, like they don't need to see it before saving the pano config file or they want to make additional changes and *then* prerender
(please don't tell me that that has to be done after each change, it doesn't, and even if it should be done there are times when I don't want it to be done
again please do not assume that the hardware will be capable of running the GPU prerender and doing it in 0.1s or even that "it will just take a few seconds even in cpu mode"...
if I want it to prerender I will be happy to tell it to prerender and when I want it to stop prerendering I want it to stop right that instant, not 2 minutes later)

The prerender doesn't just do prerendering. There are some computations that cannot just be disabled here. We did quite everything we could to recompute just what's needed and not
more, but there are cases where you just need to do the process. But now, with GPU processing, everything is far faster and real time.

touristguy87 wrote:11 just a concern at the moment the 1.9alpha doesn't have a global way to reduce the quality of the prerender, that definitely needs to be in the production version.
Not everyone will have graphics cards that can support the GPU prerendering and reducing it to the min quality halves the prerender time on my machine
11a put in a slider to control the size of the thumbnails in the editor (globally) whoever designed the editor, it looks like it was done at 1MP resolution or smaller maybe
11b please add the file date& time to the exif info listed in the editor
11c in the alpha there is an option to group the files by FL, this is nice but the groupings are too tight. The delta is very small. Why not make this a global option...percent maybe.
Or...look for large variations in FL and group them in clusters.
That way if there is a continuous spacing of FL they would all be in one group not in 32 different groups each with 2 or 3 images.

11, 11a :
in GPU mode : everything is dynamic ( thumbnails used, quality of rendering, etc). No need of any settings here.
in CPU mode : you still have the preview render size to control the speed of prerendering
11b : easy to do
11c : known bug I still have to fix.

touristguy87 wrote:12 fix the batch renderer so that jobs can be added to the batch without actually running the batch.
12a please fix the kill buttons so that they actually kill the batch without requiring me to go into TM and kill it manually

Will be part of the rendering code rewrite for v2.1 and Smartblend 2.

touristguy87 wrote:13 some sort of command-line mode would be nice, so that panos can be rendered automatically from config files without firing up the APP software in a window

No. This is autopano server and will never be part of standalone products, pro or giga.

touristguy87 wrote:14 it would be nice to be able to scale the panos by MP not by percent or by dimensions and/or dpi...to simply be able to fix the dpi and the maximum MP for all the panos
14a please fix it so that I don't have to restart APP for it to take the configuration options
14b likewise it should not "automatically" switch the temp *drive* just because it doesn't see the specified temp *folder*...just have it remake the folder & switch the temp drive
only as a last resort (if it isn't actually available) and switch it back if it *becomes* available later
14c ...why can't it use more than one temp folder, so if the first one fills up it can run the batch on the 2nd one, instead of aborting the batch and sitting there stupidly?

14: a MP slider instead of a percent slider ... Hum, not convinced.
14a: See point explaination
14b: I don't really understand that one
14c: multiple temp folder is planned for v2.1

touristguy87 wrote:15 why can it not automatically close the groups when autodetecting panos with the auto config & save box checked? Once the pano config files are made that pano is gone
from the system. Only modifying the groups and re-detecting would change the results, and that would be saved in a new pano file. But there is no way to save the groups.
In this mode the groups should be saved (and automatically closed) as well as the pano-config files.

In autopano Giga, a workspace is planned to allow to load and save groups with their settings. Now, closing groups after detection ... why not. Never thought of it.

touristguy87 wrote:16 it would be very nice to have a global setting so that the panos are created and stored in the same folder that the source files were in. (with a /pano subdirectory, maybe)...right now I just copy both the config files and the panos to the source directory after they are done

Already available : see detection folder / template as well as rendering folder / template.

touristguy87 wrote:17 it is possible to have the pano config file automatically include the dimensions but not the resolution in MP, this would be very nice so that one can quickly see the size
of the pano that is produced with that pano config file.

See rendering filename template options.

touristguy87 wrote:18: ...is there no way to have the smartblend fix straight lines in the non-planar perspectives? If an image-processor can do barrel and pincushion corrections, why can't APP
do that for the perspectives which will distort straight lines? Yes I know that non-planar projections tend to not produce straight lines but it seems that this is something
that can be corrected.

Really not as simple as that. Straight lines beeing blended can comes from several causes :
- wrong focal length,
- wrong distortion
- nodal point issue
- etc.

touristguy87 wrote:18b the auto-horizon tool doesn't seem to work very well. It seems that if one starts with lines in the original images it shouldn't be too hard to make sure that those
same lines have the same orientation relative to each other in the final pano. It's not bad but the panos all seem to need *slight* modification in this regard, the horizon
is slightly bowed one way or the other, if the whole pano isn't slightly rotated. Getting it 90% right 90% of the time is useful but hardly consistent with the whole theory that
"quality comes first".

If doesn't work on line at all. This algorithm sometimes can fail, that's true. It finds the +90° rotation instead of 0° rotation making the panorama straight up instead of a row.
We have an hidden option to prevent that may be put public.


Interesting reading. Thanks for your feedback.

no avatar
touristguy87
Member
 
Topic author
Posts: 234
Likes: 0 post
Liked in: 0 post
Joined: Mon Feb 09, 2009 9:45 pm
Info

by touristguy87 » Tue Feb 17, 2009 6:45 pm

I have to take this one "entry" at a time, because of course...I wrote all this because I fervently believe it to be true...so I don't know if we are talking about a clash of logic, values or understanding or foresight but any case

one at a time

" 1-APP will not automatically scan across multiple folders for files to put into one pano-group. At least on cursory examination, all of the files in a group will be from one folder.

True. I seems logical for me because if images are in different folder, there must be a good reason.
Now, we can imagine to create checkbox that says if a folder is a separator for groups or not."

Actually there must be *a* reason. Whether that reason is good or bad is a different story. That depends on the context in which one is evaluating the reason :)

So, say, let us say that a person has never heard of panos or rendering or any of that and has sorted their image files according to criteria that have nothing to do with APP, at least consciously.

Then we throw APP into the mix. And they say "hm, it would be neat to have it scan my images and see if it can make panos out of them".

but, as I have said already, APP, as it sits now, requires all the files to be in the same folder to become part of one group, to become part of one pano.

They have to be part of the same group to become part of the same pano.
They have to be in the same folder to become part of the same group.

...the pattern getting clear yet?

If you want it to look across N files to see if it can form panos from those files, those files all have to be in the same group, not just the same folder.

The best way to run the autodetection routine from the perspective of finding panos, is to put all the files in one *group*, not just one folder.

That means that you need to manually go in and put files from different folders into the *same* group so that they could be considered for a pano from that group of files.

Pointing it at a tree will merely segment the files even further than they are already segmented based on folders, which is bad for finding panos out of the set of files.

Now there might be any # of reasons why the files are separated into folders. Whatever those reasons are, that will make it difficult to find panos amongst all the files.
APP needs to search in different folders *regardless* of what those reasons are, for separating the files into separate folders, and *regardless* of how many files are in the folder, it needs to put them all into one group. It needs to, basically, mimic the Explorer search-engine, and just scan through the subdirectory and find all the files that match a certain criteria, and use that as one group of files to try to find panos.

...and then of course if you wanted to include files in another folder in a separate tree, there should be some way to do that.

Otherwise you have to REsort all the files. Just for APP (and CS4 and whatever else can't handle files that aren't presorted).

I spent 3 hours last night doing that for one set of shots, all the shots that I took in the Manhattan area, around the Hudson, because I wanted to see what panos it found there in those shots. This is something of a special case because there are so many jurisdictions around the Hudson Bay area (and I sort my shots by jurisdiction...which gets tricky when shooting wide-angle waterfront shots). There would be no *reason* for me to do that, in general. But still separate folders would pose a problem for APP...even if one made the group size limit very large and tried to get all the shots into one group.

That's what should happen, regardless. Certainly as a user option.

Now I've basically sorted all the shots of interest into 2 trees. Many of the shots in those trees (the folders) I don't want APP to use as source images...many I *do* want it to use as source-images. There's no way to, say, show a tree and click the folders that you want it to scan for source-images, like the editor shows files that you can click to use them in the pano. That would be *very* nice.

But basically it needs to work with the files as they are where they are otherwise they have to be resorted (either in directories or in groups). Which goes a long way to defeat the advantages of using APP in the first place. It will handle 100 files and find 5 panos in those 100 files, but you still have to set up those 100 files for it to search through. That's not a lot different from having to separate those 100 files into 5 different folders. I shouldn't have to move *any* of the files or create any new directories just to use APP.

no avatar
touristguy87
Member
 
Topic author
Posts: 234
Likes: 0 post
Liked in: 0 post
Joined: Mon Feb 09, 2009 9:45 pm
Info

by touristguy87 » Tue Feb 17, 2009 6:48 pm

"This is not the way the settings works in autopano."

....yes, I realize this.

What I'm telling you about how I think they should work is not how they actually work. This I know.

The documentation explains how APP currently works. This is a wish-list for a future version of APP.

no avatar
touristguy87
Member
 
Topic author
Posts: 234
Likes: 0 post
Liked in: 0 post
Joined: Mon Feb 09, 2009 9:45 pm
Info

by touristguy87 » Tue Feb 17, 2009 6:50 pm

"Complicate to code the selection of a tree hierarchie. Solution, drag'n'drop the right selection from explorer ( or finder ) to APP."

....right, go into Explorer and handpick the files because it's too complicated for you guys to code up something that will let me use APP without having to do that.

no avatar
touristguy87
Member
 
Topic author
Posts: 234
Likes: 0 post
Liked in: 0 post
Joined: Mon Feb 09, 2009 9:45 pm
Info

by touristguy87 » Tue Feb 17, 2009 6:58 pm

"That part is really not something for the detection stage, but for the rendering. I talked already about that, but we are rewritting smartblend to something really better
that is able make such decision ( pixels from long focal have a higher priority than those from shorter focal length ).
The decision of taking or not an image during detection is just not possible, it's really at the end of the process that we can do something clever."

Of course it's possible. You just have to decide how you're going to do it.
I'm of the opinion that it is not better to use longer focal length shots over shorter ones because the increased resolution comes at the expense of greater instability and lower actuance. Unless you're shooting from a tripod you really don't want to use long FL's to shoot a pano (not to mention that you've just exponentially increased the # of shots that you need to cover the scene).

If I can form the same pano from 12 35mm shots and from 96 100mm shots I want it to use the 35mm shots and forget all about the 100mm shots. The last thing I want it to do is combine the 100 shots together into one pano config file and then pick and choose which pixel it will use from what image in the final render.

This again should be a user option (and clearly that's not even in the cards).

The last place I want this decision to be made is in the *renderer* much less in smartblend :)

no avatar
touristguy87
Member
 
Topic author
Posts: 234
Likes: 0 post
Liked in: 0 post
Joined: Mon Feb 09, 2009 9:45 pm
Info

by touristguy87 » Tue Feb 17, 2009 7:02 pm

" 4 a global control that would set the minimum MP of the panos that it finds, relative to the largest source image used.
it should be smart enough to not make panos that are barely any bigger than any of the original images, in terms of FOV

I didn't get this one."

If (assuming that all the shots are the same FL and thus have the same FOV) the highest resolution source is 12MP I don't want APP to make panos that are 13MP.
I don't even want to see the pano unless the FOV of the pano is much larger than that of any one component shot, and likewise the resolution in MP. This can be specified in a number of ways, I just chose MP because that's the most general way that I see at the moment. If one starts with 12MP sources I want the resultant pano (at 100% rendering) to be at least 20MP, say. and I want to be able to specify that as a percentage or something in a global setting before the autodetection routine starts.

no avatar
touristguy87
Member
 
Topic author
Posts: 234
Likes: 0 post
Liked in: 0 post
Joined: Mon Feb 09, 2009 9:45 pm
Info

by touristguy87 » Tue Feb 17, 2009 7:03 pm

" 5 a control that will limit the *maximum* MP of the source-files used for panos, so that it will not try to make panos out of panos.
(if the file name contains the word 'pano' it won't try to use that file to make a pano, of course one could select *only* files with the word pano in them etc)
6 some sort of exclusion logic so that you can put flags in the file names and it won't use those files for making panos.
Also a filter for file type

feature proposal : "an exclude filter based on name for the browse dialog box" ?"

...NOT in the browse dialog box, just a general setting that *always* applies...nothing that requires manual intervention once it's set up...

no avatar
touristguy87
Member
 
Topic author
Posts: 234
Likes: 0 post
Liked in: 0 post
Joined: Mon Feb 09, 2009 9:45 pm
Info

by touristguy87 » Tue Feb 17, 2009 7:04 pm

"This is not the way the settings works in autopano. It has another spirit, but the results are just the same. Let me explain :
Global settings are in fact "Default values". Every new panorama will have those values as startup value.
So if you change anything in the global settings, it will be used in any new group or panorama created but not on the currently opened one.

You can then decide to override any settings on an individual group for example.
"

then please put in a box to enable the global settings to override the settings in the pano-config file, where that makes sense

no avatar
touristguy87
Member
 
Topic author
Posts: 234
Likes: 0 post
Liked in: 0 post
Joined: Mon Feb 09, 2009 9:45 pm
Info

by touristguy87 » Tue Feb 17, 2009 7:07 pm

" 7: some way to turn off the "contrast optimization" logic globally (right now that can't be done, the AL can be disabled but not the "contrast-optimization")

I don't agree. Contrast optimization is called "auto level" ( not a good term in fact ) and we'll keep the constrat of original pictures ( except perhaps for 1/255 pourcentage, we
found a bug and the value can slide of one 1/255 )."

are you sure that you are not confusing a correction step with an optimization routine?

what's the problem with giving the user the choice to do this or not?
the more control that you take out of the users's hands and reserve for your own, the more that you make the use of APP an "either-or" proposition.

no avatar
touristguy87
Member
 
Topic author
Posts: 234
Likes: 0 post
Liked in: 0 post
Joined: Mon Feb 09, 2009 9:45 pm
Info

by touristguy87 » Tue Feb 17, 2009 7:09 pm

" touristguy87 wrote:

8: raise the maximum MP limit and rate it as a percentage of system ram, right now it seems to be limited to about 1/3rd of total system ram.
I want APP to use as much memory as it needs to autodetect and render panos quickly, if I want it to, it should be allowed to grow as large as possible to use
up the available memory and avoid any unnecessary disk i/o which will slow it down (and not rely on the system cache to do this)
Please make the slider 0-100% of real memory not 0-100% of the amount of system ram that you will allow APP to use

Memory managment is not that easy and just changing the limits of the max memory won't help much if the algorithms are not designed for.
This part is definitively related to the new smartblend I talked before.

touristguy87 wrote:

9 make it so that it has an internal ramdrive for smartblend cache, so that I don't have to set up one for APP to use as a temp folder
(which is much faster than using raid0 and works fine for panos of moderate MP)

=> Smartblend 2
"

Ok, but see "I can configure my system to render panos much better that APP can configure itself on my system to render panos, and therefore I'm quite pissed"
Someone running APP1.4 with a user-configured ramdrive on a PC should not be able to beat "smartblend2" running the same panos on the same system. That's all I'm going to say about that.

no avatar
touristguy87
Member
 
Topic author
Posts: 234
Likes: 0 post
Liked in: 0 post
Joined: Mon Feb 09, 2009 9:45 pm
Info

by touristguy87 » Tue Feb 17, 2009 7:11 pm

"The prerender doesn't just do prerendering. There are some computations that cannot just be disabled here. We did quite everything we could to recompute just what's needed and not
more, but there are cases where you just need to do the process. But now, with GPU processing, everything is far faster and real time."

There's no excuse for prerendering twice just to see the prerender in the editor, and then prerendering *again* if any of the controls are hit but no change is made in the pano config.
Again please do not assume that everyone will have a pc that will support GPU processing.

no avatar
touristguy87
Member
 
Topic author
Posts: 234
Likes: 0 post
Liked in: 0 post
Joined: Mon Feb 09, 2009 9:45 pm
Info

by touristguy87 » Tue Feb 17, 2009 7:33 pm

the rest is more specific than I want to get into now, I take it that you guys are the experts on stitching and rendering.

"14b likewise it should not "automatically" switch the temp *drive* just because it doesn't see the specified temp *folder*...just have it remake the folder & switch the temp drive"

if you set up the temp folder and for some reason that folder disappears, APP will switch itself to the previous temp folder that it used. (or maybe it reads the %TEMP% global variable)

The drive might still be there just not the *folder*. Why can't it just recreate the folder on the specified drive?

It's like the code tries to change to "r:\temp" say gets an error that the directory doesn't exist and then says ok change to %temp% (or %tmp%)
I would rather that it tries to create \temp on R: first

(I got around this by just using r:\)

because the ram drive wouldn't have the \temp folder when windows starts

anyway there are some "level A" issues here and "level B" issues. Basically I'm happy with the panos that I chose to make, that it autodetects. The main problems are in the autodetection and in the global controls. I realize that the global settings will affect what goes into the pano config files...the problem is that you can have 10 panos that you want to render and want to render them all at 10MP using smartblend instead of at "100%" using multiblend and that means that you have to send them all to the batch renderer but adjust the same parameters over and over gain, recalculating final MP from the dimensions of each pano. That ges to be quite tedious after the 3rd time.

You should be able to set global settings and have APP use those global settings as much as possible when doing whatever it does (so little if any user-intervention is required). And you can put in a global setting to choose whether to do this or do things the way they are done now (where the pano config file configures the renderer in priority over the global settings).

I can see having the pano-config file as a reference, but then why have a window pop-up when rendering the pano to allow the user to change the rendering options?
That totally defeats the purpose of having those same rendering options in the global settings.

I don't want to have to change those rendering settings to match what I just put into the global rendering settings each time I render a pano. Which I would have to do unless I did it at least once -for each pano- and then saved the BATCH in a batch-config file. Then I could always just rerun the batch and generate those panos the same way, every time, assuming that the files are there, and again the rendering settings in the pano-config file are irrelevant.

But by far my biggest complaint with it now is its eagerness to stack exposures when autodetecting the panos. Next the exposure-correction "feature" that I can't disable.
Third not being able to pick and choose which folders in a tree that I want the autodetection routine to run on. Next having to calculate how many MP the final pano will have based on image-parameters and then having to adjust the % slider for each pano to match the desired MP value, instead of just being able to set this globally.

I can see the next thing being that most of the features that I want to see in the next version depending on running the GPU-enabled editor.
A) I don't want to run the editor, ever
B) I don't want to have the performance & features of the editor depend on the GPU code, just in case I do need to run it.

Technically I can use a "go/no-go" logic on the panos that it autodetects. And the ones that I really like that I might want to edit, I can edit those. There might be a handful of those out of all the panos that it autodetects that I want to render, and there will be a handful of those out of all the "panos" that it autodetects, and it can only autodetect panos on a fraction of the files and folders that I have, because it will only scan over and use so many files in a group at once.

The quality of the rendering is a minor issue compared to these problems.

It's this fantasy of being good at "automatically" detecting and rendering good panos from a tree full of images that is its main problem.
Like the fantasy that the performers on American Idol have a real chance of being pop-stars :)

no avatar
touristguy87
Member
 
Topic author
Posts: 234
Likes: 0 post
Liked in: 0 post
Joined: Mon Feb 09, 2009 9:45 pm
Info

by touristguy87 » Tue Feb 17, 2009 7:41 pm

...the reason that I care about MP and not the image dimensions is that I don't really need it to be 5000x3000 or 15000x12000, I need APP to be able to use the ramdrive to do the smartblend, and not have to use my c drive.

That depends on the MP of the final pano.

If I needed specific dimensions, the issue would be the same. The slider gives you a percentage of how big it can make the pano without interpolation. That's almost useless unless you need that to be as big as possible. 99 times out of 100 I want either specific *dimensions* or a specific *resolution*.

So since each pano is different in general, setting the slider to say 20% will mean that each pano will be a different resolution and have different dimensions. That's not efficient.

Technically all I really need is for them all to be 2MP after cropping. So I could enable the auto-crop (or not) (ideally globally) and then set the output resolution to 2MP and be happy. But APP has no capability to do this. Likewise with the image-quality, I don't want to have to go in and change the image-quality setting in each one to 9 or 10, I just want to set that once globally [and when I render the pano I want that global setting to be used]{and if you don't like this then please put in an option to allow the user to prioritize global settings over pano-config settings for the same category of setting}.

otherwise I'll write something in matlab to do this to the pano-config files.

I mean, the pano config files are great, ascii and all that, good stuff. No problems there.

The problem is that I think that there were a LOT of times during the development of this program where someone said "this should be like this" or even "this *has* to be like this" and that was the end of the discussion and there were no options left to the user for changing that. In my opinion the program is way too hard-coded. It does what it does reasonably well, but what it does is not reasonably-well chosen. And only passably user-configurable. Only in the sense that there is nothing else even *close* on the market in terms of the auto-detection routine.

It's biggest strength by far is the ability to look at say 1000 images and have it autodetect different panos.
But the devil lurks in the details.
You guys make the classic engineering mistake of thinking that the way that you want to do that is the best way to do it.
Last edited by touristguy87 on Tue Feb 17, 2009 7:46 pm, edited 1 time in total.

no avatar
touristguy87
Member
 
Topic author
Posts: 234
Likes: 0 post
Liked in: 0 post
Joined: Mon Feb 09, 2009 9:45 pm
Info

by touristguy87 » Tue Feb 17, 2009 10:45 pm

if I were to take my camera out and shoot N shots of M panos and whatever else and I came home, dumped them all in a folder on my PC, and RC and ran APP on the results I would be pretty-happy with the results. I might wonder if maybe the groups were too tight and APP maybe missed a shot or two and I might have a few grimaces when dispatching the panos to the batch-renderer but still I would pretty-much be happy with the process and the results (the fact that I no longer rely on shooting AEB to get adequate DR would go a long way towards reducing the # of #### "panos" that APP autodetects, more Matlab programming will reduce this issue even further). Then I would sort the files and move on. It's only [mainly] in the context of *past* shots that have already been sorted into directories, along with exposure-pushes of the original shots, that the interface to APP is really a problem.

That takes the other issues to a new level.
Last edited by touristguy87 on Tue Feb 17, 2009 10:51 pm, edited 1 time in total.

no avatar
mediavets
Moderator
 
Posts: 16415
Likes: 2 posts
Liked in: 130 posts
Joined: Wed Nov 14, 2007 2:12 pm
Location: Isleham, Cambridgeshire, UK.
Info

by mediavets » Tue Feb 17, 2009 11:14 pm

touristguy87 wrote:It's only mainlyin the context of *past* shots that have already been sorted into directories, along with exposure-pushes of the original shots, that the interface to APP is really a problem.

Quite.
Last edited by mediavets on Tue Feb 17, 2009 11:15 pm, edited 1 time in total.
Andrew Stephens
Many different Nodal Ninja and Agnos pano heads. Merlin/Panogear mount with Papywizard on Nokia Internet tablets.
Nikon D5100 and D40, Sigma 8mm f3.5 FE, Nikon 10.5mm FE, 35mm, 50mm, 18-55mm, 70-210mm. Promote control.

no avatar
touristguy87
Member
 
Topic author
Posts: 234
Likes: 0 post
Liked in: 0 post
Joined: Mon Feb 09, 2009 9:45 pm
Info

by touristguy87 » Tue Feb 17, 2009 11:51 pm

...right. If you dump all your shots into one directory, or work on one directory at a time (and there's no chance that the panos that you want to make will depend on shots that are not in that directory), then all you need to do is worry about the size of the groups, the amount of free ram in your system, and the various issues with the editor and general controls. And any optimization steps that you would take that don't rely on APP directly (though most do).

So if you hand-sort your files then you just have to deal with maybe 75% of the items that I listed.

And of course if you don't try to make panos at all you don't have to deal with any problems with APP, at all.
Last edited by touristguy87 on Tue Feb 17, 2009 11:56 pm, edited 1 time in total.

User avatar
AlexandreJ
Kolor Team
 
Posts: 5987
Likes: 7 posts
Liked in: 10 posts
Joined: Mon Nov 14, 2005 4:56 pm
Location: Francin, France
Info

by AlexandreJ » Wed Feb 18, 2009 9:04 am

Just a note for touristguy87.
Please use the
Code: Select all
 [quote="someone"]text[/quote]

in the messages you are writting because it really hard to understand if you don't.

User avatar
[bo]
Member
 
Posts: 1226
Likes: 0 post
Liked in: 0 post
Joined: Fri May 05, 2006 8:16 am
Location: Bulgaria
Info

by [bo] » Wed Feb 18, 2009 9:29 am

I always sort the pano sets after a shoot and I've never had any of the problems you describe. I've had other problems, that got solved in recent versions. It's just my workflow is different, so I don't like the generalizations you make in many of your posts here. Your problems are not everybody problems; in fact, most of the things you write about are not seen as a problem by anyone else here, in the active community.

So as much as Alexandre and the other developers might find your input useful, you have to realize that posting tens of consecutive posts (instead of using the "Edit" function) won't push the development of APP in a direction suited to your exclusive needs.
Some of my panoramas, posted in the Autopano Pro flickr group.

User avatar
klausesser
Member
 
Posts: 8836
Likes: 5 posts
Liked in: 64 posts
Joined: Mon May 22, 2006 12:18 am
Location: Duesseldorf, Germany
Info

by klausesser » Wed Feb 18, 2009 12:34 pm

'[bo wrote:']. . . so I don't like the generalizations you make in many of your posts here.

especially in such a definitely insolent manner.

'[bo wrote:']in fact, most of the things you write about are not seen as a problem by anyone else here, in the active community.

The problem seems to be to reveal his understanding of what a program like APP is designed for and what´s his personal need - which he generalizes.
Simplicity is the keynote of all true elegance. Coco Chanel

User avatar
DrSlony
Moderator
 
Posts: 1893
Likes: 0 post
Liked in: 0 post
Joined: Sat Nov 03, 2007 6:30 pm
Location: Sweden
Info

by DrSlony » Wed Feb 18, 2009 3:52 pm

My reply form is as follows:
proposal number, proposal number, proposal number, ... - summary of proposal - reason why i (do not/)agree with it, if one is required.

---

Points I agree with:
8, 9 - use RAM more wisely, avoiding disk I/O
11a - adjustable thumbnail size
~11b - adjustable display of exif info
12 - add panos to batch without having them auto-start
12a - kill switches - buttons to stop all APP actions, allowing the user to change settings and reerun those actions, or to close APP, are needed
14c - multiple temp paths
~18b - verticals tool - I posted several times about a being able to set a bezier curve along a wavy horizon, would work much better than the verticals tool in some panos. I would also like to be able to set a horizontal line in all projections (currently for equirectangular I can set a "verticals tool" line horizontally to correct whole pano rotation, then APP will rotate my whole pano by ~90°, so I have to un-rotate by 90° to get the small rotation corrected... if you follow). Would also be nice to have the crop tool draw a horizontal line, or even a grid... this would basically do the same thing as my request for a "horizontal line tool".

---

Points I disagree with:
touristguy87 wrote:the global settings should take precedence over the same settings in the pano-config file

Absolutely not.

---

Points I'm neutral about, meaning that I don't care if they're optionally implemented, since although they wont affect me, they might help someone... although I'd rather have that developer time spent on more important things and instead have this marginal amount of users learn to use APP and adjust their workflow accordingly:
1, 2 - recursive scanning
3abcde, 6 - source image filters - As I wrote in the previous post, a pano-oriented workflow makes all of these filters a waste of developer time. On the other hand if you have several thousand images that you took before learning about panoramas, then these filters might help you out. But then again, the thousands of photos you took before learning about panography are likely to make ugly panos.
4, 5 - create panos only larger/smaller than a percentage of the source image size either based on pixel dimensions or field of view in ° - I never needed this since a proper pano workflow makes this a waste of develop time, as said before, but optionally having this wont negatively influence me.
7 - turn off exposure changes/auto levels - never needed it, dont see the point of using it, dont care as long as its optional
10 - turn off prerendering - touristguy87 suggests something a bit different in fact, but I'd like to propose a button to turn off prerendering for some tasks, such as moving around images, so that people who will use APP2 and not have a GPU can do these things more quickly. Having a pano with 50 images where 20 sky images are unlinked involves spending a lot of time moving them around if one has to wait for APP to prerender each time. Would be better for those users to be able to turn off prerendering and just move around image outlines and have APP put the different operations into a processing queue. Then when they finished moving those 20 image outlines around, they hit a button and APP prerenders all.
14 - render panos by dpi (or whatever) size

---

AlexandreJ: I'm thrilled to read that, cant wait for APP2!
[bo]: agreed completely
klausesser: agreed completely

no avatar
touristguy87
Member
 
Topic author
Posts: 234
Likes: 0 post
Liked in: 0 post
Joined: Mon Feb 09, 2009 9:45 pm
Info

by touristguy87 » Wed Feb 18, 2009 4:16 pm

...the general idea here is that if they would just put sufficient options in for user-control of the program you wouldn't have to worry about whether your workflow is well suited for APP.

APP could be configured to suit your workflow.

I mean, think (geez, what an idea, to think) "PS could work only with DNG files. Adobe could always say PS is the perfect editor for people whose files are already in DNG. If your files are *not* in DNG, please convert them beforehand."
If APP required your files to be in DNG, what would you say then? Would you say, "you shouldn't use PS if you're not willing to convert your files to DNG first. And if they're in some lowly 8-bit format like jpeg, they're not likely to be of good quality anyway".

Do you people *hear* yourselves? Do I expect the autodetection routine to create crappy panos from images if they are not pre-planned for panos & shot with a pano head? I don't care *what* it does or *how* it does it, or *what* kind of files that I give it, it shouldn't make bad panos.

And really if you want the program to be optimized for *your* workflow that's very nice. As long as you realize that it's possible that others don't want to use your workflow. That's the fundamental issue here. Is the program going to be flexible or rigidly "optimized" for a particular image- and pano-detection & fabrication configuation.

...the fact that many panos would be #### if autodetected from several thousand (or tens of thousands) of images that were not shot with panos in mind doesn't mean that they would all be ####. In fact the more images that you have to work on the more likely that you will find good panos. Especially if the autodetection routine can be well-configured.

You people really are not thinking. You're locked into a way of doing things, the way that you do things, that makes sense to you (or that you were just told to use, and you follow without thinking) based on the way that you came to the issue of pano-making, and you aren't even trying to think outside of your little box. Flippantly dismissing my suggestions out of hand doesn't make them stupid. What *is* stupid is trying to have a rational forward-thinking discussion with close-minded unimaginative people.

So I'm not trying to do that. I'm gonna just tell you what I think, lay it out there and let you deal with it as best you can.

It simply does not make sense that I should just ignore the potential of making good panos from a heap of pre-existing good shots simply because APP can't handle that scenario without my having to presort them or dump them all into one big folder and run it on a machine with a ton of ram. Likewise, it doesn't make sense that the APP development community should ignore that in the general case and try to force everyone to shoot and render panos the way that they want to do it. Now of course, I can do *either one* of those (presort or collect them all into one folder), but that still won't resolve the issues with the pano-config file settings vs the global-settings, or with the editor, or the autostacking of images to form panos, the lack of filtering on the source files, the way the memory-limit is set, the memory-management, the temp-folder management, the redundant and twitchy prerender issue, the way that the final resolution is determined...all of these things and more (certainly you don't expect me to re-list them all here, do you?) are hokey in the current version of APP. But sure I can work with it as it is. And I *do* work with it.

Or did you think that I don't..that I can't?

I'm not saying that I can't get APP to do what I want it to do. I am not saying that I can't work with it as it is, or that I'm *unwilling* to work with it as it is. Or is that not clear to you?

I'm just saying that these suggestions would make it a lot easier to use and better at what it does.
If you have issues with *that*, you need to find another forum entirely.

And if you think that I would say "change this so that it works my way instead of the way that it works now" you're completely misreading what I'm saying. I have said consistently to put in options so that I can CHOOSE which way it works. I wouldn't want to redesign APP so that *my* preferences are forced on the existing user base. But likewise I don't want the preferences of the existing user-base (or the designers) to be forced on me. Or on anyone else who would like to use this program. Especially when they are so clearly and so broadly suboptimal for the general case. This program borderline sucks, honestly, except that it is the best that I have found for doing what I want to do: analyze a bunch of random files for decent panos. And the panos that it does make, ignoring the ones that I wouldn't want anyway, are fairly decent. On those two points alone I would continue to use this program, dealing with the various other issues that I have mentioned. Don't get me wrong, it still sucks. I wouldn't have written all this stuff if it was a good program.

Beyond that if you have personal issues with what I'm saying (or how I'm saying it) feel free to go read another thread. I have no interest in your opinion about me personally, I didn't get on this forum to find friends or even to get your opinions about me as a person. You want to know what my opinion of you is, do you care about my opinion of you? Then you have real issues. In any case you need to leave your personal issues out of this. For all of our sakes. This is not the View or f*ing Dr. Phil and I am not interested in a relationship with you. I'm not even interested in a friendship with you. I don't give a damm whether you agree with me or not (because there will ALWAYS be someone with a completely-different point of view, for their own reasons...using their own "logic").

I'm not even trying to find a consensus here.

I'm just trying to get a few points across to the developers. From my own perspective. Feel free to do the same but keep your damm opinions about me to yourselves. I have no interest whatsoever in your opinions about me.

You put enough options in the program, almost everyone will be happy. You don't and then you get factions that love it the way that it is and that it has to be used, and those who hate it for those same reasons. It's that simple. And if it's too much effort in writing code for you to do that then just sit on it the way that it is or write "fun-code" and watch Autodesk, Adobe, Microsoft and others write *their* rendering-software the way that it should be and suck-away your user-base. Your choice. Time heals all wounds for good reasons. Only the strong survive. And these aren't even open-source packages, you guys are *charging* for this ****. No sit on it the way that it is now or even better rewrite it so that half of it depends on GPU rendering that won't be supported on many systems, and see if anyone is even using it in a year or two. I have rendered over 100 panos with APP on a 1GB laptop most of which were 20MP or more. You don't need high-end hardware to render panos of decent resolution in a decent timeframe. Eventually *anyone* would get tired of the various bugs and quirks of this software, and the hoops that one has to jump through to use it. If it takes me 15 mouse-clicks to get decent panos in APP the way that I want them and in CS4 it only takes me 5, which do you think that I'm going to use? Right now CS4 has one major flaw, that is shared by Autodesks's new pano tool and most others. It will put *all* the images that you select, or that are in the folder that you point to, into ONE pano, it cannot automatically sort them into different panos. THAT is the ledge between APP and the rest. Nothing to do with GPU acceleration (which the Autodesk stuff already has, and CS4 supposedly already has it too, or it's coming in soon) or even control-point editing (which I doubt that the user can do with them but I have no interest in CP editing either).

And unless you guys have that patented, I would suggest that you work on improving the user-interface and program flow & control-logic, in the ways that I've mentioned and explained here. Just my opinion, sure, but I know what I'm talking about. I've used this program pretty damm hard over the past 6 weeks. You can that it's only 6 weeks but that's 6 weeks more than anyone looking at APP for the first time.
Last edited by touristguy87 on Wed Feb 18, 2009 4:49 pm, edited 1 time in total.

no avatar
touristguy87
Member
 
Topic author
Posts: 234
Likes: 0 post
Liked in: 0 post
Joined: Mon Feb 09, 2009 9:45 pm
Info

by touristguy87 » Wed Feb 18, 2009 4:58 pm

...look, the Mac still has a user-base.

I am sure that no matter what you guys do to APP there will still be a loyal fan-base. If you write it, they will use it.

And you can even say, "it works great if you have your workflow optimized for APP, and you will get the best quality panos this way".

That's fine. Go ahead and do that and everyone else will use some other program because they are more interested in speed with *decent* quality and good user-friendliness than in "quality-first".

But there will come a point where even the people who want "quality first" and who are willing to suffer the consequences don't agree with the choices that you guys are making in developing this program.

The ONE thing that you can do to make both groups happy is to put in more than enough options to allow the user to configure it the way that they want it to be. Then you don't have to fight that battle with *either* side. The more options that it has, the easier it is to process the files that you want to process and to get panos that you want out of it without clicking and waiting and fussing, the better. Everyone happy. All you have to do is write the code. You can even put in an "APP-default" switch to make it run just like it is now.

You don't want to use file-filters? Fine, disable them.
You want the pano-config settings to override the global settings? Fine disable that.
You want all the source files to be in the same folder? Fine, disable any option to allow the user to browse & create groups over multiple folders.

Disable whatever.

But to NOT put the options in to do that is to make the same choice the other way for each user and to force them to use the program the way that YOU want to use it.
Last edited by touristguy87 on Wed Feb 18, 2009 5:02 pm, edited 1 time in total.

no avatar
touristguy87
Member
 
Topic author
Posts: 234
Likes: 0 post
Liked in: 0 post
Joined: Mon Feb 09, 2009 9:45 pm
Info

by touristguy87 » Wed Feb 18, 2009 5:04 pm

last but not least

no I'm not going to "force" anyone to do what I want by repeating myself

but hopefully by restating my point in a different way I can explain it in a way that makes more sense to more people.

If you have issues with that please return to Bulgaria and turn off your internet connection.

Next

Who is online

Users browsing this forum: No registered users and 2 guests