Nov 24 | 8:50 AM |
Mark M. | has entered the room |
Nov 24 | 8:55 AM |
Mark M. | turned on guest access |
Nov 24 | 9:00 AM |
Jonatan R. | has entered the room |
Jonatan R. |
hey
|
Mark M. |
hello, Jonatan!
|
Mark M. |
how can I help you today?
|
Jonatan R. |
I'm having trouble with integrating camera API
|
Mark M. |
aren't we all :-)
|
Jonatan R. |
:p
|
Jonatan R. |
we have an an app that's loading a preview window at the right scale but then when the picture is snapped the scale and cropping is off
|
Mark M. |
"the scale and cropping is off" on the preview or on the picture?
|
Jonatan R. |
on the picture
|
Jonatan R. | |
Jonatan R. |
that's the code we use for the preview, that I'm trying to apply to the picture
|
Nov 24 | 9:05 AM |
Mark M. |
well, the preview resolution is unlikely to bear much resemblance to the picture resolution
|
Mark M. |
so, you can't just directly apply the calculations you used for the preview resolution to the picture
|
Jonatan R. |
right so the actual picture pixels are different so you're saying I need to re-calculate something that ends up similar instead of trying to apply the same logic
|
Mark M. |
right
|
Jonatan R. |
ok, thanks, that makes sense :)
|
Mark M. |
plus, you'd have to experiment to try to determine how best to approach that
|
Mark M. |
suppose the picture is 4K (3840 x 216)
|
Mark M. |
er, 3840 x 2160
|
Mark M. |
and suppose the preview is 1080p (1920 x 1080)
|
Mark M. |
in that case, the picture is double the size, along both axes
|
Mark M. |
however, that does not necessarily imply that the center of the picture is the center of the preview
|
Mark M. |
I would hope that it would be
|
Mark M. |
but I have had so many assumptions trashed by device manufacturers and their cameras, that I try not to make any more than are necessary
|
Jonatan R. |
right
|
Mark M. |
things get more complicated if the aspect ratios differ
|
Mark M. |
I would probably start off hoping that the picture center and the preview center are the same
|
Mark M. |
but then test the heck out of it
|
Mark M. |
that's why I have The Wall of Phones here in my Secret Mountain Lair
|
Mark M. |
for testing my camera library
|
Jonatan R. |
haha
|
Jonatan R. |
I was hoping I would be able to hook into some cloud lab
|
Jonatan R. |
in the future
|
Mark M. |
IIRC, Amazon's lab is set up that cameras at least kinda sorta work
|
Nov 24 | 9:10 AM |
Jonatan R. |
I was looking at I was looking at https://github.com/commonsguy/cwac-cam2 is there any code there I could use as a reference for what I'm trying to do?
|
Mark M. |
not for this particular problem
|
Mark M. |
I have specifically sworn off trying to worry about synchronizing the preview to the picture
|
Mark M. |
IMHO, the preview is simply for aiming
|
Mark M. |
the picture is what the picture is
|
Mark M. |
and the user can do their own cropping or other post-processing on their own
|
Jonatan R. |
right, except in ios it looks exactly the same so the android versions should too :)
|
Jonatan R. |
it's a selfie snapchat-like app
|
Mark M. |
if you have other questions, go right ahead -- it's a quiet chat room today
|
Jonatan R. |
still on the camera just trying to figure this out: Could I apply a matrix transformation somehow on the actual picture like I'm doing for the preview?
|
Nov 24 | 9:15 AM |
Mark M. |
um, perhaps as part of rendering the image to a Bitmap-backed Canvas or something
|
Jonatan R. |
I found and am trying CaptureRequest.SCALER_CROP_REGION but this only takes a Rect object
|
Jonatan R. |
(on the Capturebuilder)
|
Mark M. |
to be honest, I rarely use Matrix, and I have never tried SCALER_CROP_REGION (as I'm still aiming to support pre-5.0 devices)
|
Jonatan R. |
right
|
Jonatan R. |
I think our pre-5.0 is working better actually
|
Jonatan R. |
for a more simple camera app would it be a problem to just go with the old camera api?
|
Mark M. |
that depends on the scope of "a problem"
|
Mark M. |
tactically, it should be fine, as all devices still need to support it, for backwards compatbility
|
Mark M. |
however, getting device manufacturers to adhere to APIs with respect to cameras is difficult as is
|
Mark M. |
particularly since Google doesn't test it much in the CTS, per yesterday's fireside chat
|
Mark M. |
my expectation is that device manufacturers will focus on the 2nd generation API, for what little compatibility testing they do
|
Mark M. |
which means that over time, support for the 1st generation API will decay
|
Mark M. |
so, given a choice between "use the 1st generation API exclusively" or "don't ship", use the 1st generation API exclusively for now
|
Mark M. |
however, getting reliable support for the 2nd generation API is reasonably important, increasingly so as time passes
|
Jonatan R. |
right
|
Jonatan R. |
make it work for now with old API and then make sure the new one is working asap
|
Nov 24 | 9:20 AM |
Mark M. |
so long as "asap" doesn't degrade to "the Tuesday after never"
|
Mark M. |
you know how engineering priorities can shift
|
Jonatan R. |
what, that never happens right :)
|
Mark M. |
oh, well, I'm only speaking theoretically
|
Jonatan R. |
great, thanks
|
Mark M. |
and *certainly* not from personal first-hand experience
|
Mark M. |
:-)
|
Jonatan R. |
haha
|
Nov 24 | 9:40 AM |
Jonatan R. |
Thanks for the help Mark, I'm going to log out and see if I can make these camera troubles go away.
|
Mark M. |
OK, best o' luck!
|
Jonatan R. |
Thanks, bye
|
Jonatan R. | has left the room |
Nov 24 | 10:00 AM |
Mark M. | turned off guest access |