Hi,
I think the answer for this issue is quite clear.
We already have queryctrl and querymenu API to check supported CIDs.
That means application or middleware which handles camera device
should check first CIDs supported by the device they handle.
I hope this could be the answer for your concern.
Cheers,
Nate
On Sat, Apr 11, 2009 at 9:30 AM, Theodore Kilgore
<kilgota@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
>
> On Sat, 11 Apr 2009, Dongsoo, Nathaniel Kim wrote:
>
>> On Sat, Apr 11, 2009 at 2:39 AM, Theodore Kilgore
>> <kilgota@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>>>
>>>
>>> On Fri, 10 Apr 2009, Dongsoo, Nathaniel Kim wrote:
>>>
>>>> Hello everyone,
>>>>
>>>> I'm posting this RFC one more time because it seems to everyone has
>>>> been forgot this, and I'll be appreciated if any of you who is reading
>>>> this mailing list give me comment.
>>>
>>> I don't know much about the topic, and I wish I did.
>>>
>>>> I've got a big question popping up handling white balance with
>>>> V4L2_CID_WHITE_BALANCE_TEMPERATURE CID.
>>>>
>>>> Because in digital camera we generally control over user interface
>>>> with pre-defined white balance name. I mean, user controls white
>>>> balance with presets not with kelvin number.
>>>> I'm very certain that TEMPERATURE CID is needed in many of video
>>>> capture devices, but also 100% sure that white balance preset control
>>>> is also necessary for digital cameras.
>>>> How can we control white balance through preset name with existing V4L2
>>>> API?
>>>
>>> Let's broaden the question to include digital still cameras, which
>>> present
>>> similar problems. They present data related to this kind of thing, that
>>> is
>>> obvious. But are there any standard meanings to what is there? Do you
>>> know
>>> anything about that? Can you help?
>>>
>>
>> Exactly right, but we need to see this on the top of the user space first.
>> Because there could be several types of camera devices could be handled.
>> I mean, the device that I'm intending to handle is based on I2C device
>> and the "digital still camera" you issued is totally based on USB
>> communication.
>> That could be different in driver implementation point of view, but
>> user in user space should be using in same manner.
>> And I think I can help to coordinate how to handle them in user space
>> with V4L2 API, but not so much with usb communication with digital
>> still cameras.(but I really want to help indeed)
>> Actually my expertise is totally based on mobile camera devices like
>> camera phone. Even though they are "mobile" camera modules, they are
>> very close to regular digital camera in performance and quality level
>> now days.
>
> Well, I would say of the top of my head that to do things the same way is a
> good idea, whenever possible. But that would appear to me, then, that
> libgphoto2 and things related to v4l would have to do these things, which
> would probably result in some code being incorporated in both places, in the
> end.
>
>>
>>> Two examples:
>>>
>>> The SQ905 and SQ905C cameras in stillcam mode use an allocation table,
>>> which
>>> presents on each line some data about the given image. In this line, byte
>>> 0
>>> is a one-byte code for pixel dimensions and compression setting. Then
>>> some
>>> more bytes give the starting and ending locations of the photo in the
>>> camera's memory (actually irrelevant and superfluous information, because
>>> you can only ask for the photos in sequence, and with a command which has
>>> nothing to do with its memory location at all). Then some more bytes
>>> obviously have something to do with contrast, brightness, white balance,
>>> color balance, and so on. But I have no more idea than the Man in the
>>> Moon
>>> how those bytes are supposed to be interpreted. The SQ905 gives no such
>>> equivalent information while in streaming mode, and so there is nothing
>>> at
>>> all which could be done with the nonexistent information. But the SQ905C
>>> does obviously give such information, in a few bytes in the header of
>>> each
>>> frame.
>>
>> As far as I know, SQ905 (is that actually cheez camera?)
>
> You know, I really do not know the answer to that. The relation between some
> of these outfits is very confusing. But what I *think* I know is
>
> -- Standard & Quality Technology (S&Q, or SQ) <www.sq.com.tw> claims to make
> the chips, and then a lot of companies sell cameras with those chips.
>
> -- CHE-eZ appears to me to be one of the companies which produces cameras,
> which appears to be an activity of, more or less, putting a plastic case and
> a decal or stencil logo on the outside of a plastic case containing the
> electronics which allegedly came from SQ. There are lots of companies that
> do that, as I said.
>
> -- The usb.ids file seems to think that Vendor 0x2770 is some Japanese
> company called NHL. I think that the usb.ids file is probably not correct
> and the number belongs to SQ, which actually makes the chips and is not (for
> example) a mail drop for some other company. But how could I actually know?
> I don't.
>
> What is the real story? Perhaps you can enlighten _me_.
>
> .. ... is a regular
>>
>> digital camera not a mobile camera module, so in that case it could be
>> handled in gspca and totally control through usb_control_msg.
>
> Well the issue here with the supported SQ cameras is to be able to process
> better the data that came out of the camera. There is nothing which can be
> set up through usb_control_msg. These cameras do not have any control
> settings for changing what goes on inside the camera. The SQ905 cameras, as
> I said, do not even provide any data other than direct image data, whle
> streaming (though they do in stillcam mode). So one would not be able to do
> anything at all. The SQ905C cameras will pro
>
>> And with my experience, I think I can help you if I have any kind of
>> datasheet or user manual for that.
>
> The user manuals, of course, just tell how to insert the Windows CD and
> install the drivers. The "datasheets" which were available at the SQ website
> (see above) were not much more than glorified sales brochures. They are not
> available now; I just checked. I do have copies from when they were
> available.
>
>> But even if I don't have datasheet and don't know which message field
>> means what I'm intending to do, I think it could be possible to make
>> it compatible with the parameters I'm trying to make in v4l2 control.
>
> Again, commands which can be sent to the camera are not even part of the
> discussion, from my point of view. My questions are about how to use
> information which the camera sends along with the data in order to improve
> the quality of the resulting images.
>
>>
>>>
>>> The MR97310A cameras give similar information in the header of the photo
>>> itself (and in this case the camera does the same thing in webcam mode,
>>> too). Again, I have no idea either what these mysterious bytes are
>>> supposed
>>> to mean, and how to use them constructively.
>>>
>>> I could mention several other examples, too, but these will do for a
>>> start.
>>
>> OK I've got what you mean. Can I have any information like user manual
>> or datasheet for those SQ and MR devices?
>
> As to the SQ devices, I do not think you will find anything interesting in
> the datasheets.
>
> The MR cameras are apparently using some Pixart chipset (there is a company
> called Mars Technologies, but is it really just a brand name for Pixart?
> Again, who really knows?). I am not sure if I ever did find any datasheets
> from them; back when I was first confronted with an MR97310 camera, it took
> me months even to find the company's website! There are too many companies
> called Mars Technologies.
>
>> If we make a white balance preset api in v4l2, then we should have to
>> implement that functionality in every single camera drivers in v4l2 if
>> those devices are supporting for white balance presets.
>>
>> I want to make this clear that if we have white balance preset api in
>> v4l2, then we can handle every camera device's white balance more user
>> friendly.
>
> Not if there are no such controls available for that camera.
>
>> Thank you for your opinion by the way.
>>
>> Nate
>
> It does seem that we were talking about two different branches of this
> topic. You are looking from the point of view of sending commands to the
> camera to alter what it is doing, with respect to white balance and such. I
> am well aware of the fact that some cameras will let one do that. However,
> my concerns were (and mostly are) about cameras which do not have such
> control options, but which do send you some few bytes of metadata which
> relate to white balance and other image properties. The question is then how
> to use that information constructively.
>
>>
>>>
>>> Are there any agreed-upon standards about this kind of thing, in the
>>> camera
>>> industry? Is there any source of information about it?
>
> Perhaps someone can still answer this question ...
>
> Theodore Kilgore
>
--
========================================================
DongSoo, Nathaniel Kim
Engineer
Mobile S/W Platform Lab.
Digital Media & Communications R&D Centre
Samsung Electronics CO., LTD.
e-mail : dongsoo.kim@xxxxxxxxx
dongsoo45.kim@xxxxxxxxxxx
========================================================
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
