OpenImageIO
OpenImageIO copied to clipboard
Great Big `iv` Wish List
Master list of iv
feature requests
Rather than proliferate scattered issues, let's coalesce all the requested iv features or changes here. Feel free to add comments with new suggestions, and I will occasionally merge them into this list.
This is just requests for features or changes in behaviors. Actual bugs should be entered as separate issues.
They are in no particular order.
- [x] **Full support of OCIO color spaces and displays**
- [ ] Dark mode (was #311) (Suggestion: does this help? https://github.com/ColinDuquesnoy/QDarkStyleSheet
- [ ] Difference mode: shows you the absdiff between the current image and the last image. (originally #291)
- [ ] Wipe mode: There should be a mouse+modifier that splits the screen horizontally and/or vertically (depending on the mouse movement direction) of the current image and the previous image. (originally #292)
- [ ] Have iv able display partially-written exr files (originally #1191).
- [ ] Area probe: Allow a way to sweep out a rectangle and report the min/max/avg values within the rectangle. (originally #310)
- [ ] Flip and rotate should be added to the edit menu (or view?). (originally #290)
- [ ] "Save window" doesn't work -- it saves the whole image. (originally #286)
- [ ] iv Help menu should have a choice that tells you all the available plugins or formats supported (similar to `oiiotool --help`) (originally #279)
- [ ] "Open" shouldn't resize the window. (was #289)
- [x] Togglable overlay to show the boundaries of the display & data windows. (was #308)
- [x] Multiple windows -- iv should allow the current image to be split off into a separate screen window in the same iv process. (was #287)
- [ ] Help menu / documentation. (was #284)
- [ ] If an image doesn't load, should it close that image's slot? (was #44)
- [x] Load a directory: `iv dirname` ought to be the same as specifying all the image files in that directory
Support for the KTX-format would be great! https://www.khronos.org/opengles/sdk/tools/KTX/file_format_spec/
@silverlan That's a great idea. Can you file a new issue about supporting this file format? This is not really an iv
related issue, as this ticket is dedicated to, since iv doesn't contain any format-specific code at all (it just relies on OIIO's support for many formats).
I added the KTX request on a different ticket.
I marked this as "good first issue", but just to clarify -- this is a "super-issue" that lists many previously suggested improvements to iv. Any one of these may be a good first issue, not trying to do all of them at once, obviously.
Hi, I want to take up the task for "Load a directory: iv dirname ought to be the same as specifying all the image files in that directory" which image file formats is the iv tool supposed to work with?
also, is it supposed to also work with iv filename1 dirname
and so on?
@CheeksTheGeek Yeah, I would assume that it's fine to have multiple files or directories on the command line -- for each file, it opens that image, and for each directory, it opens all the image files in that directory. (And, I should add, it should not be an error if there are files in that directory that are not image files.)
@CheeksTheGeek Yeah, I would assume that it's fine to have multiple files or directories on the command line -- for each file, it opens that image, and for each directory, it opens all the image files in that directory. (And, I should add, it should not be an error if there are files in that directory that are not image files.)
Yupp! I had a feeling, that would be more ux intuitive, so did this, if the directory doesn't have even a single valid image, it then throws an error and continues with other files/dirs
I'd like to take the OCIO support feature. It is probably too much work for the dev day, but I could start.
That would be great. If you've ever put OCIO support on a viewport before, it's probably not a big job for you.
If it simplifies things, I wouldn't mind at all if the OCIO features in iv
only worked with OCIO >= 2.0. I think OIIO's support for OCIO 1.x will probably get dropped before next year's release, so I'm not sure I would recommend investing much time in a second code path for it with so little runway left. I'm saying all that without much appreciation for whether it's any appreciable amount of extra work to support both 1.x and 2.x. Use your best judgment and don't feel obligated to support too far back.
Hi, I'd like to take on the "Open" shouldn't resize the window
issue for the ASWF Dev Day