Apple rachète SnappyCam et sa prise de photos très rapide

Apple rachète SnappyCam et sa prise de photos très rapide

Des améliorations à prévoir dans les prochains iOS

Avatar de l'auteur
Vincent Hermann

Publié dans

Économie

06/01/2014 3 minutes
41

Apple rachète SnappyCam et sa prise de photos très rapide

Apple a confirmé avoir racheté la société SnappyLabs, en fait composée d’un seul homme. Le développeur avait créé une application capable de prendre rapidement une série de photos en pleine définition.

snappycam

De 20 à 30 clichés par seconde en pleine qualité

SnappyCam est une application iOS vendue jusqu’à peu 79 centimes et dont la mission était simple : permettre à l’utilisateur  de prendre très rapidement une série de clichés sans que cela se fasse au détriment de la qualité des photos. En pratique, on pouvait donc en prendre de 20 à 30 par seconde, autrement dit bien plus qu’un iPhone ne propose à la base, même en appuyant très vite sur le bouton. Une vitesse qui peut monter jusqu'à 60 images par seconde en qualité moindre.

 

Depuis quelques jours, la rumeur voulait qu’Apple ait décidé de racheter la société qui se tient derrière SnappyCam, SnappyLab. Une structure qui ne comprend en fait qu’un seul homme, John Papandriopoulos, unique développeur de l’application. Cette dernière avait disparu de l’App Store et beaucoup se demandaient si un tel rachat n’avait pas eu lieu, le site officiel n’affichant plus qu’une page vide.

Un rachat confirmé 

La confirmation est survenue hier via un cours communiqué envoyé au site Re/Code. Apple y utilise sa réplique à tout faire dans ce genre de cas : « Apple rachète de temps en temps de plus petites sociétés technologiques, et nous ne discutons généralement pas de nos objectifs ou plans ». Autrement dit, SnappyLab a bien été racheté, mais Cupertino ne donnera aucune information complémentaire. D’ailleurs, aucune somme n’a été annoncée, comme d’habitude dans ce genre de cas.

 

On se doute évidemment que les avancées de John Papandriopoulos ont fortement intéressé Apple au point de racheter la petite entreprise. On remarquera cependant que la firme procède le plus souvent à ce type d’opération quand elle souhaite renforcer une équipe s’attelant à un aspect spécifique de l’un de ses produits. On a pu le voir récemment avec le rachat de PrimeSense, à l’origine du capteur du tout premier Kinect de Microsoft.

 

TechCrunch avait eu par ailleurs la possibilité de mettre de côté un billet présent sur le blog du développeur, maintenant disparu. Il y expliquait que pour parvenir à un tel résultat, il avait en quelque sorte recréé le format JPEG en étudiant les algorithmes DCT (Discrete Cosine Transform) puis en en écrivant un nouveau, pensé pour le jeu d’instructions NEON SIMD des processeurs ARM. Un travail d’environ 30 000 lignes de code (10 000 en assembleur et le reste en C de bas niveau) complété par un autre sur la compression Huffman qui causait des difficultés.

 

Si ce sont bien ces travaux en particuliers qui ont inspiré le rachat à Apple, il est probable que les résultats soient exploités tels quels ou légèrement adaptés dans un futur produit, pourquoi pas iOS 8 par exemple.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

De 20 à 30 clichés par seconde en pleine qualité

Un rachat confirmé 

Fermer

Commentaires (41)


Enorme boulot qu’il a fait et enorme récompense au final…Tant mieux pour lui. Le travail paie…<img data-src=" />


Ces petites machines ont encore plus de ressources qu’on ne croit. Les vrais développeurs le prouvent (C et assembleur)…




shooting until you let go, just like a dslr



Hmmm… un apn qui enregistre 20 ou 30 images (raw) en rafale avant de caler c’est déjà bien beau, ça ferait ici 1 seconde de rafale (2-3 secondes pour analogie avec un reflex en jpeg) , une idée du fonctionnement du buffer avec cette app sur l’iPhone ?


OMG les “iPhoniens” vont nous mitrailler, vite…sortez vos gilets pare-balles. <img data-src=" />


Une estimation du prix du rachat ? <img data-src=" />

Ca chiffre en milliers ou million d’$ ?


Comment fonctionne la capture de photos sur iPhone ?

