Discret68

Ton FocusCube est monté sur quel type de tube ? Il peut y avoir quelques précautions à mettre en œuvre selon que tu utilises une lunette, un newton ou pire, un SCT Celestron. D’une manière générale, je conseille de commencer par chercher le point de focus idéal en utilisant la commande de position du focuser via NINA en relevant la position du moteur (nombre de pas). Et tu relèves la HFR correspondante. Tu décales progressivement le focuser en intra ou extra jusqu’à arriver une HFR d’environ 2,5 fois la HFR mini relevée précédemment, surtout avec un tube équipé d’un miroir secondaire (newton, SCT, ...). Avec une lunette, tu peux aller un peu au delà. Le problème avec un tube équipé d’un secondaire, c’est que l’image défocalisée d’une étoile forme un donut, et la mesure de la HFR devient difficile, avec échec à la clé. D’où la préconisation des 2,5 fois maxi la HFR mini. Tu relèves le nombre de pas correspondant et tu y retires la valeur relevée à la HFR mini. Tu as la valeur de variation pour une demi-course du focuser. Tu divises la valeur obtenue par le nombre de points de mesure (valeur de décalage initial) que tu as saisi pour la courbe automatique. J’ai mis 5 pour mes différents focuser, y compris pour le FocusCube. Tu saisis le nombre résultant dans le champ taille pas FA. Avec ces réglages, la focalisation auto réussit à 100%. D’une manière générale, avant de lancer la focalisation auto, ton focuser doit se trouver dans la plage de mesure de la courbe en V, sinon, NINA va partir dans les choux. JP

Tu peux l'utiliser comme disque de sauvegarde incrémentale (ou séquentielle) des fichiers que tu considères les plus importants. Vu que j'ai installé un SSD également de 2TO pour le système, et vu la place qu'il reste énormément de place, tous les fichiers que je crée (excel, Word, ...) sont placés dorénavant dans un sous-dossier su dossier "Documents" et il sont intégrés dans la sauvegarde séquentielle.

Il n’y a aucun intérêt à diminuer le gain à 252 car tu vas perdre en sensibilité et augmenter le bruit de lecture.

Maintenant que la partie gauche de la courbe est décalée vers la droite et ne touche plus l’axe vertical du graphique, tu peux progressivement réduire la valeur d’offset caméra pour ramener légèrement la courbe vers la gauche, en veillant à laisser un petit jeu à gauche pour garantir l’absence de pixels à 0 adu. si la mesure avec Siril te donne une valeur min inférieure à 200 sur les 3 couleurs et qu’aucune valeur min n’est à 0 adu, tu peux considérer que tu as le bon réglage d’offset caméra.

Vu la courbe SharpCap, tu peux laisser le Gain à 480.

Vu que tu n'as pas de valeur de référence pour l'offset caméra, ce qu'on peut constater pour les derniers essais (offset caméra réglé à priori à 29), ta courbe coupait l'axe vertical du graphique SharpCap. Au début, tu faisais référence à une valeur d'offset caméra à 69. A quoi ressemble la courbe SharpCap à cette valeur d'offset caméra ? Fais un bias à cette valeur et mets une copie écran de la courbe.

Je ne vois pas comment tu arrives à dire que le gain unitaire (1e-/ADU) est obtenu au Gain de 252 pour une valeur de 480 déterminée par le fabricant. Lorsque je regarde tes mesures, à la valeur de Gain 501, tu obtiens un gain de 0.95e-/ADU, ce qui confirme la valeur de 480 pour 1e-/ADU ! Sur tes images précédentes, je ne comprends pas pourquoi Siril te donne une valeur mini RVB de 16 alors que la courbe des 3 couleurs sur SharpCap à l'air de franchement couper l'axe vertical à gauche, ce qui aurait tendance à montrer qu'il y a des valeurs de pixels à 0. Quelle est la valeur d'offset caméra recommandée par le fabricant ? Histoire de voir comment réagit SharpCap (que je connais mal), fais un essai avec une valeur d'offset caméra à 1,5 fois la valeur recommandé, histoire de voir comment réagit la courbe, pour voir si elle se décale effectivement vers la droite et qu'on arrive à voir à combien elle se situe (en terme de %) par rapport à l'axe verticale du graphique. Et profites en pour voir les valeurs min que donne Siril sur la même image. PS : c'est quoi ces taches noires sur ton écran ? Tu fais des repères au feutre directement sur l'écran ? 😄

