[F] iPad (Informatique et high-tech) - Page 273

Nhut (./8156) :
http://arstechnica.com/apple/2013/09/new-lease-on-life-or-death-sentence-ios-7-on-the-iphone-4/

Cela dit je trouve ça marrant qu'un appareil qui fait tourner l'Unreal Engine 3 en 960 x 640 est incapable de gérer des transparences floutées. C'est totalement stupide.



Comme la PS3 qui fait des graphismes du feu de dieu mais qui prend un temps fou pour afficher des icônes à la con dans son XMB

Iceman RGC (./8154) :
au hasard l'émulateur SNES caché dans un gestionnaire de fichier

The_CUrE (./8155) :
Caché dans un gestionnaire de fichiers?

???

Sûrement une app qui contourne l'interdiction d'apple (ou de nintendo) d'avoir une app émulant une snes en se faisant passer pour un gestionnaire de fichiers.

La "transparence floutée" (flou de convolution) est loin d'être une opération si simple mathématiquement : concrètement ça veut dire attendre la fin du rendu parallélisé en cours, lire beaucoup de pixels, leur appliquer plusieurs étapes de calcul matriciel, rendre le résultat sur une texture aussi grande que le morceau d'origine. C'est consommateur en mémoire, en opérations GPU détournées de leur usage d'origine (même un Core i7 aurait beaucoup de peine à le faire de façon fluide en software), en transparence et nécessite de "staller" le GPU, deux dernières opérations qui cassent totalement les optimisations mises en oeuvre sur les GPUs mobiles, qui rendent possible ce que tu vois dans ton UE3 malgré leur puissance relativement faible.