Sur Android le développeur n’a, pour l’instant, accès qu’à un JPEG ou au flux vidéo ce qui empêche de telles optimisations bas niveau.



Ce qui est sympathique c’est finalement que le capteur est capable de telles rafales. Ce qui est dommage, c’est qu’Apple ne l’ait du coup pas proposé directement, car c’était un atout évident pour eux.


Le travail paye… Faut voir selon les cas de ce qu’il se passe ensuite.



Il n’y a qu’à voir comment sparrow a été coulé après son rachat (par Google ou apple d’ailleurs ?)



Après si c’est repris pour être utilisé sur le terminal et que le dev est en plus embauché avec une belle paye, la oui c’est cool :) (chose qu’on sais pas pour le moment)


Question pour ceux qui savent:

ça devient quoi NEON en ARM 64-bit ?








ErGo_404 a écrit :



Comment fonctionne la capture de photos sur iPhone ?



Simple, une iMain avec un iFilet à papillon Oops…photos, sort du iMachin et capture les photos au passage, c’est pas évident mais Apple a réussi à faire un système innovant et fonctionnel <img data-src=" /> ————-<img data-src=" />









A-snowboard a écrit :



Il n’y a qu’à voir comment sparrow a été coulé après son rachat (par Google ou apple d’ailleurs ?)







Très bonne question <img data-src=" />



http://sparrowmailapp.com/



<img data-src=" />









ErGo_404 a écrit :



Comment fonctionne la capture de photos sur iPhone ?

Sur Android le développeur n’a, pour l’instant, accès qu’à un JPEG ou au flux vidéo ce qui empêche de telles optimisations bas niveau.



Ce qui est sympathique c’est finalement que le capteur est capable de telles rafales. Ce qui est dommage, c’est qu’Apple ne l’ait du coup pas proposé directement, car c’était un atout évident pour eux.





Le plus simple c’est d’aller sur la page dédié au dev d’app photo<img data-src=" />









ErGo_404 a écrit :



Comment fonctionne la capture de photos sur iPhone ?

Sur Android le développeur n’a, pour l’instant, accès qu’à un JPEG ou au flux vidéo ce qui empêche de telles optimisations bas niveau.





Disons que Apple c’est du open source et que Androïd, c’est fermé ? <img data-src=" />









levhieu a écrit :



Question pour ceux qui savent:

ça devient quoi NEON en ARM 64-bit ?







Toujours du NEON v2, ca n’a pas bougé.









jaretlafoudre a écrit :



Toujours du NEON v2, ca n’a pas bougé.







Merci<img data-src=" />









kade a écrit :



Disons que Apple c’est du open source et que Androïd, c’est fermé ? <img data-src=" />





ça dépends surtout des API, pas de l’ouverture du systeme <img data-src=" />









kade a écrit :



Disons que Apple c’est du open source et que Androïd, c’est fermé ? <img data-src=" />





Rien ne t’empêche sur Android de modifier la façon dont l’appareil photo et l’API concernée fonctionnent.



Par contre ça ne sera pas une simple application à vendre sur le playstore. Et si tu développe une application qui utilise ces modifs elle ne fonctionnera que sur les ROM possédant la modif. Ça limite un peu l’intérêt commercial.









ErGo_404 a écrit :



Ce qui est dommage, c’est qu’Apple ne l’ait du coup pas proposé directement, car c’était un atout évident pour eux.







J’ai l’impression qu’Apple a plus tendance à laisser les développeurs tiers trouver des bonnes idées et les intégrer officiellement par la suite, il me semble que c’est pas la première fois qu’ils rachètent une application tierce pour l’intégrer à iOS.









taralafifi a écrit :



Une estimation du prix du rachat ? <img data-src=" />

Ca chiffre en milliers ou million d’$ ?







En millions sûrement, on parle d’Apple là hein.









NiCr a écrit :



Très bonne question <img data-src=" />



http://sparrowmailapp.com/



<img data-src=" />







C’est donc google (je penchais sur lui sans en être sur)

Sparrow est devenu quoi ? Rien, un soft qui n’est plus trop à jour. Bref google à racheté ce projet pour le couler.

En apparence du moins.







ErGo_404 a écrit :



Comment fonctionne la capture de photos sur iPhone ?

Sur Android le développeur n’a, pour l’instant, accès qu’à un JPEG ou au flux vidéo ce qui empêche de telles optimisations bas niveau.