Comment veux-tu que je te réponde, tu ne précises pas ce qu'il y a comme différence entre tes différentes images ? A part les résultats ! Tes images s'appellent toutes offset42 .... Donc, je ne sais pas ce qu'il y a de différent entre les images ! Essaies de faire des phrases claires, détaillées et précises, sinon, on tourne en rond. Vu la récurrence des questions que tu poses, je me demande si tu lis ce que je t'explique au fil des messages, ou alors, je ne suis pas suffisamment clair. Et comme je l'ai dit à plusieurs reprises, il faut faire la mesure sur un bias de courte durée de pose, inférieur à 1s, de manière à couvrir l'ensemble des durées. Lors en augmentant la durée de pose, la courbe va se décaler(comme on dit) vers la droite, c'est à dire que le niveau adu des pixels va augmenter, donc s'éloigner du 0 adu.

Je parle de la partie la plus à gauche de la courbe et non pas de l'axe qui passe par "la bosse". Il faut s'assurer qu'il n'y a aucun pixel à la valeur 0 adu. Le problème est qu'avec une courbe qui couvre une plage de 0 à 100% de luminosité, il n'est pas aisé de s'intéresser à la plage la plus à gauche (la plage de 0 à 2% de la courbe). Vu que j'utilise SharpCap très rarement, je ne sais pas si on peut dilater l'échelle horizontale. Pourquoi ne procèdes tu pas comme je te l'ai indiqué avec Siril ? Même si tu n'arrives à sélectionner que 95% de la surface de ton image, c'est révélateur. Je viens encore de le tester à l'instant : On voit bien que la zone sélectionnée (6040 x 4013) est très proche de la surface complète du capteur (6072 x 4042 pixels). Mes minis sont respectivement à 28/44/48 adu, ce qui garantit l'absence de pixels à la valeur 0 adu.

J'avoue ne pas bien comprendre ce que tu veux dire, avec la 3ème valeurs dont tu parles (48, 69 puis 68) ! Si à la valeur d'offset caméra réglée à 48, la courbe est collée à gauche (axe verticale), c'est que la valeur de l'offset caméra est trop faible. Si à la valeur d'offset caméra réglée à 69, la courbe est décalée par rapport à l'axe verticale, c'est que la bonne valeur d'offset caméra se trouve entre les 2 valeurs (48 et 69). Fais des mesures avec Siril sur ton image réalisée avec la valeur d'offset caméra réglée à 69 en sélectionnant l'intégralité de l'image. Si la valeur "min" indiquée par Siril est supérieure à 0 et inférieure à environ 200 pour chacune des 3 couleurs RVB, considères que c'est bon. Si au moins une valeur min est égale à 0, il faut augmenter la valeur de l'offset caméra. Si tu as une des 3 valeurs min (RVB) qui est bien au dessus de 200, diminue légèrement la valeur d'offset caméra (de 69 à 64 par exemple) et refais les mesures. L'important est de n'avoir aucun pixel à la valeur 0. Au final, que tu obtiennes une valeur min de 100, 200 ou 400, cela ne va pas changer grand chose. Par contre, au delà, tu peux réduire. Mais il ne faut pas se faire de nœud au cerveau dans le sens où tu vas refaire (impératif) tes darks, bias, flats et brutes à cette même valeur d'offset caméra. Les uns compenseront les autres !

Je dirais aucun, dans le sens où tu fais ta mesure sur une toute petite portion de l'image. Ce n'est pas représentatif. On voit bien que les valeurs mesurées sont pour certaines contradictoires avec l'évolution de la valeur d'offset caméra. Il faut impérativement faire la mesure sur l'image entière car les pixels les plus bas peuvent ne pas être dans la zone que tu as sélectionné. SharpCap (courbes) et NINA (valeurs numériques) font dans chaque cas la mesure sur l'intégralité de l'image. Puisque tu utilises Siril, bases toi sur la valeur "min" (avant dernière de la liste) qui doit être supérieure à 0 pour chacune des 3 couleurs. Et fais en sorte que l'intégralité de l'image soit sélectionnée. J'avais visualisé la vidéo que @TuxAstro a mis en lien. Comme moi non plus, je ne suis pas un aficionados de l'anglais, si j'avais compris à peu près la manip à faire en regardant les images, je n'avais au final pas compris la valeur à retenir puisqu'elle est probablement annoncée de vive voix et pas matérialisée sur un des écrans.

