Pfstmo as a library

[Giuseppe Rota]

Hi Rafal and list,
As you probably know we have a slightly modified copy of pfstmo's
codebase in qtpfsgui which we have to manually keep in sync with
pfstmo's sources. This is obviously quite a hassle.
This begs the following questions:
1) are you planning on transforming pfstmo as a library (dll/so)?
2) If so, what's the status on that?
3) Would you accept patches against pfstmo that implement the
transformation from a set of executables to a library?
4) Zeev's proposed patch (scale-invariant Fattal) seems very
interesting: are you planning to integrate it? More generally, will
you accept from users patches against pfstmo that extend the
functionality of existing tmos or introduce new ones?

best regards,
Giuseppe

[rafm]

Hi Giuseppe,

Please see my answers below.

On Sun, Mar 29, 2009 at 6:11 AM, Giuseppe Rota
<rota.g...@gmail.com> wrote:
>
> Hi Rafal and list,
> As you probably know we have a slightly modified copy of pfstmo's
> codebase in qtpfsgui which we have to manually keep in sync with
> pfstmo's sources. This is obviously quite a hassle.
> This begs the following questions:
> 1) are you planning on transforming pfstmo as a library (dll/so)?

Yes, this is the goal for the next major release. I agree that pfstmo
should be a library.

> 2) If so, what's the status on that?

Julian has been actually working on this and have
already introduced some changes, mostly to make the future pfstmo
library exception-safe and to improve its performance. Please get in
touch with Julian so that we do not duplicate the work.

> 3) Would you accept patches against pfstmo that implement the
> transformation from a set of executables to a library?

Definitely, if this is coordinated work.

Julian, could you forward some of our e-mails to Giuseppe? Perhaps he
could comment on the design of the library and whether it also suits
qtpfsgui. Thanks.

> 4) Zeev's proposed patch (scale-invariant Fattal) seems very
> interesting: are you planning to integrate it? More generally, will
> you accept from users patches against pfstmo that extend the
> functionality of existing tmos or introduce new ones?

I did not have time to look into that, but I am generally open to all
improvements. The only thing I would insist on is a switch that would
disable the extensions and run a TMO in its original version. GUI
should also clearly indicate that this is no longer the TMO by Fattal
et al. but its extended version.

Cheers,

Rafal

[Yuval Levy]

hi Rafal,

rafm wrote:
> Yes, this is the goal for the next major release. I agree that pfstmo
> should be a library.

great news.

> The only thing I would insist on is a switch that would
> disable the extensions and run a TMO in its original version. GUI
> should also clearly indicate that this is no longer the TMO by Fattal
> et al. but its extended version.

you may want to check how libpano is integrated in Hugin (and other GUIs
can call it too):

<http://panotools.svn.sourceforge.net/viewvc/panotools/trunk/libpano/queryfeature.c?view=markup>

Daniel M. German devised an elegant architecture which gives the library
control to indicate the different projections (TMOs in your case) and
their parameters, so that adding a new one is very easy.

<http://panospace.wordpress.com/2008/12/30/vedutismo/> is the GUI side.
I still have to write a proper howto on adding on the library side.

If you define different TMO types and names in the interface, then any
such contributed extension can have its own name and you control the
naming convention.

Any chance to see you at <http://www.libregraphicsmeeting.org/> ? there
is a call for presentations out
<http://groups.google.com/group/hugin-ptx/browse_thread/thread/2a68e0f9ad28a348>

Also some readers of this list may be interested in
<http://www.uwivi.com/> to showcase their tonemapped image during LGM.

Last but not least, this is very very very last minute, but I'd like to
extend you a hand: if you have a student with an interesting project
description we can hook you and him into our google summer of code
mentoring organization to get him sponsored. Deadline: April 3.

<http://socghop.appspot.com/org/show/google/gsoc2009/hugin>

<http://panospace.wordpress.com/2009/03/26/last-minute/>

Yuv

[rafm]

Hi Yuv,

On Mar 29, 6:56 pm, Yuval Levy <goo...@levy.ch> wrote:
> Daniel M. German devised an elegant architecture which gives the library
> control to indicate the different projections (TMOs in your case) and
> their parameters, so that adding a new one is very easy.
>
> <http://panospace.wordpress.com/2008/12/30/vedutismo/> is the GUI side.
> I still have to write a proper howto on adding on the library side.
>
> If you define different TMO types and names in the interface, then any
> such contributed extension can have its own name and you control the
> naming convention.

I am quite sure that pfsmo, once it is converted into a library, could
be used with libpano by adding an another level of indirection. The
pfstmo library interface does not use any custom "Image" or "Array"
classes, but instead uses float* pointers, which should make
integration with any external software much easier.

You can say that tone mapping is a photometric "projection", the
difference is that you can combine arbitrary geometric projection with
an arbitrary tone mapping (photometric projection). I am not sure how
this is realized in Higin or libpano and if making such combinations
is possible.

Cheers,

Rafal

[juli...@googlemail.com]

Hi there,

I wasn't subscribed to this group until now which is why I didn't
chime in earlier.

Over the past year or so I've been working with Rafal towards making
pfstmo into a library. I don't have a lot of time to spare to work on
it but we've already made some inroads and, after a break of a couple
of months, I've recently re-joined the project and I plan to put some
more effort towards this goal in the near future.

I have several patches and a simple design for an API sitting here
that I plan to commit over the next weeks.

The general plan is to make all TMOs:
- thread-safe
- valgrind-clean, i.e. not leak any memory, not read uninitialized
memory, and not read or write outside of their allocated memory
regions (this is already done but needs to be double-checked)
- exception-safe by performing all resource allocation using RAII.
This is so that the progress callback can raise an exception at any
point in time to cancel the currently running operation in a safe way
and without needing additional code in the TMOs
- support fine-grained progress reporting as this improves perceived
performance
- support a common C++ API that provides simple and safe usage of the
library

I'm happy to elaborate on any of these points if there are any
questions.

There are also a few small issues unrelated to the API, such as minor
optimizations and a test suite, that I plan to commit.

Any help is appreciated - please get in touch with me so that we can
coordinate our efforts. I'm currently working on committing a few
optimizations as well as testing and cleaning up my progress reporting
patches. After that I plan to remove any remaining dependencies on
pfstools core and move on to RAII transformations.

Yuval, regarding queryfeature.c, we did not plan to go that far at
this point in time. I can see a generic interface to be useful at
some point in time, however in this first pass I was planning to
concentrate on the points above - this is going to be enough to do for
now.

Cheers,

Julian

[Yuval Levy]

juli...@gmail.com wrote:
> regarding queryfeature.c, we did not plan to go that far at
> this point in time. I can see a generic interface to be useful at
> some point in time, however in this first pass I was planning to
> concentrate on the points above - this is going to be enough to do for
> now.

understand. You have enough on your plate. Thanks a lot for providing
the world with such useful tools.

Yuv