Quand je dis que la puissance du GPU de l'i4 est limite pour l'écran, il faut savoir que changer de contexte est très lent (max. 4 par frame, et l'OS en a beaucoup besoin pour l'isolation des zones d'écran) et qu'on peut couvrir jusqu'à 7 plans avec une texture avec alpha channel, nombre qui chute à 4 lorsqu'on utilise une texture différente à chaque plan (mais on atteint 15 dans les mêmes conditions sans alpha channel, ce qui signifie pas de transparence ou même pixel invisible, rendant ce mode inutile à part en 3D...). Rajoutes-y un HUD, des particules et autres, et tout simplement du processing et tu vois qu'on n'a pas tant de marge que ça.

Ximoon (./8163) :
Sûrement une app qui contourne l'interdiction d'apple (ou de nintendo) d'avoir une app émulant une snes en se faisant passer pour un gestionnaire de fichiers.

Mais sur un forum aussi respectable que le nôtre.... enfin... un peu de sérieux, non ?

Quel est le nom de cette application qui commet un délit atroce ?

Ah j'en savais rien du tout. Mais c'est marrant quand même. ça a l'air vraiment con comme truc. Qui aurait pu penser qu'un effet de buée sur une vitre pourrait être aussi complexe à reproduire

Plein de gens

...alors qu'il suffit d'être myope

Une astuce que beaucoup gens croient possible avait été mise en place par Apple dans une des beta, ça consiste à rendre la zone d'écran à flouter en tout petit dans une autre texture avec filtrage bilinéaire, puis rendre cette texture agrandie sur la zone de destination. Mais ça marche très mal, vu que pour chaque pixel de la zone de destination, le GPU ne fait pas une moyenne de tous les pixels couverts dans la zone source, mais prend un échantillon de 4 pixels seulement, et fait une moyenne pondérée à partir de ça. On a donc beaucoup trop de contraste entre les pixels de la petite texture, et en agrandissant ça se voit beaucoup, un peu comme les ombres dans Twilight Princess ou Gravity Rush.

very (./8130) :
Clients apple, clients à entuber.... ça me parait logique !

→ ./8118

Ah non Kevin, pas tous les jours, ça suffit!

./8155 ./8162 ./8163 > Non mais c'est vraiment un gestionnaire de fichier (+ lecteur). Il permet, en se connectant à un ftp ou sous son compte Dropbox de lire tout un tas de fichiers. Les roms SNES, c'est juste le cadeau Bonux qu'Apple n'a pas apprécié (compatible iCade et basé sur SNES9X 1.53).
http://lifehacker.com/remote-file-manager-sneaks-a-snes-emulator-onto-your-ip-1245256779

./8156 > Ne pas avoir 2-3 effets de transparence j'avoue m'en foutre royalement, mais en termes de réactions la différence est assez flagrante. Dernièrement je pestais assez souvent et pensais changer de téléphone. Depuis la mise à jour, j'hésite un peu plus. Après j'ai du virer une grosse app (Real Racing 3) pour faire de la place le temps de la mise à jour d'iOS 7(en OTA), puis je l'ai réinstallée ensuite. Peut-être que le système s'est un peu "nettoyé" au passage, je n'en sais rien.

Nhut (./8109) :
Génial, énorme, superbe... Merci Apple (nooooon j'ai dit 'merci Apple' )

Non mais comme ça les anciens appareils ne sont plus si obsolètes que ça. Y en a marre de ces applications qui ne supportent plus les anciens iOS, que ce soit parce qu'ils sont trop vieux ou soit parce que les développeurs ont juste envie de faire chier leur monde

Certains développeurs ont râlé que ça coûtait bonbon de maintenir des versions obsolètes d'App. Du coup, petit retour en arrière, ce sont les développeurs qui décideront.
http://9to5mac.com/2013/09/19/app-store-developers-now-allowed-to-manage-legacy-app-availability/

Sinon TouchID marche même avec les chats (mais c'est plus long...) => http://techcrunch.com/2013/09/19/watch-a-cat-unlock-the-iphone-5s-using-touch-id-and-the-fingerprint-sensor/

Bon j'arrive après la bataille, mais visiblement une semaine de vacances n'a pas suffi à GUNNM, il gagne donc un mois supplémentaire et un kick du topic.

Nhut> J'ai fait une simulation, à voir en 100% pour se donner une idée de ce que ça rendrait sur l'écran (à gauche, le hack dont je parle, à droite la vraie méthode que GIMP a pris 10 secondes à appliquer).



Et encore, en réalité celui de gauche est pire, parce que là j'ai réduit avec un vrai bilinéaire, pas celui plus limité d'un GPU.

Mmh, c'est vrai que c'est assez moche...

Sinon, y'a quoi comme différence entre un filtrage bilinéaire calculé au GPU et la même chose au CPU ? (en fait la formule est tellement simple que je ne vois pas trop là où on peut gratter pour améliorer les perfs au détriment de la qualité)

Brunni (./8174) :
à droite la vraie méthode que GIMP a pris 10 secondes à appliquer

ouch, 10 secondes ? oO En fait, chaque pixel impacte combien de pixels autour de lui ? En se posant la question comme ça, ça a l'air impressionnant.

Normalement, pour de l'interpolation bilinéaire, chaque pixel de sortie nécessite 4 pixels d'entrée.

Mais pour l'effet flouté, c'est beaucou plus que ça, non ? A moins que ce soit ça l'interpolation bilinéraire ? (WP n'a pas été mon amis avec leur sytème d'équation, mais pas d'exemple précis )

cross
Folco parlait du flou : en l'occurrence, ça dépend de l'intensité du flou que tu souhaites #utile#

Folco> 100 pixels dans mon cas. Mais sur l'iPhone à voir le niveau de flou si ça se trouve c'est même encore plus.
Zerosquare> le flou ne se base pas sur le bilinéaire, ça ne veut pas dire "je prends 10 pixels pour en former 1 et ensuite je réétale ce pixel en le mélangeant avec ses voisins pour en former 10 à nouveau". Ca veut dire "chaque pixel de la texture d'origine s'étale et affecte ses 10x10 voisins" (environ). Ca nécessite une zone de destination d'à peu près la taille de celle source comme on le voit, et chaque pixel de destination est le résultat d'un calcul sur beaucoup de pixels source.
Pour comparer avec un monde 3D classique, ça veut dire qu'un "rayon" de lumière formant 1 pixel ne parvient pas directement sur l'écran, mais se disperse sur un cercle d'un rayon de 10 pixels.
Je ne suis plus certain en détail de l'algo, mais il y a des matrices pour calculer ça plus rapidement, et les GPUs sont bons là-dedans, surtout que tu peux bénéficier du parallélisme parce que sauf erreur tu n'as pas besoin d'attendre le résultat de ton voisin pour calculer la valeur de ton pixel : tu fais tes calculs à partir de l'image source seulement.

Ah OK. Je comprends mieux le temps mis pour le calcul (même si 10 secondes sur une machine récente, ça me semble beaucoup... même un flou gaussien ou un redimensionnement Lanzcos n'est pas aussi lent, à moins de prendre un rayon énorme ou d'avoir une image énorme).

Ma machine a dû laguer, et les 10 secondes je les donne à l'arrache. De toute façon comme je ne dis pas ce que c'est comme machine ça ne veut rien dire à part que c'est effectivement une opération coûteuse.

(je veux dire par là que ça prend typiquement bien moins de 10 secondes sur mon PC, et ça m'étonnerait beaucoup que ta machine soit plus lente )

En même temps, GIMP est un outil libre, c'est pas étonnant! #[t]roll#

()

En tout cas sur les images de l'article, je préfère le rendu de iOS 7 sur iPhone 4 à la version "normale", comme quoi...

Brunni, tu peux poster l'originale de ta photo ? Je voudrais faire quelques tests.

Après une (petite) journée de test : bien plus pratique qu'iOS 6, mais en revanche, il faut absolument changer les icônes ().

Et madame râle parce que j'ai mis son iPad à jour, maintenant

Sans lui demander son avis ? C'est pas bien, ça

./8177 > Ça, c'est toujours vrai pour l'agrandissement, mais pour la réduction, si tu veux un truc de qualité optimale, tu dois moyenner tous les pixels qui couvrent la zone du futur pixel. Si tu divises l'image par 2*2, ça fait effectivement 4 pixels pour 1 pixels, mais sinon, ça peut faire beaucoup plus ^^
À ce niveau, tu peux concevoir qu'un GPU se contente d'un algorithme simplifié pour optimiser les performances.
./8176 > Un filtre Gaussien est une fonction 2D continue, donc en théorie, pour calculer un pixel de l'image de destination, tu dois utiliser *tous* les pixels de l'image source. En pratique, tu peux réduire la surface du filtre lorsque les coefficients produits par la fonction deviennent "négligeables", donc ça concerne juste une "zone large" de pixels. (PS: Si tu disposes de suffisamment de mémoire, et en général c'est le cas, tu peux décomposer le filtre 2D en deux opérations de filtrage 1D pour rendre le calcul plus rapide.)

Zerosquare (./8119) :
Apple a fait le très bon choix d'augmenter la taille du capteur plutôt que le nombre de pixels…

Bah euh... ils auraient pu aussi augmenter la taille et le nombre de pixels (en gros garder la même densité) ? Du coup tu pourrais avoir des photos avec une définition plus élevée quand il fait clair, et combiner les pixels pour réduire le bruit quand il fait sombre. Non ?[/cite]Chaque évolution technologique dans le domaine des capteurs permet de réduire le SNR à taille de pixel fixe, mais à technologie équivalente, un pixel plus gros implique toujours un meilleur SNR. Techniquement, si tu augmentes la taille du capteur en même temps que la technologie utilisée, tu gagnes sur les deux plans.
Sinon, le fait d'avoir de plus gros pixels améliore l'image dans toutes les conditions en dehors de la sur-exposition. Ça veut aussi dire que si tu as une zone un peu plus sombre dans une image relativement claire, les détails seront meilleurs (enfin ça va dépendre de l'exposition choisie par le logiciel). Et tu n'auras pas de dégradation subite de la qualité d'image en dessous d'une luminosité arbitraire comme c'est le cas avec l'iPhone 5
Disons que tu mises sur une qualité d'image constante… Et qu'ainsi tes utilisateurs ne seront pas déçus.
(En outre, la taille du capteur et des pixels a une implication sur le choix et le design de l'objectif. Plus les pixels sont petits, plus ton objectif doit être précis ^^)

PS: Si tu regardes ici, tu constateras une nette différence entre les pixels produits par l'iPhone 5 (qui utilisait la technique de combinaison des pixels), et les pixels produits par l'iPhone 5s : http://www.anandtech.com/show/7335/the-iphone-5s-review/10.
Un seul pixel de l'iPhone 5S (en réalité c'est plus compliqué à cause du dématriçage mais bon…) produit un meilleur résultat que plusieurs pixels de l'iPhone 5

Encore une bonne chose (à part pour la batterie peut-être) : http://9to5mac.com/2013/09/19/ios-7-becomes-first-commercial-software-to-support-multipath-tcp-allowing-simultaneous-wi-fi-and-cell-network-connections/

Sauf que j'ai aps encore tout compris comment ça marche, ça.
A priori, si le Wifi a un souci, il passe en 3G ?