La transformation: La larve quitte son enveloppe pour devenir libellule:
https://framapic.org/fmcfwssevmla/nGqOTXgPBfLO.jpg
Les jeunes libellules profitent du soleil:
https://framapic.org/emxr2GClOokd/gxQXDwgvfNKA.jpg
https://framapic.org/YxPDsx2CIani/WDidVGcjhvWU.jpg
https://framapic.org/rl2N1lXQqDvD/h1i7J9NBisWs.jpg
"RAW est un format de fichier pour les images numériques" https://tinyurl.com/RAW-wikipedia
l'article est assez faux dans son introduction, on devrait dire que le raw est le fichier dump mémoire des capteurs d'image.
pas toujours, je dirais même jamais puisque chaque contructeur y rajoute sa petite sauce
c'est un dump + des exif, toujours.
Stephane Legras-Decussy
On 05/28/2019 05:38 PM, Benoît wrote:
Non, il capte le rouge des pixels x-1, x et x+1. Un pixel est un capteur plus ses deux voisins qui sont de couleurs différentes.
non, un pixel RVB final par photosite monochrome
C'est ç'la ouiiii ! J'ai 1/3 des données captées et je suis meilleur et plus gros qu'une jpeg ?
oui exactement ! étonnant hein :-)
D'où tu sors ton tiers ? Du fait qu'un appareil va utiliser les données de trois capteurs pour faire un pixel ? Si c'est le cas, sache que chaque capteur est utilisé pour générer plusieurs pixels.
oui, c'est bien pour ça seulement 1/3 des RVB sont captés
Bin voyons, tu nous la joues Copperfield maintenant. Il faut pas les imaginer, mon bon Stephane doux rêveur, elles sont là, devant ton nez,
et oui, exactement, il faut les imaginer vu qu'elles ne sont pas captées. par exemple, il y 12 Millions de photosites sur un capteur, pour creer 36 millions de composantes RVG finales.
c'est juste que le format de stockage ne t'es pas compréhensible. Je te rassure : moi non plus j'y entrave que couic, mais je sais qu'elles sont là.
non la preuve, tu as par exemple le constructeur Foveon qui a créé un capteur avec 3 photosites RVB pour chaque pixel, de façon à ne rien imaginer et tout capter et tout mettre dans le raw.
On 05/28/2019 05:38 PM, Benoît wrote:
Non, il capte le rouge des pixels x-1, x et x+1. Un pixel est un capteur
plus ses deux voisins qui sont de couleurs différentes.
non, un pixel RVB final par photosite monochrome
C'est ç'la ouiiii ! J'ai 1/3 des données captées et je suis meilleur et
plus gros qu'une jpeg ?
oui exactement ! étonnant hein :-)
D'où tu sors ton tiers ? Du fait qu'un appareil va utiliser les données
de trois capteurs pour faire un pixel ? Si c'est le cas, sache que
chaque capteur est utilisé pour générer plusieurs pixels.
oui, c'est bien pour ça seulement 1/3 des RVB sont captés
Bin voyons, tu nous la joues Copperfield maintenant. Il faut pas les
imaginer, mon bon Stephane doux rêveur, elles sont là, devant ton nez,
et oui, exactement, il faut les imaginer vu qu'elles ne sont pas captées.
par exemple, il y 12 Millions de photosites sur un capteur, pour creer
36 millions de composantes RVG finales.
c'est juste que le format de stockage ne t'es pas compréhensible. Je te
rassure : moi non plus j'y entrave que couic, mais je sais qu'elles sont
là.
non
la preuve, tu as par exemple le constructeur Foveon qui a créé un
capteur avec 3 photosites RVB pour chaque pixel, de façon à ne rien
imaginer et tout capter et tout mettre dans le raw.
Non, il capte le rouge des pixels x-1, x et x+1. Un pixel est un capteur plus ses deux voisins qui sont de couleurs différentes.
non, un pixel RVB final par photosite monochrome
C'est ç'la ouiiii ! J'ai 1/3 des données captées et je suis meilleur et plus gros qu'une jpeg ?
oui exactement ! étonnant hein :-)
D'où tu sors ton tiers ? Du fait qu'un appareil va utiliser les données de trois capteurs pour faire un pixel ? Si c'est le cas, sache que chaque capteur est utilisé pour générer plusieurs pixels.
oui, c'est bien pour ça seulement 1/3 des RVB sont captés
Bin voyons, tu nous la joues Copperfield maintenant. Il faut pas les imaginer, mon bon Stephane doux rêveur, elles sont là, devant ton nez,
et oui, exactement, il faut les imaginer vu qu'elles ne sont pas captées. par exemple, il y 12 Millions de photosites sur un capteur, pour creer 36 millions de composantes RVG finales.
c'est juste que le format de stockage ne t'es pas compréhensible. Je te rassure : moi non plus j'y entrave que couic, mais je sais qu'elles sont là.
non la preuve, tu as par exemple le constructeur Foveon qui a créé un capteur avec 3 photosites RVB pour chaque pixel, de façon à ne rien imaginer et tout capter et tout mettre dans le raw.
Stephane Legras-Decussy
On 05/28/2019 06:28 PM, efji wrote:
On 28/05/2019 13:20, Stephane Legras-Decussy wrote:
Le 28/05/2019 03:52, efji a écrit :
Le gars avait recopié sans rien comprendre au lieu de copier-coller... et il avait rajouté un espace mal placé.
c'est exactement ce que je dis : ne pas se coltiner de la recopier à la main ! et sinon même un expert peut sans problème faire cette faute d'espace, je dirais même que l'excès de confiance aide à faire des conneries :-) par exemple, cette jolie ligne de commande : ffmpeg -i video_origine.avi input -acodec aac -ab 128kb -vcodec mpeg4 -b 1200kb -mbd 2 -flags +4mv+trell -aic 2 -cmp 2 -subcmp 2 -s 320x180 -title X video_finale.mp4 le gars qui sait exactement ce qu'il fait, il avait l'aprem de libre :-)
Franchement aucune difficulté. "man ffmpeg" t'explique chaque option en détail.
oui, lire tout le man et lire toute les specs h264... je repasse en fin d'aprem... :-)
On 05/28/2019 06:28 PM, efji wrote:
On 28/05/2019 13:20, Stephane Legras-Decussy wrote:
Le 28/05/2019 03:52, efji a écrit :
Le gars avait recopié sans rien comprendre au lieu de copier-coller...
et il avait rajouté un espace mal placé.
c'est exactement ce que je dis : ne pas se coltiner de la recopier à
la main !
et sinon même un expert peut sans problème faire cette faute d'espace,
je dirais même que l'excès de confiance aide à faire des conneries :-)
On 28/05/2019 13:20, Stephane Legras-Decussy wrote:
Le 28/05/2019 03:52, efji a écrit :
Le gars avait recopié sans rien comprendre au lieu de copier-coller... et il avait rajouté un espace mal placé.
c'est exactement ce que je dis : ne pas se coltiner de la recopier à la main ! et sinon même un expert peut sans problème faire cette faute d'espace, je dirais même que l'excès de confiance aide à faire des conneries :-) par exemple, cette jolie ligne de commande : ffmpeg -i video_origine.avi input -acodec aac -ab 128kb -vcodec mpeg4 -b 1200kb -mbd 2 -flags +4mv+trell -aic 2 -cmp 2 -subcmp 2 -s 320x180 -title X video_finale.mp4 le gars qui sait exactement ce qu'il fait, il avait l'aprem de libre :-)
Franchement aucune difficulté. "man ffmpeg" t'explique chaque option en détail.
oui, lire tout le man et lire toute les specs h264... je repasse en fin d'aprem... :-)
Stephane Legras-Decussy
On 05/28/2019 06:34 PM, efji wrote:
C'est mon métier mais là j'avoue que je jette l'éponge.
moi ça me maintient en forme... mais c'est fou de rien retenir à ce point !
On 05/28/2019 06:34 PM, efji wrote:
C'est mon métier mais là j'avoue que je jette l'éponge.
moi ça me maintient en forme... mais c'est fou de rien retenir
à ce point !
C'est mon métier mais là j'avoue que je jette l'éponge.
moi ça me maintient en forme... mais c'est fou de rien retenir à ce point !
Stephane Legras-Decussy
On 05/28/2019 06:46 PM, Benoît wrote:
C'est ç'la oui ! Je préfère le man de HandBrake.
aucune différence... handbrake génére juste à la souris le script ci-dessus.
Dans cette histoire il y a toujours eu un truc qui m'énerve : tous les flash & co font appel à de la compression « standard », mais tous les logiciels que j'ai vu font une décompression puis un réencodage. Je ne comprends pas qu'ils ne sachent extraire les données sans les modifier.
là j'ai beau relire.... euh...
On 05/28/2019 06:46 PM, Benoît wrote:
C'est ç'la oui ! Je préfère le man de HandBrake.
aucune différence... handbrake génére juste à la souris le script ci-dessus.
Dans cette histoire il y a toujours eu un truc qui m'énerve : tous les
flash & co font appel à de la compression « standard », mais tous les
logiciels que j'ai vu font une décompression puis un réencodage. Je ne
comprends pas qu'ils ne sachent extraire les données sans les modifier.
aucune différence... handbrake génére juste à la souris le script ci-dessus.
Dans cette histoire il y a toujours eu un truc qui m'énerve : tous les flash & co font appel à de la compression « standard », mais tous les logiciels que j'ai vu font une décompression puis un réencodage. Je ne comprends pas qu'ils ne sachent extraire les données sans les modifier.
là j'ai beau relire.... euh...
Thierry Houx
Le 29/05/2019 à 00:00, Markorki a écrit :
Thierry Houx a écrit :
Photos proxi, faites avec GX9 + Lumix 100-300. La transformation: La larve quitte son enveloppe pour devenir libellule: https://framapic.org/fmcfwssevmla/nGqOTXgPBfLO.jpg Les jeunes libellules profitent du soleil: https://framapic.org/emxr2GClOokd/gxQXDwgvfNKA.jpg https://framapic.org/YxPDsx2CIani/WDidVGcjhvWU.jpg https://framapic.org/rl2N1lXQqDvD/h1i7J9NBisWs.jpg
Tiens, bonjour, j'aime bien ces bestioles, et donc j'en remets une couche avec 3 images déjà montrées il y a (très) longtemps : (pour voir en grand, cliquer au milieu de l'image, le curseur doit être un "+") http://sebmortum.free.fr/Majencoules/slides/MM_2007-04-27_09-24-19_P1ds.html http://sebmortum.free.fr/Majencoules/slides/MM_2007-04-27_09-24-55_P1ds.html http://sebmortum.free.fr/Majencoules/slides/MM_2007-04-27_09-25-24_P1ds.html
Super, d'autant que trouver une exuvie n'est déjà pas simple.
Le 29/05/2019 à 00:00, Markorki a écrit :
Thierry Houx a écrit :
Photos proxi, faites avec GX9 + Lumix 100-300.
La transformation: La larve quitte son enveloppe pour devenir libellule:
https://framapic.org/fmcfwssevmla/nGqOTXgPBfLO.jpg
Les jeunes libellules profitent du soleil:
https://framapic.org/emxr2GClOokd/gxQXDwgvfNKA.jpg
https://framapic.org/YxPDsx2CIani/WDidVGcjhvWU.jpg
https://framapic.org/rl2N1lXQqDvD/h1i7J9NBisWs.jpg
Tiens, bonjour, j'aime bien ces bestioles, et donc j'en remets une
couche avec 3 images déjà montrées il y a (très) longtemps :
(pour voir en grand, cliquer au milieu de l'image, le curseur doit être
un "+")
http://sebmortum.free.fr/Majencoules/slides/MM_2007-04-27_09-24-19_P1ds.html
Photos proxi, faites avec GX9 + Lumix 100-300. La transformation: La larve quitte son enveloppe pour devenir libellule: https://framapic.org/fmcfwssevmla/nGqOTXgPBfLO.jpg Les jeunes libellules profitent du soleil: https://framapic.org/emxr2GClOokd/gxQXDwgvfNKA.jpg https://framapic.org/YxPDsx2CIani/WDidVGcjhvWU.jpg https://framapic.org/rl2N1lXQqDvD/h1i7J9NBisWs.jpg
Tiens, bonjour, j'aime bien ces bestioles, et donc j'en remets une couche avec 3 images déjà montrées il y a (très) longtemps : (pour voir en grand, cliquer au milieu de l'image, le curseur doit être un "+") http://sebmortum.free.fr/Majencoules/slides/MM_2007-04-27_09-24-19_P1ds.html http://sebmortum.free.fr/Majencoules/slides/MM_2007-04-27_09-24-55_P1ds.html http://sebmortum.free.fr/Majencoules/slides/MM_2007-04-27_09-25-24_P1ds.html
Super, d'autant que trouver une exuvie n'est déjà pas simple.
efji
J'adore les "démonstrations" de René, toujours marquées de la même rigueur scientifique :) On 29/05/2019 06:00, René wrote:
Le lundi 27 mai 2019 03:08:28 UTC-4, efji a écrit :
Oui et non. Ca fait aussi partie des polémiques courantes des débuts du numérique. Les compressions successives ne font rien (vraiment rien) si on ne touche pas l'image, autrement dit les compressions ne s'accumulent pas comme le croient beaucoup de gens. Si on effectue des modifications, ça dépend du type de modification. Par exemple un recadrage ou une retouche locale ne dégradent pas le reste de l'image. Evidemmment si on bouge tous les niveaux on refait une compression. Mais tout ceci est très théorique. Avec des taux de compression faibles (qualité >92) en pratique on ne voit rien.
Cher FJ Il te faudrait diminuer tes certitudes qui portent sur des approximations. Voici une copie d'écran portant 3 images. https://1drv.ms/u/s!AnXJi-qA5kiXqXliq_bxuDELOi6u
et ?
La première est le texte ci-haut dans lequel tu parle des qualités absolues des fichiers jpeg. La copie d'écran originale a été faite en PNG pour ne pas introduire d'artéfacts propres au JPEG.
bien
Puis j'ai converti ce PNG en JPG dans l'imbattable Photoshop, qualité maximum offerte pas ce logiciel
parfait
Ensuite j'ai également converti le PNG en JPG dans Corel PhotoPaint aussi qualité maximum.
idem
Je compare ensuite les 2 images JPG très agrandies. Pardonne moi j'ai
Tu compares quoi en fait. Tu mets les 2 images côte à côte agrandies 12 fois. En effet c'est une façon très courante de regarder les photos :) Et même comme ça c'est kif kif.
choisi ironiquement ta signature F.J. pour cet exemple.
Pas de problème, j'assume. Donc jusqu'ici tout va bien, comme dit le gars qui tombe des twin towers.
J'espère que tu vois sur ton écran que l'image sortie de PS comporte un nuage de pixels tournoyant autour de ta signature tel les abeilles autour de la ruche. Il y a également de ces pixels parasites sur l'image sortie de PhotoPaint.
Badaboum. Un "nuage de pixel". Diantre. Tu veux parler des petits carrés ni blancs ni noirs? Gris donc. Ca s'appelle l'antialiasing et c'est très utile pour lisser les fontes d'écran. Aucun rapport avec le sujet et avec la compression jpg, tu les as aussi sur le png mais tu as bien pris soin de ne pas montrer le png à 1200% :) De toute façon ce que tu crois démontrer ("oui le jpg compresse") n'est pas ce que j'ai dit. Je répète mon assertion et je t'invite à concevoir une procédure pour la contester (tu peux réutiliser ma signature) : "A partir d'une image *déjà en jpg* compressée avec une compression X, l'ouvrir et la fermer au même taux de compression dans un logiciel quelconque, y compris en faisant des modifications mineures comme une retouche locale ou un recadrage, ne dégrade pas l'image."
J'aurais pu pousser la démonstration avec d'autres étapes d'enregistrement
Ah oui ? Fais-le alors !
mais je crois suffisant cet exemple pour démontrer mon désaccord concernant
Il ne s'agit pas de croire...
tes affirmations sur le "vraiment rien" des compressions. Je reconnais que ces "petites différences" ne sont pas perceptibles dans l'usage courant des photos. Mais elles existent et m'interdisent d'affirmer qu'il n'y a pas de différence.
Allez, au travail !
;-)
Pareil
René
J'adore les "démonstrations" de René, toujours marquées de la même
rigueur scientifique :)
On 29/05/2019 06:00, René wrote:
Le lundi 27 mai 2019 03:08:28 UTC-4, efji a écrit :
Oui et non. Ca fait aussi partie des polémiques courantes des débuts du
numérique. Les compressions successives ne font rien (vraiment rien) si
on ne touche pas l'image, autrement dit les compressions ne s'accumulent
pas comme le croient beaucoup de gens. Si on effectue des modifications,
ça dépend du type de modification. Par exemple un recadrage ou une
retouche locale ne dégradent pas le reste de l'image. Evidemmment si on
bouge tous les niveaux on refait une compression. Mais tout ceci est
très théorique. Avec des taux de compression faibles (qualité >92) en
pratique on ne voit rien.
Cher FJ
Il te faudrait diminuer tes certitudes qui portent sur des approximations.
Voici une copie d'écran portant 3 images.
https://1drv.ms/u/s!AnXJi-qA5kiXqXliq_bxuDELOi6u
et ?
La première est le texte ci-haut dans lequel tu parle des qualités absolues
des fichiers jpeg. La copie d'écran originale a été faite en PNG pour ne pas
introduire d'artéfacts propres au JPEG.
bien
Puis j'ai converti ce PNG en JPG dans l'imbattable Photoshop, qualité
maximum offerte pas ce logiciel
parfait
Ensuite j'ai également converti le PNG en JPG dans Corel PhotoPaint aussi
qualité maximum.
idem
Je compare ensuite les 2 images JPG très agrandies. Pardonne moi j'ai
Tu compares quoi en fait. Tu mets les 2 images côte à côte agrandies 12
fois. En effet c'est une façon très courante de regarder les photos :)
Et même comme ça c'est kif kif.
choisi ironiquement ta signature F.J. pour cet exemple.
Pas de problème, j'assume.
Donc jusqu'ici tout va bien, comme dit le gars qui tombe des twin towers.
J'espère que tu vois sur ton écran que l'image sortie de PS comporte
un nuage de pixels tournoyant autour de ta signature tel les abeilles
autour de la ruche. Il y a également de ces pixels parasites sur l'image
sortie de PhotoPaint.
Badaboum. Un "nuage de pixel". Diantre. Tu veux parler des petits carrés
ni blancs ni noirs? Gris donc. Ca s'appelle l'antialiasing et c'est très
utile pour lisser les fontes d'écran. Aucun rapport avec le sujet et
avec la compression jpg, tu les as aussi sur le png mais tu as bien pris
soin de ne pas montrer le png à 1200% :)
De toute façon ce que tu crois démontrer ("oui le jpg compresse") n'est
pas ce que j'ai dit. Je répète mon assertion et je t'invite à concevoir
une procédure pour la contester (tu peux réutiliser ma signature) :
"A partir d'une image *déjà en jpg* compressée avec une compression X,
l'ouvrir et la fermer au même taux de compression dans un logiciel
quelconque, y compris en faisant des modifications mineures comme une
retouche locale ou un recadrage, ne dégrade pas l'image."
J'aurais pu pousser la démonstration avec d'autres étapes d'enregistrement
Ah oui ? Fais-le alors !
mais je crois suffisant cet exemple pour démontrer mon désaccord concernant
Il ne s'agit pas de croire...
tes affirmations sur le "vraiment rien" des compressions.
Je reconnais que ces "petites différences" ne sont pas perceptibles
dans l'usage courant des photos. Mais elles existent et m'interdisent
d'affirmer qu'il n'y a pas de différence.
J'adore les "démonstrations" de René, toujours marquées de la même rigueur scientifique :) On 29/05/2019 06:00, René wrote:
Le lundi 27 mai 2019 03:08:28 UTC-4, efji a écrit :
Oui et non. Ca fait aussi partie des polémiques courantes des débuts du numérique. Les compressions successives ne font rien (vraiment rien) si on ne touche pas l'image, autrement dit les compressions ne s'accumulent pas comme le croient beaucoup de gens. Si on effectue des modifications, ça dépend du type de modification. Par exemple un recadrage ou une retouche locale ne dégradent pas le reste de l'image. Evidemmment si on bouge tous les niveaux on refait une compression. Mais tout ceci est très théorique. Avec des taux de compression faibles (qualité >92) en pratique on ne voit rien.
Cher FJ Il te faudrait diminuer tes certitudes qui portent sur des approximations. Voici une copie d'écran portant 3 images. https://1drv.ms/u/s!AnXJi-qA5kiXqXliq_bxuDELOi6u
et ?
La première est le texte ci-haut dans lequel tu parle des qualités absolues des fichiers jpeg. La copie d'écran originale a été faite en PNG pour ne pas introduire d'artéfacts propres au JPEG.
bien
Puis j'ai converti ce PNG en JPG dans l'imbattable Photoshop, qualité maximum offerte pas ce logiciel
parfait
Ensuite j'ai également converti le PNG en JPG dans Corel PhotoPaint aussi qualité maximum.
idem
Je compare ensuite les 2 images JPG très agrandies. Pardonne moi j'ai
Tu compares quoi en fait. Tu mets les 2 images côte à côte agrandies 12 fois. En effet c'est une façon très courante de regarder les photos :) Et même comme ça c'est kif kif.
choisi ironiquement ta signature F.J. pour cet exemple.
Pas de problème, j'assume. Donc jusqu'ici tout va bien, comme dit le gars qui tombe des twin towers.
J'espère que tu vois sur ton écran que l'image sortie de PS comporte un nuage de pixels tournoyant autour de ta signature tel les abeilles autour de la ruche. Il y a également de ces pixels parasites sur l'image sortie de PhotoPaint.
Badaboum. Un "nuage de pixel". Diantre. Tu veux parler des petits carrés ni blancs ni noirs? Gris donc. Ca s'appelle l'antialiasing et c'est très utile pour lisser les fontes d'écran. Aucun rapport avec le sujet et avec la compression jpg, tu les as aussi sur le png mais tu as bien pris soin de ne pas montrer le png à 1200% :) De toute façon ce que tu crois démontrer ("oui le jpg compresse") n'est pas ce que j'ai dit. Je répète mon assertion et je t'invite à concevoir une procédure pour la contester (tu peux réutiliser ma signature) : "A partir d'une image *déjà en jpg* compressée avec une compression X, l'ouvrir et la fermer au même taux de compression dans un logiciel quelconque, y compris en faisant des modifications mineures comme une retouche locale ou un recadrage, ne dégrade pas l'image."
J'aurais pu pousser la démonstration avec d'autres étapes d'enregistrement
Ah oui ? Fais-le alors !
mais je crois suffisant cet exemple pour démontrer mon désaccord concernant
Il ne s'agit pas de croire...
tes affirmations sur le "vraiment rien" des compressions. Je reconnais que ces "petites différences" ne sont pas perceptibles dans l'usage courant des photos. Mais elles existent et m'interdisent d'affirmer qu'il n'y a pas de différence.
Allez, au travail !
;-)
Pareil
René
benoit
Stephane Legras-Decussy wrote:
On 05/28/2019 06:46 PM, Benoît wrote:
C'est ç'la oui ! Je préfère le man de HandBrake.
aucune différence... handbrake génére juste à la souris le script ci-dessus.
Dans cette histoire il y a toujours eu un truc qui m'énerve : tous les flash & co font appel à de la compression « standard », mais tous les logiciels que j'ai vu font une décompression puis un réencodage. Je ne comprends pas qu'ils ne sachent extraire les données sans les modifier.
là j'ai beau relire.... euh...
Pour les fichiers flash qui contiennent un film, la plupart des utilitaires ne savent pas l'extraire, mais le décode et le réencode. Un peu comme si pour une image dans un pdf il fallait afficher l'image puis l'enregistrer en faisant une nouvelle jpeg. Ou comme si à chaque fois que tu affiches une jpeg tu la réencodes à la fermeture même si tu n'y a pas touché. -- Vie : n.f. maladie mortelle sexuellement transmissible Benoit chez lui à leraillez.com
Stephane Legras-Decussy <no@flash.fr> wrote:
On 05/28/2019 06:46 PM, Benoît wrote:
> C'est ç'la oui ! Je préfère le man de HandBrake.
aucune différence... handbrake génére juste à la souris le script ci-dessus.
> Dans cette histoire il y a toujours eu un truc qui m'énerve : tous les
> flash & co font appel à de la compression « standard », mais tous les
> logiciels que j'ai vu font une décompression puis un réencodage. Je ne
> comprends pas qu'ils ne sachent extraire les données sans les modifier.
là j'ai beau relire.... euh...
Pour les fichiers flash qui contiennent un film, la plupart des
utilitaires ne savent pas l'extraire, mais le décode et le réencode. Un
peu comme si pour une image dans un pdf il fallait afficher l'image puis
l'enregistrer en faisant une nouvelle jpeg. Ou comme si à chaque fois
que tu affiches une jpeg tu la réencodes à la fermeture même si tu n'y a
pas touché.
--
Vie : n.f. maladie mortelle sexuellement transmissible
Benoit chez lui à leraillez.com
aucune différence... handbrake génére juste à la souris le script ci-dessus.
Dans cette histoire il y a toujours eu un truc qui m'énerve : tous les flash & co font appel à de la compression « standard », mais tous les logiciels que j'ai vu font une décompression puis un réencodage. Je ne comprends pas qu'ils ne sachent extraire les données sans les modifier.
là j'ai beau relire.... euh...
Pour les fichiers flash qui contiennent un film, la plupart des utilitaires ne savent pas l'extraire, mais le décode et le réencode. Un peu comme si pour une image dans un pdf il fallait afficher l'image puis l'enregistrer en faisant une nouvelle jpeg. Ou comme si à chaque fois que tu affiches une jpeg tu la réencodes à la fermeture même si tu n'y a pas touché. -- Vie : n.f. maladie mortelle sexuellement transmissible Benoit chez lui à leraillez.com
benoit
Stephane Legras-Decussy wrote:
On 05/28/2019 05:38 PM, Benoît wrote:
Non, il capte le rouge des pixels x-1, x et x+1. Un pixel est un capteur plus ses deux voisins qui sont de couleurs différentes.
non, un pixel RVB final par photosite monochrome
C'est ç'la ouiiii ! J'ai 1/3 des données captées et je suis meilleur et plus gros qu'une jpeg ?
oui exactement ! étonnant hein :-)
D'où tu sors ton tiers ? Du fait qu'un appareil va utiliser les données de trois capteurs pour faire un pixel ? Si c'est le cas, sache que chaque capteur est utilisé pour générer plusieurs pixels.
oui, c'est bien pour ça seulement 1/3 des RVB sont captés
Bin voyons, tu nous la joues Copperfield maintenant. Il faut pas les imaginer, mon bon Stephane doux rêveur, elles sont là, devant ton nez,
et oui, exactement, il faut les imaginer vu qu'elles ne sont pas captées. par exemple, il y 12 Millions de photosites sur un capteur, pour creer 36 millions de composantes RVG finales.
Voir ma réponse plus haut.
c'est juste que le format de stockage ne t'es pas compréhensible. Je te rassure : moi non plus j'y entrave que couic, mais je sais qu'elles sont là.
non la preuve, tu as par exemple le constructeur Foveon qui a créé un capteur avec 3 photosites RVB pour chaque pixel, de façon à ne rien imaginer et tout capter et tout mettre dans le raw.
Le capteur faveon a l'avantage de pouvoir mettre quatre fois de pixels, s'ils ont la même taille que les autres. De plus, il va sortir de l'info pour chaque couleur et c'est à toi de les regrouper. -- Vie : n.f. maladie mortelle sexuellement transmissible Benoit chez lui à leraillez.com
Stephane Legras-Decussy <no@flash.fr> wrote:
On 05/28/2019 05:38 PM, Benoît wrote:
> Non, il capte le rouge des pixels x-1, x et x+1. Un pixel est un capteur
> plus ses deux voisins qui sont de couleurs différentes.
non, un pixel RVB final par photosite monochrome
> C'est ç'la ouiiii ! J'ai 1/3 des données captées et je suis meilleur et
> plus gros qu'une jpeg ?
oui exactement ! étonnant hein :-)
> D'où tu sors ton tiers ? Du fait qu'un appareil va utiliser les données
> de trois capteurs pour faire un pixel ? Si c'est le cas, sache que
> chaque capteur est utilisé pour générer plusieurs pixels.
oui, c'est bien pour ça seulement 1/3 des RVB sont captés
> Bin voyons, tu nous la joues Copperfield maintenant. Il faut pas les
> imaginer, mon bon Stephane doux rêveur, elles sont là, devant ton nez,
et oui, exactement, il faut les imaginer vu qu'elles ne sont pas captées.
par exemple, il y 12 Millions de photosites sur un capteur, pour creer
36 millions de composantes RVG finales.
Voir ma réponse plus haut.
> c'est juste que le format de stockage ne t'es pas compréhensible. Je te
> rassure : moi non plus j'y entrave que couic, mais je sais qu'elles sont
> là.
non
la preuve, tu as par exemple le constructeur Foveon qui a créé un
capteur avec 3 photosites RVB pour chaque pixel, de façon à ne rien
imaginer et tout capter et tout mettre dans le raw.
Le capteur faveon a l'avantage de pouvoir mettre quatre fois de pixels,
s'ils ont la même taille que les autres. De plus, il va sortir de l'info
pour chaque couleur et c'est à toi de les regrouper.
--
Vie : n.f. maladie mortelle sexuellement transmissible
Benoit chez lui à leraillez.com
Non, il capte le rouge des pixels x-1, x et x+1. Un pixel est un capteur plus ses deux voisins qui sont de couleurs différentes.
non, un pixel RVB final par photosite monochrome
C'est ç'la ouiiii ! J'ai 1/3 des données captées et je suis meilleur et plus gros qu'une jpeg ?
oui exactement ! étonnant hein :-)
D'où tu sors ton tiers ? Du fait qu'un appareil va utiliser les données de trois capteurs pour faire un pixel ? Si c'est le cas, sache que chaque capteur est utilisé pour générer plusieurs pixels.
oui, c'est bien pour ça seulement 1/3 des RVB sont captés
Bin voyons, tu nous la joues Copperfield maintenant. Il faut pas les imaginer, mon bon Stephane doux rêveur, elles sont là, devant ton nez,
et oui, exactement, il faut les imaginer vu qu'elles ne sont pas captées. par exemple, il y 12 Millions de photosites sur un capteur, pour creer 36 millions de composantes RVG finales.
Voir ma réponse plus haut.
c'est juste que le format de stockage ne t'es pas compréhensible. Je te rassure : moi non plus j'y entrave que couic, mais je sais qu'elles sont là.
non la preuve, tu as par exemple le constructeur Foveon qui a créé un capteur avec 3 photosites RVB pour chaque pixel, de façon à ne rien imaginer et tout capter et tout mettre dans le raw.
Le capteur faveon a l'avantage de pouvoir mettre quatre fois de pixels, s'ils ont la même taille que les autres. De plus, il va sortir de l'info pour chaque couleur et c'est à toi de les regrouper. -- Vie : n.f. maladie mortelle sexuellement transmissible Benoit chez lui à leraillez.com
benoit
efji wrote:
"A partir d'une image *déjà en jpg* compressée avec une compression X, l'ouvrir et la fermer au même taux de compression dans un logiciel quelconque, y compris en faisant des modifications mineures comme une retouche locale ou un recadrage, ne dégrade pas l'image."
Le mieux est de faire un paquet de retouches, les annuler et enregistrer le fichier qui est donc identique. -- Vie : n.f. maladie mortelle sexuellement transmissible Benoit chez lui à leraillez.com
efji <efji@efi.efji> wrote:
"A partir d'une image *déjà en jpg* compressée avec une compression X,
l'ouvrir et la fermer au même taux de compression dans un logiciel
quelconque, y compris en faisant des modifications mineures comme une
retouche locale ou un recadrage, ne dégrade pas l'image."
Le mieux est de faire un paquet de retouches, les annuler et enregistrer
le fichier qui est donc identique.
--
Vie : n.f. maladie mortelle sexuellement transmissible
Benoit chez lui à leraillez.com
"A partir d'une image *déjà en jpg* compressée avec une compression X, l'ouvrir et la fermer au même taux de compression dans un logiciel quelconque, y compris en faisant des modifications mineures comme une retouche locale ou un recadrage, ne dégrade pas l'image."
Le mieux est de faire un paquet de retouches, les annuler et enregistrer le fichier qui est donc identique. -- Vie : n.f. maladie mortelle sexuellement transmissible Benoit chez lui à leraillez.com
