Aller au contenu
Forum Avex

Philippe

Anciens Avex
  • Compteur de contenus

    1 634
  • Inscription

  • Dernière visite

Messages posté(e)s par Philippe

  1. Merci Pep, Philippe et Didier


    Philippe, oui assez content du setup. Disons que tout fonctionne sans soucis en nomade et en 15min je suis prêt sur le terrain.

    Après, le Riccardi Honders n'est pas une formule simple. De plus, un grand capteur comme le KAF16803 n'est pas vraiment prévu pour le RH200 (il est prévu pour 24x36). Néanmoins il passe plutot bien. Il me reste un peu de tilt mais j'attends MaxSelector pour peaufiner tout ça.

  2. merci pour ce rappel, je n'avais jamais envisagé cela sous cet angle.... :-p

    mais on est bien d'accord que par PIXEL d'une couleur donnée le "rendement' est le même ?! >:p , on arrive à la saturation des pixel à la même vitesse ?

     

    Oui et non : si le pixel répond de la même façon, il n'y en a qu'un sur 4 qui voit les photons. Donc au final, c'est toujours 4x moins de photons.

  3. faux pour la sensibilité couleur (je ne parle pas du L bien sur) c'est strictement identique a une CCD devant laquel on passerai successivement les 3 filtre RVB mais la j'ai l'avantage de faire qu'une passe : trois fois fois moin de boulot

    la resolution est en théorie moin bonne sur un bayer mais la couleur n'est pas vraiment résolvante en tout cas en LRVB (je garde) la sigma pour faire les L

     

    La sensibilité en R,V, B est moins bonne sur une CCD couleur comparé à 3 passes en N&B

    Les canaux ROUGE et BLEU verront 4 fois moins de lumière que un N&B avec filtres. Le canal VERT sera 2x moins sensible.

    Par exemple, en rouge, seulement 1 pixel sur 4 verra de la lumière. Les photons devant arriver sur les 3 autres pixels seront perdus !


    un petit dessin :

    fetch.php?w=&h=&cache=cache&media=apa:theorie:bayer.jpg




    Sinon, pour l'affaire du siècle... [mdr]

    8300 + couleur + bruit de lecture de 9 à 10 e- (alors que certains font 6 à 7 sur le 8300), même à 700€ je ne qualifierais pas ça d'affaire du siècle... Simplement l'affaire de Frédo >:[

    Mais à comparer avec un APN, pourquoi pas. ;)

  4. Merci à vous 2


    Frédo, pourquoi 17h, tout simplement parce que j'étais proche de la pleine lune et que les acquisitions se faisaient à coup de 4 ou 5 images par nuit. J'ai compté le nombre qu'à la fin du séjour !!! Puis ça se débrouillait tout seul alors que je m'attelais au setup "APN".

    Je pensais aussi qu'un peu de fond de ciel nuirait à la qualité d'où un nombre de pose plus important. Je voulais aussi tester le gain en terme de nombre d'image. Il y a une différence significative mais une réduction de bruit optimisée permettrait de revenir à un résultat proche.

    J'ai aussi fait cet objet il y a 3 ans à la FS60 et QSI540 avec un nombre de pose plus faible et avec aussi peu de bruit...


    D'autre part, ma nouvelle méthode de prétraitement est plus à l'aise avec un nombre important de pose afin de mieux affiner les étoiles. Mais ce n'est pas sur ce critère dont je me suis basé. Seulement la pleine lune >:((

  5. Hello

    Ma seule photo CCD de cet été : IC1396 sous la pleine lune

    17h de poses accumulées sur plusieurs jours.


    Le prétraitement sous Pixinsight est "nouveau" et optimisé pour mon RH200.

    Le traitement est assez simpliste (je j'ai meme pas fait de réduction de bruit)


    Les détails de l'acquisition :

    wa_import21.jpg


    L'image :

    Image 4000x4000 en cliquant sur l'image 25% ci-dessous

    IC1396_RH200_25pc.jpg


    Philippe

  6. L'objet en lui-même est joli, rien a redire !

    Les étoiles sont un peu bizarres, même sur la 2nde version, avec leur halo rouge vif :x

    Les extensions sont quand-même limite visible. Un petit peu plus n'aurait pas nuit à la qualité (bruit et dynamique), je pense


    La vraie question est : pourquoi DSS pour la couche oiiiOoO

  7. Pour faire simple : DBE (dynamicBackgr....) "fonctionne" en apparence avec image container MAIS le but étant de recalculer un background différent pour chacune des images (en gardant les mêmes points de controle), DBE ne calcule ce background que lors de la 1ere image du container et ne force donc pas un nouveau calcul à la 2eme, 3eme.. Nième image. De ce fait, le procédé "fonctionne" mais sur un calcul faux, et donc des résultats très aléatoires.

    ABE fonctionne, lui, très bien sur ce mode "process container" pour chaque image.


    Si on souhaite donc utiliser DBE, il faut le faire image par image, à la mano.


    Mes Process v3.60 ne l'indiquent pas car je l'ai découvert il y a peu de temps.

  8. Tout à fait Dieter 333ème du nom !


    MAIS, de toute façon, DynamicBackgroundExtraction ne peut pas être utilisé en image container car il ne peut pas recalculer le gradient de chaque image. Il applique alors à toutes les images le gradient calculé pour la 1ere image.


    Il faut donc utiliser AutomaticBackgroundExtractor, un peu moins performant, mais complètement automatique en session image Container


    De nouveaux process sont en cours, avec pas mal de nouvelles options (APN, drizzle, distorsion, automaticBackground...) mais ça me prendra un peu de temps pour peaufiner tout ça. Surtout quand je vais m'attaquer à une des images de cet été au RH200 qui devrait intégrer tout ça (drizzle, distorsion, ABE,... )

  9. bon j'ai encore à affiner mon traitement sur les étoiles.

    Sinon ben les poses de 20 minutes sont mieux ;-).. moins de bruit, meilleur RSB...mais moins bonne FWHM si je me rappelle bien (normal je pense car les étoiles saturent plus...?)

     

    Beh oui, les 20min c'est mieux !!!

    Si la FWHM augmente, ce n'est pas forcément les étoiles qui saturent mais plutot ton autoguidage qui dérive. Il faut donc affiner les réglages.

     

    Comment poster des brutes pour voir la comparaison ? à part une copie d'écran de mon écran sous Pixin avec les 2 photos ouvertes après une STF ?

     

    Soit tu fais ta copie d'écran en JPG bonne qualité, soit tu mets un BLINK en "GIF" réalisé sous Pix... Parfois c'est plus parlant.

    Sinon, des liens vers les 2 fichiers bruts mais ils doivent faire plusieurs Méga !!!

  10. j'ai normalement atteint (d'après T. Legault) le point où poser plus longtemps n'apporte pas grand chose ;

     

    Ouais, enfin, faut quand-meme sortir des grandes théories de certains... Y a la théorie et il y a la pratique. Et dans 99% des cas, la pratique est bien différente de la théorie. Ceux qui écrivent des bouquins n'ont pas ta camera, ton tube, ta monture, ton ciel.


    Nous aussi, quand on était jeunes, on croyait à tout ça... puis on a fait des images, puis on a fait des traitements, puis on a fait travailler notre cerveau... puis on s'est dit : "mais en fait, c'est des c....ies ????" ^^^^^^^^^^

    J'exagère, bien sur, il y a des règles de base à respecter. Mais beaucoup de choses dépendent de ton setup et de ton ciel.



    D'ailleurs, ton fantome, tu ne verras rien en oiii ni sii. C'est en RVB qu'il donnera son meilleur signal. Mais tu auras du fond de ciel. Le Ha donnera un peu de signal, très propre en posant longtemps, et pourra servir de couche L.

  11. O&V reste un magasin sérieux, avec de bons produits et aussi bien Frank que Gilles connaissent leurs produits. On peut aussi avoir (ou ne pas avoir) des affinités avec tel ou tel vendeur ou avoir eu de bonnes expériences avec ce magasin ou au contraire avoir eu merde sur merde. Je pense que tout le monde ici a eu des expériences réussies ou calamiteuses avec divers magasins en France ou ailleurs.

    Ce n'est pas ça le soucis.


    Le probleme est que sur Mac, il n'y a pas grand chose. Certes, pas mal de constructeurs ont un driver OSX qui fonctionne (pas mal sont quand même estampillés "beta") mais tous les efforts sont mis sur Windows. D'ailleurs, question soft "pas cher" sous Mac, à part Nebulosity et PHDguiding, c'est rare de trouver un "bundle" performant. TheSkyX surement mais là aussi, quid du matos supporté ? Ne serait-ce que les montures. Ou les focusers...

    Ascom n'est pas géré sous OSX (à ce que je sache). Il faut donc obligatoirement des drivers natifs.


    Donc oui, on peut, à la rigueur, dire "sur mac une majorité de CCD sont pilotées", mais on doit aussi avertir de la pauvreté des logiciels existants sous OSX tout en conseillant quand-même de se retrancher sous windows. La, c'est plus sérieux et dans ce cas, je commence à avoir confiance. Sinon... >:p

  12. Merci pour votre aide dans mon projet, par contre, concernant cette caméra moravian 4022, existe t'il des drivers compatible sur Mac.

    J'ai discuté avec gilles Cohen d'Omission qui m'a certifié que les CCD était compatible Mac, ce que je ne pense pas, et aussi, dans le cas ou cette caméra ne serait pas compatible, quelle puissance, capacité et résolution de PC portable me conseilleriez vous

    Merci:

    PS/ Cela fait beaucoup de question mais je souhaiterais vraiment être bien renseigné avant d'investir.

     


    Vraiment étrange que O&V t'affirme que les moravian sont compatibles Mac. En plus ils ne sont pas revendeurs de cette marque.

    J'ai une moravian G4 et je n'ai pas connaissance d'un driver Mac OSX. Et pourtant je suis aussi sur Mac (mais pas pour l'acquisition)


    Sinon, pour simplifier les choses, je te conseille un petit PC portable où tu n'installeras que les logiciels qui te serviront lors de l'acquisition (acquisition, guidage, cartographie...). Une petite config à 500€ suffit amplement. Et puis faire les traitements sur un PC ou Mac plus puissant.

  13. Bah là, dans mon cas, ce n'est pas tellement les disques (SSD d'ailleurs) ni la RAM/swap mais vraiment du calcul (souvent à 100% d'utilisation de chacun des coeurs).

    L'empilement cométaire (avec algo de réjection spéciale) de 300 images de 16Mpix en 3 couches x 32bits couleurs... bah c'est 1h10 de calcul. Après avoir passé des heures pour la registration.

    Mais il est vrai que le résultat est bluffant (quand on voit une brute). On se dit même qu'on a mal cadré car la queue sort du capteur ! Après il faut trouver un compromis entre détails et bruit. Mais le fait de garder un peu de bruit n'est pas non plus choquant.


    Paradoxalement, j'ai tenté Deep Sky Stacker... plus rapide, certes, mais une vraie catastrophe du point de vue du résultat.

  14. Je l'utilise parfois pour certains process spécifiques. Il a des qualités et des défauts. Très gourmand en ressources pour pas mal de process, c'est donc lent sur des images 4k x 4k même avec une machine survitaminée.


    Mais je traite en ce moment des piles d'images à l'APN de la comète Jacques sous Pixinsight et les calculs sont aussi très longs. Ca se chiffre en heures (selon les calculs).

    Je vais aussi commencer le prétraitement d'une image Ha faite cet été au RH200 (50 poses de 20min) et là aussi, j'expérimente une méthode plus complète d'optimisation de prétraitement et j'ai peur que ça mouline pas mal de temps.

×
×
  • Créer...

Information importante

Conditions générales