ptX gui

ku.b kuwe@gmx.de
Tue, 16 Apr 2002 14:04:04 +0200 (MEST)


Hi Listmembers,

my name is Kai-Uwe Behrmann, architect - living in germany and working at
the moment for buildingauthority of Saxony. So its not easy to get contact
to internet over the day. On the technical university at my hometown
Chemnitz I had my first contacts with computers - all sun=B4s and ibm=B4s a=
nd
such things, later linux-pc=B4s and this is what I use now at home. I=B4am =
new
to such an development project as this ptX one exept some hacking on
colormanagement, printing ... . I=B4ve got not as much expiriences as maybe
useful for good programming (only small scripting-knowledge) and so I
decided to think about an useful interface for the ptX-gui.

Hopefully You all can understand my english written german and the poor
graphics.

The here descriped interface relies on some complex properties
to interact from first step to the pano-result. Not such=20
important parts I descriped in brackets ().

I take my expiriences and the thoughts if an not computer-experienced one
and state at first
=09- the ptX gui should show as less as nessesary options=20
=09  =09( for the intuitive beginners )=20
=09  and by doubleklicking as much as possible ( for the expirienced ).
It would be useful to find all the file-, options-and helpmenues on top but
primary doubleklicking ( or press enter ) on an objekt to make an further
action on it, because I very often found this is a direct way to handle the
objekts more intuitive. Many of the mac-programmes goes this way - great
interfaceculture.

Second I was thinking about an too-part application
=09- on part for the roughly job ( selecting the pictures and saying
=09  where they should stay in the final pano )
=09  an one for the fine one ( CP-job, single picture korrection, and
=09  the pano-Save-button ).
This could be the allways visible too parts of the interface, maybe in too
windows. All other parts could be visible only at the moment when they are
needed.


Window A:=09file-selecting, projekt creation, first preview
__________________________________________________________________
|  |file|_  |options|  ______                            |help|   |
|  |thumb|  pic-name   |thumb| pic-name     (inner-pano-sphere)   |
|  |nail |  RGB/gray   |nail | RGB/gray            +y+         ^  |
|  |_____|  size/date  |_____| size/date         ++   ++       |  |
|                                              ++ ____  ++     |  |
|     .                .                      +   |   |   x    |  |
|     .                .                      x   |   |   +    |  |
|     .                .                       +  |   |  +     |  |
|     .                .                       ++ |___| ++     |  |
|     .                .                         ++   ++       |  |
|     .                .                           +y+         =B0  |
|     .                .                     <--------------->    |
|     .                .                     ___   _____   ______ |
|     .                .                    |new| |erase| |change||
|                                           |___| |_____| |______||
|_________________________________________________________________|
In window A You see left the images used for the actual projekt. Right You
can see an sphere with an projection of the to been expected pano (preview
inside of an sphere ). I hope it isn't too difficult.

It is possible to rotate the right sphere up/down and left/right arround tw=
o
fixed axis (x and y). (The y-axis could seem shorter or as long as the sher=
e
be rotating x-x from 90=B0 to -90=B0 . y-y can rotate from -65000=B0 to +65=
000=B0.)

I think the simple usage would mainly depend from an visible result of user=
s
action. So everybody could easily understand what he is doing at the moment
and what kind of result he could expect. ( Thumbnail-preview may save
timeconsuming finishpicture-calculations. )

The left thumbnails (.xvpics?) can been draged to the hole sphere in the
right part of the window. You should see the inner face of the sphere. Ther=
e
they are placed as thumbnails and can gif the user a small not intensive to
compute preview of the resulting image ( this would be mainly an
gl-programming job -->  vrml / libvrml ? ).

 ( The previewcalculating operation could take eighter the values of the
second window or standard values depending of count of used images in
project to calculate the preview. )