Merci de nous faire un retour sur tes manip, histoire d'enrichir les connaissances communes.

Vu que tu utilises SharpCap, regardes cette discussion sur la méthode à mettre en œuvre pour déterminer la valeur minimale de l'offset caméra. Vu que j'utilise NINA, la méthode avec ce logiciel est un peu plus précise qu'avec SharpCap. Mais ça n'a pas vraiment d'importance. Pour avoir fait la manip sur 2 de mes caméras (ASI2600MC et ASI2600MC), voila les grandes lignes du réglage : Les généralités : Le réglage de la valeur d'offset caméra a pour but de garantir qu'il n'y aura pas de perte de signal dans les lumières basses. Le réglage s'effectue sur une durée de pose courte. Moi j'étais à 0,0001 seconde de temps de pose, soit la valeur d'un bias. Le réglage doit s'effectuer avec un capteur caméra totalement dans le noir. Mettre le bouchon de la caméra et se mettre préférentiellement dans le noir. Placer éventuellement la caméra dans un placard ou un tiroir pour être sûr qu'aucune lumière n'atteigne le capteur. L'objectif est de n'avoir aucun pixel à la valeur 0 adu, ce qui signifie qu'avec SharpCap, toutes les courbes (RVB) doivent avoir leur début de courbe (partie à gauche) au dessus de 0 adu. En fait, on règle le "talon mini" de la caméra L'augmentation de la durée de pose va décaler la courbe vers la droite, donc s'éloigner de la valeur 0 adu. Ce n'est pas un problème dans le sens où toutes tes images seront d'une durée supérieure temps de pose d'un bias. Il n'y a donc aucun risque de perte de signal. Il faut déterminer la valeur de l'offset caméra avec un capteur à la température à laquelle les séquences photos sont réalisées. Le réglage : Tu commences les poses courtes avec la valeur par défaut de la valeur d'offset que tu as saisi. Tu regardes la courbe. Si au moins une des courbes présente des valeurs à 0 adu, tu augmentes la valeur d'offset caméra, et tu refais une pose. Tu analyses les courbes et tu augmentes encore la valeur de l'offset caméra. Si les courbes montrent un espace important par rapport à la valeur 0 adu, tu peux diminuer la valeur de l'offset caméra. Il n'est pas forcément utile d'amener les courbes au plus proche de zéro car toutes les images que tu va réaliser devront l'être avec la même valeur d'offset caméra. Il y aura donc soustraction des différentes valeurs de darks ou offsets sur les images, toutes ayant le même "talon mini". Tu peux vérifier la valeur min obtenu à l'aide d'un logiciel de traitement image. Que ce soit Siril, Pixinsight ou autre, il existe toujours une fonction qui permet d'avoir la valeur mini d'un pixel, voire d'une zone sélectionnée. Exemple : l'analyse de ton bias te donne une valeur mini de 200 adu. Tes darks auront la même valeur mini pour un temps de pose court. les brutes auront également cette valeur mini à laquelle s'ajoutera bien évidemment l'intensité lumineuse de la zone imagée. Pour imager mes propos, voici les mesures obtenues sur mes 2 caméras avec NINA. Dans Nina, il y a une fonctionnalité qui analyse l'intégralité de l'image et qui donne la valeur mini adu mesurée ainsi que le nombre de pixels correspondants à cette valeur. Vu qu'on obtient une valeur numérique, c'est juste plus précis en terme de lecture qu'une courbe. Pour la 2400MC, la valeur standard d'offset caméra est de 30. A ce réglage, la valeur mini adu mesurée sur l'ensemble de l'image est à 804 adu. Pour les mesures, je suis parti à une valeur d'offset caméra de 1 et je suis monté par incrément de 1. A la valeur Offset caméra de 1, la valeur mini mesurée sur l'image est de 0 adu, et il y a 46434 pixels qui sont à cette valeur. En augmentant progressivement la valeur de l'offset caméra, à la valeur 5, on voit qu'il n'y a plus de pixel à 0 adu et que leur nombre se stabilise à une valeur de 1 ou 2. C'est normal, il y a toujours au moins 1 pixel à la valeur mini mesurée. On peut en déduire que la valeur 5 est la valeur mini de l'offset caméra à utiliser. J'ai réglé la valeur d'offset caméra à 6 (petite marge) et j'ai refait mes bibliothèques de darks et bias. Toutes les nouvelles séquences (brutes et flats) sont réalisées avec cette valeur. Lorsqu'on augmente la durée de pose sur des darks, on voit bien que la courbe se décale très légèrement en augmentant, ce qui est conservatif. La valeur médiane donne la valeur adu correspondant à une répartition égale du nombre total de la valeur des pixels au dessous et au dessus de la valeur. Si une caméra a 24000 pixels, on prend la valeur au pixel 12000 après tri croissant des valeurs mesurées de chaque pixel. A ne pas confondre avec la moyenne qui la somme de toutes les valeurs de pixels divisée par le nombre de pixels. Je n'ai pas mis la valeur moyenne, mais elle se trouve à quelques dixièmes de la valeur médiane, ce qui tend à démonter une bonne répartition des valeurs mesurées sur la surface du capteur. Sur ma 2600MC, je mesure un offset caméra mini à la valeur de 18. Mais quand on voit qu'à la valeur recommandée de 30, le mini adu des pixels de l'image est à 142 (ce qui est très proche de zéro par rapport à l'échelle totale du capteur - qui est fonction du gain retenu), on peut dire que la valeur 30 est tout à fait acceptable. Bon, c'est peut-être un peu du chinois, mais dès qu'on commence à faire les mesures, on comprend bien l'impact de cette valeur d’offset caméra sur l'image. Si d'emblée, tu obtiens des courbes qui démarrent au dessus de 0 adu et qu'elles ne sont pas trop éloignées de 0, ne t'embêtes pas à rechercher la valeur optimale, car cela a en fait très peu d'effet. Surtout si tu as déjà des bibliothèques de bias et darks à la valeur préconisée. Si tu as des questions complémentaires, n'hésites pas. Jean-Pierre

C'est une difficulté de plus pour faire de la photo du ciel profond. La problématique d'une monture altazimutale est que bien qu'elle soit capable de suivre un objet, cet objet va subir une rotation de champs. C'est à dire que le ciel va tourner en permanence au niveau de chaque image. C'est ce qu'on appelle la rotation de champ. Plus la durée de pose va être importante, plus les étoiles vont former des arcs de cercle sur les images. Le pire, c'est que cette rotation de champ est évolutive dans le temps, et elle peut également changer de sens de rotation durant une séquence. La valeur de cette rotation de champ dépend également de la portion de ciel visée. Si un décalage de pointage entre les différentes images est compensé par les logiciels de traitement astro, la rotation de champ ne peut pas être corrigée. Cela peut avoir également un impact sur la qualité du suivi en cas d'autoguidage par une caméra annexe car l'étoile qui sert de guidage se situe assez loin du centre de l'image. La rotation de champ entrainant un déplacement de l'étoile guide, le logiciel d'autoguidage va compenser le déplacement de l'étoile guide et va augmenter le décalage globale de l'image. Le seul palliatif est de déterminer le temps de pose maximal en fonction du défaut admis sur les images. Pour bien comprendre ce phénomène, je t'invite à lire ce petit article : http://www.astrociel.net/rotation_de_champ_theorie_rgb.php Il existe bien des systèmes qui permettent de compenser la rotation (dé-rotateur), mais dont le coût est prohibitif par rapport à ton setup. Avec une monture équatoriale, ce problème de rotation de champ n'existe pas car l'instrument tourne sur lui même (comme le ciel). JP

Bravo pour cette nouvelle image. Il y a notamment les extensions aux extrémités des 2 bras que je n’avais jamais vu ...... y compris sur ma version. Va falloir que j’ajoute un paquet de poses.

D’un autre côté, si tu n’utilises pas d’ordi, tu ne peux pas utiliser d’autoguidage, sauf à utiliser une solution autonome. Cela va limiter le temps de pose unitaire, d’autant limité aussi par l’importante focale du C8, y compris avec un réducteur. De quelle monture disposes tu ? Comme le précises Krotdebouc, un ordi à faibles capacités ( une brouette en somme) est largement suffisant pour gérer une séquence astrophoto avec toutes les possibilités de pointage, d’autoguidage, de mise au point initiale et reprises, ....

Je peux t’expliquer comment on procède, mais il faudrait que tu précises quel est le logiciel d’acquisition que tu utilises.

Le CloudWatcher de Lunatico peut être utilisé en autonome après l’avoir parametré avec un ordi. Il faut à minima lui dire ce que tu considères comme étant un ciel acceptable ou non. Apres, tout dépend ce que tu entends par « autonome ».

Ben voilà ! comme ça, on peut mieux découvrir les autres objets présents. Comme je disais dans mon précédent message, il y a également des galaxies identifiées dans le catalogue PGC. Alors certes, nombreuses sont les galaxies de ce catalogue à être de petite taille, mais certaines peuvent révéler un intérêt (amas de galaxies, ...). Et en plus cela met en évidence presque tout ce qu'on peut trouver en fond de ciel. Lorsque l'empilement des brutes est terminé, je fais toujours une résolution astrométrique et une annotation. Ce "brouillon" me permet d'ajuster le "crop de l'image en fonction des objets présents. Je me permets de rajouter une vue (très) réduite de ton image annotée par Pix avec les galaxies PGC en complément. Si tu le souhaites, je peux retirer cette image : Dès que tu modifies les caractéristiques dimensionnelles de l'image, tu perds la résolution astrométrique. D'ailleurs, un message te prévient. Il faut à nouveau relancer la résolution astrométrique avant de pouvoir faire une nouvelle annotation, ou pour lancer un process qui a besoin de cette résolution astrométrique (PhotometricColorCalibration par exemple). En complément, si tu fais un changement de résolution de l'image (par exemple, tu fais une image 2 fois plus petite), il faut corriger la valeur de la focale dans la fenêtre de résolution astrométrique. En général, Pix a tendance à modifier la taille des pixels de la caméra, ce qui en terme de calcul revient au même, mais en ce qui me concerne, je préfère qu'il m'indique une focale équivalente qui correspond à la taille des pixels de ma caméra. Nul besoin d'être très précis sur cette valeur de focale, je me suis rendu compte que Pix est assez tolérant sur ce critère. En mettant une focale avec un écart pouvant atteindre 50% de la valeur réelle, en général, Pix se débrouille très bien. Belle lunette 😋 Et quel type de monture ? Je trouve qu'il est pertinent de préciser brièvement avec quel équipement une image à été prise. Cela permet de voir rapidement si l'objet présenté peut être intéressant avec le setup dont on dispose soi-même. JP

Bon rendu de cette belle galaxie. Au risque de me faire conspuer, moi, j'aurais bien apprécié un peu plus de couleur au niveau de la galaxie .... avec modération bien sûr. Je l'ai testé sur ton image, ça lui va bien. A noter que sur ton image, il y a également 5 galaxies intéressantes (esthétiquement) du catalogue NGC et 48 galaxies du catalogue PGC, plus d'autres répertoriées dans d'autres catalogues. Une vue annotée serait la bienvenue. JP

Personnellement, j'utilise le CloudWatcher Lunatico : https://eu.lunaticoastro.com/product/aag-cloudwatcher-cloud-detector/ Cet appareil n'est pas bon marché mais cela fait maintenant plus de 6 ans que le mien est en service et son fonctionnement irréprochable. Ce système contient un contact relais qui peut être utilisé de différentes manières, soit pour alimenter un appareil (ex : la sirène du village 😄 ), soit comme je fait, raccordé au Raspberry Pi qui gère la allsky et je traite l'info via un petit soft que j'ai développé pour assurer le repli de l'abri si présence de nuages. Les conditions d'activation de ce relais sont paramétrables dans l'application de gestion du CloudWatcher. Il existe des systèmes moins chers créés par des astrams. Exemple : https://astronomie-astrophotographie.fr/Cloud-Detector.html Sur internet, tu fais une recherche "cloud sensor" ou "cloud detector" et tu vas trouver des choses.

Je pense que tu vas prendre de plus en plus de plaisir à exploiter ton matériel en fixe. Les possibilités d'automatisation sont nombreuses. Comme les copains, j'utilise NINA pour les acquisitions qui se débrouille à merveille. Je lance la séquence le soir et je récupère les images le matin suivant, le repli de mon abri et des équipements astro étant complet, y compris la fermeture du toit. Je passe donc des nuits complète en dormant sur mes 2 oreilles. J'utilise différentes cartes relais pour lesquelles j'ai développé des scripts VBS afin de lancer une suite d'actions, principalement pour le repli automatisé. Dans le séquenceur avancé, le script est lancé directement par NINA en fin de séquence (mise en position verticale du newton, fermeture de l’obturateur du newton, park monture, lancement de l'arrêt de la monture (comme c'est une 10Micron, il faut lancer la mise à l'arrêt de la monture comme pour l'arrêt d'un ordi), fermeture du toit, coupure des alimentations des différents accessoires, mise en route du ventilateur de balayage du newton, ....). C'est plus simple et surtout plus souple pour moi de procéder ainsi que de passer par des divers ASCOM. Pour la gestion du mauvais temps qui peut arriver, et la fermeture implicite du toit avant que la pluie n'arrive, j'utilise un CloudWatcher Lunatico ainsi qu'un petit script "veilleur de nuit" qui gère le repli. Si la détection montre qu'au bout d'une dizaine de minutes il y a toujours des nuages (une mesure est effectuée par minute), c'est qu'il est temps de replier. Ce système me permet de poursuivre la séquence si ce ne sont quelques nuages qui passent. Au pire, les mauvaises images sont à jeter. Je remonte bien l'information de l'état du ciel que donne le CloudWatcher dans NINA, par contre, je suis dans l'incapacité actuellement de prendre en compte cette donnée dans le séquenceur avancé de NINA pour lancer le repli global. Les quelques bribes d'explication trouvées sur le net ne m'ont pas aidé. Les essais effectués ont été infructueux. Si quelqu'un a une idée, je suis preneur. JP

