| 12:14 | <zcorpan> | https://github.com/whatwg/html/issues/192#issuecomment-146830020 - http://people.mozilla.org/~roc/videosync.html is gone :-( |
| 12:18 | <jgraham> | This is what happens if we let roc leave the building :( |
| 15:13 | <zcorpan> | https://github.com/w3c/web-platform-tests/pull/3697 - it's not clear to me why some events have exposed=Worker and some others do not. should all events be exposed? or only those that get fired on objects that are exposed in workers? |
| 16:37 | <annevk> | replied to zcorpan in the PR |
| 17:18 | <jez9999> | Hixie: hi there, I have a question about your data: URI kitchen |
| 17:18 | <jez9999> | Hixie: you have a checkbox for "base64", but looking at your code i'm not sure why you first base64-encode the data, then URI encode it. often. the "=" character will still need to be URI-escaped. what's the purpose of the base64 encoding? |
| 18:47 | <gsnedders> | Given a HTMLScriptElement that has been loaded and executed, is there any way to find the src of what was loaded and executed? Assume the src attribute is unchanged, but the document base URL has. |
| 18:57 | <Domenic> | gsnedders: I can't think of any way. |
| 19:15 | <gsnedders> | Domenic: thx |
| 19:52 | <smaug> | crazy stuff https://wicg.github.io/shape-detection-api/ |
| 19:52 | <smaug> | totally crazy to add that as web api |
| 19:53 | <jyasskin> | smaug: What's your criterion for something to make a good web API? |
| 19:54 | <smaug> | some API which is defined properly and which isn't something one is expected to implement on top of other web APIS |
| 19:55 | <smaug> | this shape detection API is so something which should either run over some code running in workers |
| 19:55 | <smaug> | or it should send data to server side and get it there |
| 19:55 | <jyasskin> | How does the code in the workers access the hardware acceleration? |
| 19:56 | <smaug> | shape-detection-api doesn't seem to in anyway define the algorithms detection is supposed to do |
| 19:56 | <jyasskin> | And it seems bad to require web code to expose extra data to servers, and use extra network bandwidth, for use cases that native apps can achieve locally. |
| 19:57 | <jyasskin> | I think that's a good place the spec could be improved: nail down a little more precisely what these detectors actually detect. |
| 19:58 | <jyasskin> | That said, it also seems bad to forbid UAs from improving their object detection. |
| 19:59 | <smaug> | jyasskin: how is this API supposed to be implemented when it doesn't define what to do? |
| 20:03 | <jyasskin> | Taking just https://wicg.github.io/shape-detection-api/#barcode-detection-api, the spec seems clear enough: it identifies QR codes (it should link to ISO/IEC 18004:2015 or similar to define that) in an image. It doesn't say how to do that, and different implementations might do a better or worse job, making testing difficult, but IIRC the same is true of |
| 20:03 | <jyasskin> | font rendering. |
| 20:10 | <smaug> | qr code detection using JS isn't exactly hard |
| 20:11 | <mcasas> | smaug@ help me understand your concerns |
| 20:11 | <smaug> | my concern is to add API which can be implemented on top of other stuff and/or adding API which isn't defined properly |
| 20:11 | <mcasas> | the API is not providing any sw-fallback. If there's hw acceleration sitting there in the platform, it'll be surfaced; otherwise is JS-business as usual |
| 20:12 | <smaug> | currently the draft is more like an idea |
| 20:12 | <mcasas> | the API is the simplest you can find, and mimics the underlying Hw/OS: pass a single image, get the metadata back |
| 20:12 | <mcasas> | near-zero state |
| 20:13 | <smaug> | which Hw/OS? |
| 20:13 | <jyasskin> | mcasas: I think smaug wants a more rigorous definition of what the HW/OS actually do. |
| 20:13 | <mcasas> | and it lends itself nicely to a polyfill: if there is hw acceleration, use it, otherwise fallback to one of a number of JS libraries implementing, e.g. Face Detection |
| 20:14 | <mcasas> | Yeah, let me pull some links |
| 20:14 | <smaug> | we shouldn't add APIs which possibly require polyfills to the platform |
| 20:15 | <jyasskin> | smaug: So you'd be happier if the spec required UAs to include the software fallback? |
| 20:16 | <tobie> | People going to TPAC, where are you staying? |
| 20:16 | <mcasas> | Currently there are a number of JS libraries providing Face Detection. My idea was that, if the platform (i.e. the OS) provides hardware acceleration for such tasks, developers can use it, saving CPU and battery/energy. |
| 20:16 | <smaug> | jyasskin: right, and some kind of default algorithm how it all should work |
| 20:17 | <mcasas> | AVFoundation face detection is implemented here: https://developer.apple.com/library/ios/documentation/CoreImage/Reference/CIDetector_Ref/ |
| 20:17 | <smaug> | UAs would be then free to implement it all using HW or whatnot, but the end result should be still the same |
| 20:17 | <mcasas> | (-featuresInImage: is the function to actually detect) |
| 20:18 | <mcasas> | Android has the FaceDetector class: https://developer.android.com/reference/android/media/FaceDetector.html |
| 20:18 | <mcasas> | the method being findFaces(...) |
| 20:18 | <smaug> | mcasas: and what about desktop OSes? |
| 20:18 | <mcasas> | Ever since the OpenCV implementation in ~2000, all Face/shape detectors work pretty much the same |
| 20:19 | <mcasas> | so hardware manufacturers just took that pseudo-API |
| 20:19 | <mcasas> | Desktop OSes: I've only seen hw implementation in MacBooks |
| 20:20 | <mcasas> | some USB sophisticated cameras have that as well |
| 20:20 | <smaug> | mcasas: ok, so you'd have sw implementation on Windows and Linux and others |
| 20:20 | <mcasas> | JS comparison of libraries doing face detection: https://github.com/mtschirs/js-objectdetect#performance |
| 20:21 | <mcasas> | Re. having a sw fallback implementation: I don't think the browser should include such a large piece of code, for a perhaps-not-too-popular use case. |
| 20:21 | <mcasas> | If the platform has some accelerated capabilities, the browser may offer them, but the sw-fallback would be getting into deep waters |
| 20:22 | <smaug> | mcasas: so browsers would ship this API only on mobile and OSX? |
| 20:22 | <smaug> | that would be quite some new API |
| 20:22 | <mcasas> | (by "deep waters" I mean e.g. what algorithm to provide, etc) |
| 20:22 | <jyasskin> | mcasas: The CIDetector_Ref API documentation is much less precise than we're used to for web specs. It may be as precise as it can be, given the freedom we want to give implementations to optimize and improve their detection, but you should try to defend that. |
| 20:23 | <jyasskin> | (We could move that to an issue on https://github.com/WICG/shape-detection-api/issues.) |
| 20:23 | <mcasas> | the proposed API would reject the Promises if the underlying platform does not provide such acceleration |
| 20:23 | <mcasas> | it's similar to e.g., having a gps unit or not, |
| 20:23 | <mcasas> | or having a compass |
| 20:23 | <mcasas> | but yeah, feel free to open bugs to the wicg spec |
| 20:49 | <Domenic> | Windows 10 has built-in face detection I am pretty sure |
| 20:49 | <jez9999> | i will never use that malware |
| 20:51 | <mcasas> | domenic@: investigating. Would love to have more platforms. |
| 20:52 | <Domenic> | Windows.Media.FaceAnalysis |
| 20:52 | <Domenic> | https://msdn.microsoft.com/library/windows/apps/dn974129 |
| 20:54 | <jyasskin> | jez9999: Please stay civil on this forum. |
| 20:55 | <jez9999> | how is that uncivil? |
| 20:56 | <mcasas> | https://msdn.microsoft.com/library/windows/apps/windows.media.faceanalysis.aspx yeah, now the question is if that's accelerated in any way (probably yes) |
| 20:57 | <Domenic> | Surfaces come with these Intel depth cameras for real face detection (so you can't fool them by holding up a picture). I guess that's a whole nother thing |
| 20:59 | <KiChjang> | jez9999, i'm not sure how calling an entire software package malware without good reason is considered civil |
| 20:59 | <jez9999> | i have perfectly good reason |
| 21:02 | <Domenic> | jez9999: regardless, it's not appropriate for this channel. |
| 21:08 | <TabAtkins> | Yes, most important is that it's off-topic and annoying. |
| 21:14 | <jgraham> | To be fair there has traditionally been a very loose sense of "off topic" in this channel |
| 21:34 | <TabAtkins> | Yeah, but context-free "windoze sux lololol" is definitely outside of the topic, whatever it is. |