The buttons under the the sphere ( or under the thumbnails? ) could be
visible containers. With this buttons one can easily create an projekt.=20
=09New - for an new picture, opening the filemenu for selecting a new
=09=09file from directory. After this step one could place the=20
=09=09reight sphere and drag the generated thumbnail in the sphere.
=09Erase - could simply erasees the actual thumbnail or one could drag
=09=09a thumbnail to this container ( pic of a wastebasket ).
=09Change - for exchange of another sourceimage, maybe the formerly was
=09=09from an reused project, by dragging to or pushing directly this butto=
n.
=09=09Doubleclick in thumbnail should open the fileselector as well.

 (It might be helpful to define the top of the image, maybe by clicking on
the thumbnailborder wich could remain marked by an gray point.)


Window B: fineadjustment, optimisation-button, finish-button (save-pano)
__________________________________________________________________
|  |file|_  |options|   ___________________              |help|   |
|  |thumb|             |       \           |        |thumb|       |
|  |nail |  pic-name   | resulting green CP|  ^     |nail | name  |
|  |_____|             |         \ ^       |  |     |_____|       |
|                      |   x ---> X <-x    |  |                   |
|     .                | blue CP  /   |    |  |      .            |
|     .                |         /    |    |  |      .            |
|     .                |        / yellow CP|  |      .            |
|     .                |       /           |  |      .            |
|     .                | CP - X            |  |      .            |
|     .                |       \           |  |      .            |
|     .                | left   \  right   |  |      .            |
|     .                | image   \  image  |  |      .            |
|     .                |___________________|  =B0      .            |
|                      <------------------->                      |
|_________________________________________________________________|
In window B You have all thumnails painted more on the border and in the
middle an large picture with two final or zoomed images inside.

 ( It could be useful or not to take the thumbnails from window A and drag
them into the window B , but it could be irritating. )

This is the window for selecting pairs of images and placing controlpoints =
(
CP=B4s ) for fineadjustment.

 ( It=B4s helpful to integrate the "correct"-menu from the gimp-plug-in her=
e
for single-image-adjustments. Pleace make the RGB-lenscorrectfunction
available. The menue should arrice by doubleclicking on thumbnail. )

Other ( not drawn ) buttom=B4s would be nessesary for optimisation, saving =
the
result, final-creation-values (k, f, u , withe, hight ...) .

 ( The savebuttom could opens a window inluding all options for the final
pano. As an special event it would be possible to place an preview-area
inside the window. In this window someone could see all changes of the
options instandly, as very useful for beginners - f1/f2 projektion. This
preview should be switchoffable and could been - more delicate - change
between vrml-projection and flat-projection.   Ah, yes .. We could use the
preview for setting up an area only as result, change the direction and
calculate maybe 420=B0 or 135=B0 by changeing the size of the preview-area.
Sorry .. one more; but what think you about an horizontline? I often sit an=
d
try to get balanced room=B4s or places. This takes sometimes 3 or 8 renderi=
ngs
till I'am satisfied. )


Conclusing: In the simple version ( ignoring all in brackets included=20
possibilities ) this would be my idea of the project.
I know this could take a lot of time for implementing all of the
above mentioned features, from creating/adopting an useful datastructure,
over file-handling ( temporary imagefiles, projectfiles ), to integrating i=
n
different environments ( standalone - linux, win, mac?, gimp-plugin ) and
translations and helpfile-creation.

In the question of the programming-toolkit I=B4m not so wellinformed. I lik=
e=20
gtk because it is free and handles colors more carefully.

 ( Beside an standalone gui: if it would be possible to create with our
programm the project and let panotools write the output, as well it should =
be=20
possible to integrate our gui into gimp. This would make the app more
known by other users. )

My suggestions for the appname would be ...(ptMac) .. =20
 "ptX"=09=09for the listmembers or
 "Xpanotool"=09more for unix-users
 "Panozeug"=09and an wordjoke from an german - roughly translated
=09=09"panothing". The translation of tool means in german=20
=09=09Werkzeug. Werk (work) is substituted by pano - the target,
=09=09 and Zeug ( ~ thing) is remaining.

Last but not least the licenceagreement ( GNU, ...) should be for all of
interest. From my side I have no profit-interrest and would agree to an=20
style of GNU-licence.

Best, regards
Kai-Uwe