Hi, Brent, welcome!
I like your patch. Can you submit it as a pull request? (Note for others --
this is great, he found a couple "FIXME" comments buried deep in the code,
which could stand improvement but weren't broken enough to probably ever get
much attention, and then... fixed them.)
I like your project ideas, too. One area where iv could certainly use some
love is in improving its performance, especially for large images, but in other
areas as well. You mention some good ideas to explore. I'm looking forward to
seeing your final proposal. I'm fine with the idea that no single iv
improvement is a big enough job to take the entire summer; three or four
smaller ideas that improve it in a variety of ways (or even "I could try X, Y,
and Z, at least one of those should make a big improvement, but I won't know
which one until I try it out") would also make a fine proposal.
-- lg
On Mar 28, 2012, at 3:33 PM, DAVIS, BRENT wrote:
> Hello!
>
> My name is Brent Davis. I'm currently a sophomore at Coe College (Iowa, USA)
> majoring in CS with a minor in mathematics. I have taken a few relevant
> courses (eg, computer graphics with a focus on OpenGL) but most of my
> programming experience comes from outside of classes. I have been spending
> the last few weekends putting together a game - my goal is to make it
> available for purchase somewhere, perhaps Desura; if that works out it will
> be my first "published" project. I'll post a link to what's been done so far
> here, as a sort of example of my coding and organization style. It's still in
> very early stages (college is keeping me awfully busy at the moment!) but I
> feel that what *is* there is fairly solid, albeit short on comments.
>
> http://dl.dropbox.com/u/17635193/RisingWater.zip
> It's a NetBeans IDE C++ project, bear with me :P; req'd libs include GLEW,
> SDL, boost_filesystem, lua5.1, and DevIL (I know, I'm using something other
> than oiio... I hadn't heard of oiio before I started looking at the GSoC list
> of organizations, so that's my excuse :) ).
>
> Other than that, I've created a small program that displays and applies
> effects to .nif (3d model format) files, and got some experience with
> multithreaded programming (Boost::Thread) last summer doing mathematics
> research on-campus.
>
> --
>
> I've made a small commit on my fork of oiio as part of the requirements for
> application. You can view it here:
> https://github.com/btdavis/oiio/commit/23f6f623d16181eff2604bf17953526fa597d61b
>
> --
>
> As for project ideas, I'm definitely interested in working with iv. I'm
> hoping some of my experiences with interactive programs will be applicable.
>
> I tested a few large images (approx 10000x7000 pixels) with iv and it
> struggled to display them when zoomed out - thus, one idea for a project: to
> improve support for large images.
> Increasing the number of GL textures from 4 to 16 (evidently, enough to store
> the entire image) brought performance right where it usually is with smaller
> images, and letting the GL drivers decide which textures need to be resident
> is a nice option, but it is difficult to determine how many textures the
> system can handle (aside from video memory, we'd need to know available
> system memory, swap space, etc, not to mention differences in implementation
> between drivers).
>
> Using mipmaps would be another good way to minimize the amount of data that
> needs to be stored, transformed - ie, from one pixel format to another - and
> sent to OpenGL. It seems (correct me if I'm wrong) this functionality is
> already in the ImageCache, and the option is available in the iv preferences,
> but I saw nothing to suggest that it was actually being used while creating
> and loading textures. What I have in mind is to generate (or load, with
> appropriate file formats) mipmaps with oiio, and load those as top-level
> textures, so as to avoid having to pass around hundreds of MB of texture
> data. Assuming the texture tile size is as big as the window, it shouldn't
> ever be necessary to use more than 4 textures at a time with prudent use of
> mipmaps -- this would definitely benefit large images.
>
> Reorganizing the code to work around disk i/o more effectively sounds good as
> well. I'm thinking a threaded approach would work here - one thread reads
> from disk while the main thread makes requests for future images (I haven't
> dug too far into the actual image cache/loading code so I don't know if this
> sort of thing is already implemented somewhere or not). The main thread would
> do something like "Confirm images are loaded"->"Send images to
> PBOs"->"Request next set of images"->"Render". This will probably find some
> good use with respect to the video playback features as well (as would the
> mipmaps). As a side note, I'd be interested in working with the video
> playback, should that opportunity be available. I don't have much experience
> with qt unfortunately but I'd love chipping away at the back end, with the
> timing and such.
>
>
> Hopefully I've managed to make sense of my ideas :).
> Looking forward to your feedback,
> Brent Davis
> _______________________________________________
> Oiio-dev mailing list
> [email protected]
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