Ce qui est sympathique c’est finalement que le capteur est capable de telles rafales. Ce qui est dommage, c’est qu’Apple ne l’ait du coup pas proposé directement, car c’était un atout évident pour eux.







iOS7 sur iPhone 5S permet les rafales assez impressionnantes sans interruption. J’en ai fait une de 100 images et encore j’ai arrêté car je voulais pas saturer la mémoire de mon téléphone. (d’ailleurs c’est rigolo de prendre un feux d’artifice comme ça et de faire défiler les images en avance rapide <img data-src=" /> )

Par contre j’ai pas fait le calcul du nombre d’image par seconde. :/









misterB a écrit :



ça dépends surtout des API, pas de l’ouverture du systeme <img data-src=" />





<img data-src=" />

Ici en l’occurrence, le développeur a touché de l’assembleur, donc on est bien loin d’une API.



Ah, il y a donc de vrais développeurs sur les OS mobiles? Voilà qui fait plaisir <img data-src=" />









ErGo_404 a écrit :



Sur Android le développeur n’a, pour l’instant, accès qu’à un JPEG ou au flux vidéo ce qui empêche de telles optimisations bas niveau.





Même en passant par la NDK? Il me semble que l’on peut passer par les interfaces C++ “privées” d’Android pour, par exemple, remplir et afficher une surface (VLC utilise cette méthode il me semble, comme Firefox et d’autres).

Si on ne peut pas utiliser le même genre de bidouillages pour récupérer le flux non compressé issu de l’APN, c’est effectivement sacrément dommage…



Impressionnant de se dire qu’un téléphone actuel pourrait faire du 4k, (en mjpeg) du coup, sans modifications poussées, ça intéresserait les cinéastes je pense… sauf que c’est du 43 pour l’instant .. <img data-src=" />








ErGo_404 a écrit :



Comment fonctionne la capture de photos sur iPhone ?

Sur Android le développeur n’a, pour l’instant, accès qu’à un JPEG ou au flux vidéo ce qui empêche de telles optimisations bas niveau.







Il n’y a pas de problème non plus sur Android, ce n’est pas vraiment le temps de capture qui pose mais la mise en mémoire, le traitement et la (re)compression de l’image. Optimiser en C et assembleur n’est pas un problème non plus sous android (hormis le fait qu’il fasse le faire en fonction du cpu…), et on obtient également des résultats trés satisfaisant en renderscript.

Les appli de ce type sur Android peuvent faire du 60img/s en qualité max sur les modèles android les plus performants. ou plus rapide encore mais avec une résolution moindre.









kade a écrit :



<img data-src=" />

Ici en l’occurrence, le développeur a touché de l’assembleur, donc on est bien loin d’une API.







Programmer en assembleur ne veut pas dire outrepasser les API… Tu appelles les API en assembleurs aussi bien qu’en C/Objective C hein…









jaretlafoudre a écrit :



Programmer en assembleur ne veut pas dire outrepasser les API… Tu appelles les API en assembleurs aussi bien qu’en C/Objective C hein…





Des API en assembleur <img data-src=" />









Tim-timmy a écrit :



Impressionnant de se dire qu’un téléphone actuel pourrait faire du 4k, (en mjpeg) du coup, sans modifications poussées, ça intéresserait les cinéastes je pense… sauf que c’est du 43 pour l’instant .. <img data-src=" />





Je ne pense pas que ça soit très intéressant. Faible dynamique de luminosité, énormément de bruit en basse lumière et focus automatique très lent sont les premiers inconvénients qui me viennent à l’idée. Le fait que ça soit du 43 pour le coup c’est pas très dérangeant. Je ne sais pas non plus s’il est possible de régler le shutter speed sur ce type de capteur (mais ça, apriori on pourrait le faire).



Par contre Nokia utilise ce concept avec ses PureView pour permettre de zoomer sans perte en filmant en enregistrant en Full-HD (Zoom 1,8x pour les 8,7Mpixel, 2,2 pour les 20Mixpel et 3x pour le 41Mpixel), ce qui est très sympathique pour le coup.









trshbn a écrit :



Ah, il y a donc de vrais développeurs sur les OS mobiles? Voilà qui fait plaisir <img data-src=" />





Même en passant par la NDK? Il me semble que l’on peut passer par les interfaces C++ “privées” d’Android pour, par exemple, remplir et afficher une surface (VLC utilise cette méthode il me semble, comme Firefox et d’autres).

Si on ne peut pas utiliser le même genre de bidouillages pour récupérer le flux non compressé issu de l’APN, c’est effectivement sacrément dommage…









trshbn a écrit :



Ah, il y a donc de vrais développeurs sur les OS mobiles? Voilà qui fait plaisir <img data-src=" />





Même en passant par la NDK? Il me semble que l’on peut passer par les interfaces C++ “privées” d’Android pour, par exemple, remplir et afficher une surface (VLC utilise cette méthode il me semble, comme Firefox et d’autres).

Si on ne peut pas utiliser le même genre de bidouillages pour récupérer le flux non compressé issu de l’APN, c’est effectivement sacrément dommage…









Je pense qu’il y a une grosse confusion sur ce que le développeur à vraiment fait…



Il n’a pas accédé directement au hardware du capteur photo en assembleur, il y a accédé normalement via les API (et c’est faisable en assembleur aussi). La grosse partie de son optimisation en assembleur et en utilisant les instructions NEON s’est faite sur la partie accès mémoire et ré-encodage JPEG.



Et oui, il est également possible de réaliser de telles optimisation sur android Via le NDK, bien que maintenant il est plutôt conseillé d’écrire de telles optimisation en renderscript, car vu le nombre de CPU différent que l’on peut rencontrer sous android, le nombre de codepath peut être assez conséquent…









jaretlafoudre a écrit :



Je pense qu’il y a une grosse confusion sur ce que le développeur à vraiment fait…



Il n’a pas accédé directement au hardware du capteur photo en assembleur, il y a accédé normalement via les API (et c’est faisable en assembleur aussi). La grosse partie de son optimisation en assembleur et en utilisant les instructions NEON s’est faite sur la partie accès mémoire et ré-encodage JPEG.



Et oui, il est également possible de réaliser de telles optimisation sur android Via le NDK, bien que maintenant il est plutôt conseillé d’écrire de telles optimisation en renderscript, car vu le nombre de CPU différent que l’on peut rencontrer sous android, le nombre de codepath peut être assez conséquent…







Je suis dubitatif quant à la possibilité d’arriver avec un outil générique au même niveau d’optimisation que quelqu’un qui va pousser à fond toutes les spécificités d’une architecture de processeur.

Après, faut vraiment que le jeu en vaille la chandelle pour se lancer dans la manœuvre «à la mano»









cid_Dileezer_geek a écrit :



Simple, une iMain avec un iFilet à papillon Oops…photos, sort du iMachin et capture les photos au passage, c’est pas évident mais Apple a réussi à faire un système innovant et fonctionnel <img data-src=" /> ————-<img data-src=" />





j’aurais plutôt vu une iPoke-ball… un truc du genre



Moi qui n’y connais rien en code, quelqu’un peut me dire ce que représente 30 000 lignes ?

C’est beaucoup ? pas beaucoup ?

Ca représente combien de temps de travail ?

(pour se faire une idée quoi…)








Ohmydog a écrit :



Moi qui n’y connais rien en code, quelqu’un peut me dire ce que représente 30 000 lignes ?

C’est beaucoup ? pas beaucoup ?

Ca représente combien de temps de travail ?

(pour se faire une idée quoi…)







C’est tres variable et ce n’est surtout pas gage de qualité (voir Kolmogorov).

Cela varie en fonction du langage, de la modularité et des normes de codage…



Pour donnée un exemple, mes étudiants ont un projet de java a faire sur 6 mois et ca tourne entre 5 000 et 10 000 lignes…



Mon projet de recherche, toujours en java fait 15 000 lignes et je travail dessus depuis presque 3ans en visant une certaine généricité et une certaine optimisation…



Pour évaluer un code, on peut donc prendre la théorie algorithmique de l’information (et la théorie de la calculabilité) par exemple ou regardé du coté de Solomonoff ou Chaitin…










Ewil a écrit :



C’est tres variable et ce n’est surtout pas gage de qualité (voir Kolmogorov).

Cela varie en fonction du langage, de la modularité et des normes de codage…



Pour donnée un exemple, mes étudiants ont un projet de java a faire sur 6 mois et ca tourne entre 5 000 et 10 000 lignes…



Mon projet de recherche, toujours en java fait 15 000 lignes et je travail dessus depuis presque 3ans en visant une certaine généricité et une certaine optimisation…



Pour évaluer un code, on peut donc prendre la théorie algorithmique de l’information (et la théorie de la calculabilité) par exemple ou regardé du coté de Solomonoff ou Chaitin…





Euh… j’ai pas tout capté à ta seconde partie <img data-src=" />

J’ai une formation juridique, pas d’informaticien <img data-src=" />









taralafifi a écrit :



Une estimation du prix du rachat ? <img data-src=" />

Ca chiffre en milliers ou million d’$ ?









La news a écrit :



SnappyCam est une application iOS vendue jusqu’à peu 79 centimes



<img data-src=" />















——————–[]









Ohmydog a écrit :



Euh… j’ai pas tout capté à ta seconde partie <img data-src=" />

J’ai une formation juridique, pas d’informaticien <img data-src=" />







Enfaite, pour parlé juridique, comparé la qualité d’un code sur le nombre de ligne, c’est comparer la qualité du code civil avec son nombre d’article :)



