Re: [gphoto-devel] Are there any plans to support mass-storage cameras?

[Hubert F. <hfi...@te...>]

Dan Fandrich wrote:

> 
> I don't quite agree. libgphoto2 isn't just a library to get files to
> and from cameras, it's a library to get *pictures* to and from cameras. It's
> a way to abstract the low-level details of various cameras from the
> front-ends that are trying to deal with pictures.  I don't think it's too
> much to ask libgphoto2 to return a picture in a format that a generic front-
> end is likely to be able to handle.  It's optimistic to believe that
> all (or even any) front-ends are going to bother to support some of the
> esoteric and proprietary compressed or raw images that are the only
> types that some cameras give you.  
> 
> libgphoto2's mission is to abstract that kind of knowledge.  Otherwise,
> there will be a clear need for a brand-new library, call it
> libproprietarycameraformatconversion that runs on top of libgphoto2
> and converts all the oddball image formats that libgphoto2 can return
> into something that a front-end has a hope of displaying.  But the
> problem here is that some of the proprietary image formats don't even
> have a standard octet-stream representation that can be the basis of
> a conversion; they're defined by the data and contents of the camera's
> image chips and RAM, and the only place they can really be converted is
> by a program that has that kind of access to the camera--libgphoto2.
> 
> If a front-end really does want the raw image stream, it can use
> --get-raw-data to get it.

But what if that camera is just mass storage device ?


Hub