 |
|
|
|
|
|
 |
| ||||||||
 |
 
|
|
|
|
|
|
|
|
|
| ||||||||
|
|
| 
| User list | Rules | You are not logged in.
Pages: 1
System: Kubuntu 12.04 LTS, 16gb ram, SSD for root and APP spool, Intel I5 quad core
Lots of errors with single clicks doing what they should not:
a) In selecting a series of images to import, a single click on a file selects only it and
gives an error (no pano with one image.) One must ctrl-click and shift click to get a range.
(BTW still want a way to just select a whole directory as I put all my panos in directories
with an automatic program and just want to import the whole folder.)
b) Once photos are added, any click at all in the detection window displays the photo, even
ctrl=clicks. Hard to select photos to remove or move.
c) In the layers list, the list of photos also has similar problems, clicking on a photo
displays it, later you can perform actions like removing or unchecking.
d) In the CP editor, mouse drag drags the window. Shift-drag lets you draw the box for
control points.
For some reason the dialog boxes to load images have them in reverse order.
Batch render:
a) Where is the setting to "nice" (reduce priority) of renders? This is a must.
In particular because pause does not seem to pause the current render. If we can't
have a setting, the default should be slightly lower priority!
Some renders seem to be taking longer though I have not laid this out.
Some sort of bug in the total benchmark time as for a render that took about 5 minutes
it sayd 14 hours, 54 minutes 5 seconds.
UI:
Can't say I like the new UIs for controls, where drop-down menus for things like
projection and anchors/blending mode are replaced with dialog boxes so you must click,
move the mouse, click again rather than click and drag.
Playing with projections: Having more projections is nice and playing with them is fun
but perhaps if you are going to have this dialog box approach at least the various choices
should not each generate an undo event. The final choice should be an undo event.
Preview:
Great feature, but once you click on it, it can take a while and there is no way to
stop it while it sucks your CPU, and it seems no way to stop it from doing it again
and again. Can you toggle preview off? There is no menu item for it.
This is a 4-core system and it makes it drag to a halt. Especially when rendering is
going on at full-priority.
Detection:
When you start detection by accident and click stop, it seems to queue up another detection
for each time you click stop, with no way to stop them! Or perhaps it's just an infinite loop -- I had
to delete the group to stop it.
Detections should also run at slightly lower priority.
Offline
Described behaviours are like you made double clicks instead single clicks... We do not have reproduce that on our umbuntu 12.
You can't set different priorities to different algorithms, but you can reduce the number of threads in application settings. For example, if you have 4 cores you can use 2 cores only for each algorithms. So if you detect a panorama while editing, 2 cores will be used for optimization and 2 other for the editor.
The new tools UI is more consistent. In old color correction you have to open another panel if you want to change some color parameters (not only the correction model), we prefer to regroup them in one tool. Some new projections have some parameters and we prefer to regroup them too.
Issue 1511 is opened for detection.
Offline
bradtem wrote:
System: Kubuntu 12.04 LTS, 16gb ram, SSD for root and APP spool, Intel I5 quad core
Lots of errors with single clicks doing what they should not:
a) In selecting a series of images to import, a single click on a file selects only it and
gives an error (no pano with one image.) One must ctrl-click and shift click to get a range.
(BTW still want a way to just select a whole directory as I put all my panos in directories
with an automatic program and just want to import the whole folder.)
b) Once photos are added, any click at all in the detection window displays the photo, even
ctrl=clicks. Hard to select photos to remove or move.
c) In the layers list, the list of photos also has similar problems, clicking on a photo
displays it, later you can perform actions like removing or unchecking.
d) In the CP editor, mouse drag drags the window. Shift-drag lets you draw the box for
control points.
Hello,
After multiple tests on ubuntu 12.04, we are not able to reproduce such behaviors.
Can you please check :
- how your KDE environment is configured in KControl
- if any accessibility functions are activated
- if any xmodmap command are set
Thanks for your feedback.
Thomas
Offline
Not sure what you mean about being unable to set different priorities. APP 2 had a setting in it in the batch rendering window to control the priority of the rendering threads, but that function is missing in APP 3. This has become a real killer, the system eats so much CPU that the mouse slows down, I will have to run all of APP niced or go back to APP 2. Yes, I can drop to giving it only 3 cores but I want all 4 cores when the system is not doing other things of course, seems a waste. In any event, changing the number of cores requires shutdown and restart and according to reports here, APP is not remembering state, though I have not tested it myself -- kudos on stability because it has not crashed on me so far, and even stable APP2 would crash after this many panos. (BTW I have upgraded to APG but I would love to have auto saving of the workspaces in case it does crash, as in modern software no crash should ever cause somebody to lose work that's more than a few seconds old. Ever.)
KControl is not used in KDE 4.8 on modern Kubuntu, and has not been used for a long time.
Well, I guess the UI is a matter of taste, but when it comes to the projections in the old mode you could see what projection you were in on the toolbar, and you could change it with a dragging and that was nice.
Now for colour, I shoot almost all my panos in fixed exposure so I use no colour adjustment, but the default is to do it, and it reset my settings so it built a bunch of panos and in APP2 it was very simple to change, now it's a lot more clicks. I guess you are saying that most people don't change the mapping very often so it is OK if the UI is more cumbersome but my taste is to never make it cumbersome if that can be avoided.
I have not set any accessibility settings. I do use click-to-focus with raise. No problems in any other program -- including APP2.
Here is my xmodmap
shift Shift_L (0x32), Shift_R (0x3e)
lock
control Control_L (0x25), Control_R (0x69)
mod1 Alt_L (0x40), Alt_R (0x6c), Meta_L (0xcd)
mod2 Num_Lock (0x4d)
mod3
mod4 Super_L (0x85), Super_L (0xce), Hyper_L (0xcf)
mod5 ISO_Level3_Shift (0x5c), Mode_switch (0xcb)
Offline
bradtem wrote:
according to reports here, APP is not remembering state, though I have not tested it myself
This issue is solved in the version you are testing. It existed in the former alpha version.
bradtem wrote:
Now for colour, I shoot almost all my panos in fixed exposure so I use no colour adjustment, but the default is to do it, and it reset my settings so it built a bunch of panos and in APP2 it was very simple to change, now it's a lot more clicks.
Not sure to understand. Why don't you change the global editor settings to disable 'auto color correction' ?
Regards,
Thomas
Offline
Hello,
Some news on the UI side :
bradtem wrote:
System: Kubuntu 12.04 LTS, 16gb ram, SSD for root and APP spool, Intel I5 quad core
Lots of errors with single clicks doing what they should not:
a) In selecting a series of images to import, a single click on a file selects only it and
gives an error (no pano with one image.) One must ctrl-click and shift click to get a range.
b) Once photos are added, any click at all in the detection window displays the photo, even
ctrl=clicks. Hard to select photos to remove or move.
c) In the layers list, the list of photos also has similar problems, clicking on a photo
displays it, later you can perform actions like removing or unchecking.
After many tries, we finally reproduced this behavior (formerly we did not try on KDE env). The result is that this behavior is the default KDE one. Just open Kate and open a file. It can be changed as it is explained in several tutorial (http://www.trustonme.net/didactels/62.html). The fact that APP 2 doesn't behave like that (and I am sure many other programs) is caused by the fact that previous UI library version where not compliant with this version of KDE (which is newer).
bradtem wrote:
d) In the CP editor, mouse drag drags the window. Shift-drag lets you draw the box for
control points.
It also seems to come from KDE but changing single-click behavior does not change this effect. Indeed, almost all windows can be dragged this way on KUbuntu 12.04.
Regards,
Thomas
Offline
Curious. I believe there is supposed to be a setting for the widget as to whether opening single files is the expected behaviour or if opening multiple files is expected. But I haven't coded for KDE so I have not checked into this -- perhaps there are some other file open widgets that can be used that are more suitable to this? For example, a large number of the ubutnu programs, like Firefox, use a widget I see more often which, aside from being more what you need for multi-file open, remembers bookmarked directories etc. (Due a file open in firefox to see this one. Is this only in Mozilla stuff?) I believe the KDE widget has calls getOpenFileName() and getOpenFileNames() which set whether you are asking for multiple files or just one. The tutorial you pointed to seems to be for KControl and while my French is not great it does not appear to talk about changing the behaviour of the file open dialog that I can see.
There are some windows where drag moves the window, if the window has not defined another behaviour for it. However, many programs interpret drag to their own purpose (most commonly text selection and other things) and I would hope APP's CP editor would want to do that.
As to the auto colour correction -- yes, I have that disabled now. What happened was that I fired up the beta (which ignored my previous settings) and created a bunch of panos, and found them all with auto color correct, so on each one I went in by hand to correct them. I was curious as to why this action, which used to be a simple click and drag (at least the toolbar icon reveals the state still) had turned into the more complex click, move mouse, and now you are in a new editing mode so you must click your colour mode then click again to return to the editing mode you wished. This is not a big thing, I just was curious why the change to a UI with more involved interaction. I think I understand that for those who want to tweak the anchors a lot, this may be easier.
Offline
Pages: 1