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. _______________________________________________ Openexr-devel mailing list Openexr-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/openexr-devel