Bon rendu pour cette petite galaxie bien esthétique. Je me la suis noté pour lui tirer le portrait dès qu'elle sera accessible 👍 Je suis de ceux qui pensent qu'il faut garder ses images brutes vitam eternam car avec les évolutions des logiciels, plugins et autres, ainsi que ses propres connaissances qui (normalement) évoluent aussi, on finit par disposer de capacités de traitement pour des objets difficile, ou simplement pour améliorer des images qui nous satisfaisaient. Par contre, Il faut du stockage en conséquence. Ces derniers jours, j'ai repris le traitement d'images de début 2016 prises avec ma caméra de l'époque, une Moravian G2-8300 en monochrome. L'amélioration du rendu avec les logiciels d'aujourd'hui est significative. Et je pense que dans quelques années, je pourrai encore améliorer les images. C'est vrai ! Avec une carte graphique à base de RTX4070, j'ai un gain de rapidité de 4 à pratiquement 9 fois sur les process Xterminator par rapport à l'utilisation du processeur (un i7-14700K) pour ces process. Pour ceux que ça intéresse, sous Pixinsight, il est possible de mesurer les performances de sa machine par le biais du menu SCRIPT/Benchmarks/Pixinsight Benchmark, puis clic sur le bouton Run Benchmark. Au départ, vous risquez d'avoir un résultat plutôt moyen pour la partie Swap et donc, réduction des performances globales des traitement. Il y a une astuce très simple pour augmenter les performances de ce Swap 😚

A priori, il suffirait juste de placer la ligne en surbrillance de ma copie écran ci-dessous dans le menu Ressources/Updates/Manage Repositories. Tu lances le "Check for updates" puis la mise à jour. Tu quittes et tu relances Pix. Ce qui est intéressant, c'est de lancer les process XTerminator sur une image avant mise à jour, puis de refaire la même manip après mise à jour. La console donnant à chaque fois la durée de réalisation du process, ça va vite à relever. JP

Salut Serge. Tu vas pouvoir prendre un "certain plaisir" à faire du traitement d'mages 👍 Vu la valeur de SWAP, je suppose que tu as procédé comme je te l'indiquais. As-tu regardé la valeur de SWAP au benchmark avant modification ? Il ne te reste, si ce n'est fait, de mettre en œuvre CUDA, ce qui te permettra également d'aller de 4 à 9 fois plus vite sur les process XTerminator. Timing à récupérer au niveau de la console avant et après installation CUDA. Coté benchmark, avec ma config à peu près similaire, voila ce que j'obtiens : JP