Certains scientifiques comme Kolmogorov, Solomonoff et plus tard Chaitin ont proposé des méthodes pour le faire en se basant sur autre chose que le nombre de ligne, on trouve ca en parti dans la théorie algorithmique de l’information



Comme je pense, il y a des indicateur “juridique” pour évalue la qualité d’une loi (récidive ou je ne sais quoi) non ?












kade a écrit :



Des API en assembleur <img data-src=" />







Et ?









Ewil a écrit :



Enfaite, pour parlé juridique, comparé la qualité d’un code sur le nombre de ligne, c’est comparer la qualité du code civil avec son nombre d’article :)



Certains scientifiques comme Kolmogorov, Solomonoff et plus tard Chaitin ont proposé des méthodes pour le faire en se basant sur autre chose que le nombre de ligne, on trouve ca en parti dans la théorie algorithmique de l’information



Comme je pense, il y a des indicateur “juridique” pour évalue la qualité d’une loi (récidive ou je ne sais quoi) non ?





Pour évaluer la qualité des lois aujourd’hui… c’est très simple, elles sont toutes mauvaises. Très mal rédigées (beaucoup trop longues), elles manquent de concision, les termes sont mal choisis et peuvent être interprétés de plusieurs manières différentes. Et vu que les politiciens élus sont tous aussi peu doués les uns que les autres, on aboutit à des choses mal rédigées, mal comprises, mal exécutées et mal sanctionnées….



