[Pkg-phototools-devel] qtpfsgui architecture: random ideas

[Giuseppe Rota]

On Feb 5, 2008 7:13 PM, Sebastian Harl <sh at tokkee.org> wrote:

> Hi Giuseppe,
>
> (Cc'ing pkg-phototools-devel, please keep the list in Cc when replying.)
>
> Disclaimer: I did not have a look at the source code so far, nor did I
> use qtpfsgui very often yet. ;-)
>
> I was wondering how the general architecture of qtpfsgui looks like.
> I.e.: How does it access the functionality provided by pfstools and
> pfstmo? How does it exchange data between different parts of the
> program? Giuseppe, could you please provide a very simple overview? I'd
> really appreciate that.


Hi Sebastian & list,
the main data type that gets exchanged between the different parts of the
program is a pointer to a structure which was inherited by pfstools, a
pfs::Frame. If we discard the metadata a pfs::Frame basically holds 3
matrices of floats, one for each color channel.
The color space is usually either XYZ or sRBG. (The pfs stream is documented
in a pdf ffrom the pfstools project)


>
> The main reason for asking: IIrc, you reuse / modify the code of
> pfstools and pfstmo to generate one large, monolithic binary. That would
> mean that basically all of the code gets duplicated - including any bugs
> - which makes maintenance twice as much work.


yes, exactly.


> Now, I was wondering if it
> would be possible to use the pfstool / pfstmo binaries directly - i.e.
> do fork() and exec() from qtpfsgui. qtpfsgui itself would just need to
> be the glue to keep it all together and probably take care of some
> temporary files. Does that sound reasonable to you?


Yes, it is reasonable, and it actually was the default behavior in the more
recent version of qtpfsgui.
I had 2 problems, though:
1) pfstools' upstream did not want to integrate several important changes.
2) Performance: buffering the stdout and piping that in again was a terrible
drawback.