search

AcademySoftwareFoundation / openexr

The OpenEXR project provides the specification and reference implementation of the EXR file format, the professional-grade image storage format of the motion picture industry.
http://www.openexr.com/
BSD 3-Clause "New" or "Revised" License
1.64k stars 620 forks source link

New openexr viewer #521

Closed meshula closed 3 years ago

meshula commented 5 years ago

We need a new openexr viewer, as the existing one relies on the deprecated Cg toolkit, and has other portability issues as well.

[Edit: we don't "need" a new viewer per se, as discussed in this thread. We should determine however the necessity of having a viewer at all, and if we do, how to move forward.]

To kick off a discussion, I'll mention that I use this OpenEXR viewer instead of the official one: https://github.com/tizian/tonemapper . It's very lightweight, cross platform, and easy to build without bringing in a dependency as large as Qt. Perhaps it would be a good starting point.

[Edit: Many viewers exist, either open source or closed, it's not necessary to elaborate them here, as that's part of a follow up discussion after determining if OpenEXR should ship a viewer or not.]

[Edit: Unique aspects of the exrviewer are:

Here is an inventory of the existing exrviewer functionality:

interactive functionality

command line options

-p show preview thumbnail -L x display layer x -l lx ly displays level of a tiled multiresolution image -w display pixels in data window -a ignore pixel aspect ratio -c x load channel x only -l normalize exposure and knee sliders -n normalize pixels -s wrap around check mode -C apply CTL transforms -T ignore CTL transform -u live update with CTL -t use threads to load image and run CTL -h help

lgritz commented 5 years ago

Do we need a new viewer? Or any viewer? In the OpenEXR library itself?

What is the point supposed to be? When OpenEXR was first release, no software read it (by definition, on day one), and in general had no way to view or inspect images with values > 1.0. So to make OpenEXR catch on, it needed to provide a way to view the images to get people started. But 15 years later, every viewer that would be found in a VFX facility (and for that matter, any that ship on base OS distros) can read it. Several, like the one above or the one in OIIO, have ways to adjust the displayed range to deal with HDR.

lgritz commented 5 years ago

Also note that any viewer we would want to put in OpenEXR itself, without adding big dependencies, would (a) not be properly color managed by OCIO, and (b) would only display OpenEXR images, no other formats. These limitations relegate it to merely a toy example, not something of practical value in a VFX facility. Unless a minimal example that almost nobody will actually use is what we're specifically after, it will not be adding much value to this project, but it will greatly complicate the support and testing burden by introducing an interactive application.

meshula commented 5 years ago

Motivation: The TSC has already discussed moving exrviewer out of the OpenEXR repository. The initial thought was to move it into a "viewers" repo, but that's insufficient, as the viewer currently only works on systems with legacy support for nVidia's Cg library. No point in moving and maintaining an application that works on a very small number of systems.

I inventoried the functionality to discover what exactly the viewer's reason for being might be, and if there is anything unique. The unique aspects are a practical tone mapping function, a method for listing and viewing the layers in a file, and a "deep 3d" viewer. I haven't worked out yet what exactly that does, and if it's useful to anyone; I haven't seen any "deep 3d" files in the wild, aside from some toy files early in OpenEXR's development at ILM, and am wondering how/if they are used in reality. The value of another simple tonemapper is low, I can't gauge the value of the deep 3d viewer. Inspecting the layers seems useful, although there are other command line tools for that.

The question of color management, and OCIO and CTL is worthy of another issue thread, so I won't broach it here except to note that currently the active builds elide CTL support, so the current state of the code and support is unknown.

So it does seem like the more basic question of whether to update and maintain it, or remove it, should be opened for discussion.

I edited the post at the top, marked with Edit tags, to reflect this discussion.

cary-ilm commented 5 years ago

I’ve always assumed that the value of OpenEXR_Viewers was just as example code, potentially useful for a student starting out without much experience with “real” viewers, better kept in a separate repo, where that can be made clear and so the rest of OpenEXR is unencumbered with it and its dependencies. But it the code is a poor example, using bad practices or outdated dependencies, it’s possibly worth than nothing.

I’m such a pack rat that it’s hard to advocate just deleting it altogether, although the code is still there in the repo in the branches of previous releases.

I think my vote would be to move it to a separate repo, leave the code as is for now, but clearly indicate in the README that it’s outdated and in need of a rewrite.

On Sun, Aug 11, 2019 at 10:51 AM Nick Porcino notifications@github.com wrote:

Motivation: The TSC has already discussed moving exrviewer out of the OpenEXR repository. The initial thought was to move it into a "viewers" repo, but that's insufficient, as the viewer currently only works on systems with legacy support for nVidia's Cg library. No point in moving and maintaining an application that works on a very small number of systems.

I inventoried the functionality to discover what exactly the viewer's reason for being might be, and if there is anything unique. The unique aspects are a practical tone mapping function, a method for listing and viewing the layers in a file, and a "deep 3d" viewer. I haven't worked out yet what exactly that does, and if it's useful to anyone; I haven't seen any "deep 3d" files in the wild, aside from some toy files early in OpenEXR's development at ILM, and am wondering how/if they are used in reality. The value of another simple tonemapper is low, I can't gauge the value of the deep 3d viewer. Inspecting the layers seems useful, although there are other command line tools for that.

The question of color management, and OCIO and CTL is worthy of another issue thread, so I won't broach it here except to note that currently the active builds elide CTL support, so the current state of the code and support is unknown.

So it does seem like the more basic question of whether to update and maintain it, or remove it, should be opened for discussion.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/openexr/openexr/issues/521?email_source=notifications&email_token=AFC3DGJJEVWO7XV5Q2NBLG3QEBGTNA5CNFSM4IKY2BI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4BFQUI#issuecomment-520247377, or mute the thread https://github.com/notifications/unsubscribe-auth/AFC3DGI2ONKFXPNKMMVXWGLQEBGTNANCNFSM4IKY2BIQ .

-- Cary Phillips | R&D Supervisor | ILM | San Francisco

meshula commented 3 years ago

Closing. We are currently recommending that people use the otioviewer, rv, djv, or any number of other viewers for OpenEXR content.

cesss commented 3 years ago

I'm a newcomer to OpenEXR, and I must say that not having a viewer included in the distribution is unfortunate. Yes, if you download OpenEXR is because you are a developer and you'll call OpenEXR from your software, so, yes, you know how to write a viewer, but then... building OpenEXR and not being able to see it in action until you write your interfacing code is very unfortunate, IMHO.

lgritz commented 3 years ago

@cesss, What platform are you on? MOST viewers can display openexr files now.

meshula commented 3 years ago

If the motivation is a quick sanity check that everything built properly, I run exrheader on a sample exr file after a build; exrheader and a bunch of other command line tools install into bin.

cesss commented 3 years ago

My comment wasn't about viewing EXR files, but that, for example, when I build a raytracer, the first thing I do is to run its demos, no matter if I'll actually be using the raytracer as a library. In the case of OpenEXR, when you read it's a format for HDR color, I'd really expect it comes with a viewer -with minimal or no dependencies- which also would let you adjust tone mapping for example. Something like Tonemapper (suggested in an earlier post), but using OpenEXR instead of TinyEXR, and shipped with the library.

The libraries that come with examples showing you how you are expected to call them, are the most developer-friendly ones, IMHO.

Anyway, it's a subjective opinion. Just wanted to comment on this, because I felt disappointed when I saw no viewer comes with it.

lgritz commented 3 years ago

Data points:

libtiff -- does not have a viewer

libjpeg -- does not have a viewer

libpng -- does not have a viewer

giflib -- does not have a viewer

libheif -- does not have a viewer

webp -- does not have a viewer

cesss commented 3 years ago

Yes, @lgritz, agreed. But then, I wouldn't say EXR is just another one in that list, because it's the format that comes to your mind when you think about HDR color. You can argue that if you want a HDR demo, you should look for it elsewhere, and that's OK, I'm just saying what I expected to find when uncompressing the OpenEXR tarball. I just commented it because maybe other people feel the same, but maybe it's just me. I don't want to convince anybody, just my 2 cents.

lgritz commented 3 years ago

We used to have a viewer in this codebase, but the main reason was that when OpenEXR was first introduced, nothing could read it, so it was really necessary as the only way to display OpenEXR images.

Years later, LOTS of viewers support OpenEXR, and the viewer itself -- which never had enough features or developer attention to actually be "good" -- was becoming an increasing liability to support, since it (being a GUI app) was less platform-independent, harder to test, and seemed to just generate a lot more need for developer attention than could be justified by its usefulness. Also, as OpenEXR grew in capabilities, that simple viewer could be used for less and less of the entirety. For example, it never could display deep images, multi-part images, stereo, etc., and didn't have a good color management pipeline. So we dumped it.