Re: [Openexr-devel] testing/submitting exrdisplay patch

[Jared Sohn]

Thank you for a link to the test images.

> By the way, exrdisplay already displays negative values if you use -n.
> Does your change do something different than what is already there?
>

My implementation is different, but is somewhat less elegant.  (I map
-10...0 to 10...-10 and multiply the channel value by -1 and map 0...10 to
-10...20 to show positive values.)  Fortunately, all of this code can be
found in a single function so it can be removed fairly easily.

> Exrdisplay was meant to be a programming example, to show software
> developers how to display an OpenEXR image, and a reference so that
> developers can compare what their own programs show on the screen
> with exrdisplay's output.
>
> For an example, exrdisplay is becoming rather big.  I wonder if
> exrdisplay should really become two programs.  One would be the
> bare-bones "here's how you display an image" reference, and the
> other would be developed further in order to become something that
> one would actually want to use.

I am curious as to which set of features would differentiate "here's how
to display an image" and "something that one would actually want to use".
I agree that a split would make sense if this list of features is
large or complex enough.

Just for fun, here is a bloated list of potential features that I can
think of off-hand.

* Picking
* Zooming
* Quickly switching among channels
* Quickly switching among files
* Allow resizing the window
* Apply tone-mapping algorithms, blurs, etc. (i.e. a graphical frontend to
exrtools)
* (extremely bloated) Allow image editing

Can you (or anyone else) think of any others?


Jared

PS: I would say that the first feature is essential, the next three would
be nice to have, the following two would be frills and the last beyond
scope.