Mais j’ai bien compris l’analogie :)









jaretlafoudre a écrit :



Et ?





API pour rappel.

Et en français, l’assembleur.



Bon, c’est du Wiki me diras-tu. Mais ça devrait aider à comprendre l’antinomie.



Perso, j’utilise des API sous Windows, et j’ai fait de l’assembleur, mais j’ai pas trouvé de circuit “API” à souder sur la carte mère pour mes instructions <img data-src=" />









Ohmydog a écrit :



Pour évaluer la qualité des lois aujourd’hui… c’est très simple, elles sont toutes mauvaises. Très mal rédigées (beaucoup trop longues), elles manquent de concision, les termes sont mal choisis et peuvent être interprétés de plusieurs manières différentes. Et vu que les politiciens élus sont tous aussi peu doués les uns que les autres, on aboutit à des choses mal rédigées, mal comprises, mal exécutées et mal sanctionnées….



Mais j’ai bien compris l’analogie :)





ils rédigent les articles comme ils parlent, en langue de bois <img data-src=" />









kade a écrit :



API pour rappel.

Et en français, l’assembleur.



Bon, c’est du Wiki me diras-tu. Mais ça devrait aider à comprendre l’antinomie.



Perso, j’utilise des API sous Windows, et j’ai fait de l’assembleur, mais j’ai pas trouvé de circuit “API” à souder sur la carte mère pour mes instructions <img data-src=" />







Toujours pas compris ta blague ni l’antinomie entre API et le langage assembleur…









jaretlafoudre a écrit :



Toujours pas compris ta blague ni l’antinomie entre API et le langage assembleur…





<img data-src=" />





Apple rachète SnappyCam et sa prise de photos très rapide

et la renomme SpyCam <img data-src=" />