Hi everyone,
I've been using VIL for a while now and had a question/comment for you all. 
Unless I'm missing something, it appears as if VIL is unable to handle image files larger than 2^31-1 bytes (i.e.. the largest number that can be represented by vil_streampos which is typedef'd to be a long int). The reason I noticed this in the first place was because I ran across a NITF file that exceeded these bounds.  The NITF spec allows for files as big as 10^12-1 (999,999,999,999) bytes. 
So, it seems as if this limitation is caused by the combination of two things:
1) vil_streampos is defined to be long int -- long int is 32 bits on my platform (Windows).
2) vil_stream has no API for iterative seeking (i.e.. seeking from the current position as opposed to the start of the stream).
It seems like we could overcome this limitation by remedying either #1 or #2.  I took a crack at #1 in my working directory by changing the typedef (of vil_streampos) to this:
#if VXL_HAS_INT_64
typedef vxl_int_64 vil_streampos;
#else //VXL_HAS_INT_64
typedef long int vil_streampos;
#endif //VXL_HAS_INT_64
That caused lots of compiler warnings elsewhere in VIL code base where int, long int and vil_streampos are occasionally used interchangeably.  Some of these issues were easy to resolve and other would (I believe) require API changes.  Also, vil_stream_fstream::seek() (which uses std::fstream under the hood) would have to be modified.  My plan for that was to have it do multiple seeks (from current position) for cases where the desired seek offset exceeded the size of istream::streampos.  I never got this far.
The other option would be to attack #2 by adding a parameter similar to ios_base::seekdir to vil_stream::seek().  Then client code could get a larger seek, by iteratively seeking.  This would solve the NITF case somewhat nicely (files up to 10^12 bytes) but would be infeasible for REALLY large files where you may have to seek a ridiculous number of times (worst case: 2^32) to get to the end of the file.  Of course, who cares about files that are that big if they even exist.  This solution requires a (small) change to the core API.
I suppose a third option would be to add a virtual seek64() function that did the right thing for all subclasses.  I haven't really thought this idea through too thoroughly.
At any rate, does anyone have any opinions on this?  Is there another (easier) option I'm missing.  If I were to pursue a solution, would you want it incorporated into VIL?  Thank you all for your consideration.
Rob Radtke