I understand, and it's certainly possible... I guess we could have some kind of
query that would return the underlying "native" data pointer. But that is
somewhat against the OIIO philosophy of trying to hide the implementation
details and present a completely generic API regardless of file format.
The kind of situation I'm worried about is that if we change the underlying
implementation, it would break application code. I doubt we'd ever move away
from libtiff, but for other formats, we may want to change the underlying
library -- upgrade versions of the library that has compatibility break (see,
the m_tif is not enough, you might need to know which version of libtiff you
had, and maybe more as well), change from one library to another, write our
own, or replace our poorly written one with a 3rd party library -- and then app
code that assumed a particular underlying implementation would be confused or
broken. Yes, that could be a "caveat emptor" situation, the user accepts the
risk of using this back door, but I think that should be a last resort.
I'd prefer to address your problem more directly, by just supporting geotif.
I'm no expert on it, so maybe you can fill in the details. What additional
functionality do you need to read and write correct geotif files? Is it just a
bunch of additional tags that we need to support? Can it be done by choosing a
convention for metadata names for geotif-specific information, and then just
deal with it inside our TIFF reader/writer? (As we've done already for GPS
information or Exif data.)
To be more concrete, suppose you could get the underlying m_tif. Exactly what
would you do with it? What specific calls would you make to do your geotif
work? Maybe we can think of easy ways to support what you hope to accomplish,
without needing to expose the pointer or require the app to directly interface
with libtiff.
-- lg
On Sep 3, 2014, at 11:29 AM, Norman Goldstein <[email protected]> wrote:
> Here is an example of what I mean. Maybe I should have
> started off my first email this way ...
>
> Inside the OIIO TIFFInput class, is the data member
>
> private:
> TIFF *m_tif; ///< libtiff handle
>
> which is the fundamental libtiff structure for managing a tif file.
> A wrapper library, such as OIIO, will expose some of the capabilities
> offered by TIFF* and libtiff. By allowing the OIIO user/programmer access to
> the TIFF* (in a c++ civilized way), it would allow the best of both worlds:
> -- The great uniform functionality of OIIO, and
> -- For those willing to take the risk (compatibility with OIIO), further
> functionality
> available through the TIFF structure.
>
> In my case, I am wanting to do geotif stuff. I suppose I could add a new
> geotif
> file format to OIIO, but it really is just a set of tif tags and the such, so
> I think it
> makes more sense to enhance the current OIIO TIF format implementation.
> I would like to use libgeotif in conjunction with the TIFF* .
>
> I would expect that many other image file formats have similar native
> structures
> that could be used to do stuff that is specific to those formats, so this
> would be
> a general mechanism to access such functionality.
>
>
> On 09/02/2014 04:54 PM, Larry Gritz wrote:
>> I'm not quite sure what you mean by "native format functionality". Exactly
>> what data are you trying to retrieve?
>>
>> -- lg
>>
>>
>> On Sep 2, 2014, at 12:43 PM, Norman Goldstein <[email protected]> wrote:
>>
>>> I have looked through OIIO docs and source code,
>>> looking for access to native format functionality that is not exposed,
>>> or accessible, through OIIO -- for example, access to the TIFF structure
>>> when dealing with tif files.
>>>
>>> If such functionality, indeed, is not currently pat of OIIO, I will suggest
>>> in
>>> a future email how to do that, and with feedback, would consider putting
>>> in that effort of coding. It is not a lot of work. I think the issue is
>>> whether
>>> this should be considered, philosophically, to become part of OIIO.
>>>
>>> Thank you.
>>>
>> --
>> Larry Gritz
>> [email protected]
>>
>>
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> [email protected]
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>
>
> _______________________________________________
> 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
