Artyom

שחררתי בטא 11... לקראת זה שאנסה להכניס אותה חנות האפליקציות של גוגל, כמובן האפליקציה חופשית - קוד פתוח https://github.com/artyom-beilis/OpenLiveStacker/releases/tag/beta11 סגרתי את כל המשימות שהיה חשוב לסגור שיפורים הוספתי תמיכה בפרופילים של ההגדרות של המצלמה הוספתי תמיכה ב־auto-stretch של live video הכנסתי מידע על רישיונות קוד פתוח וגם קישור להוראות שימוש לאפליקציה באגים תוקן באג בו מסך תוצאות plate-solver לא קריאות במסכים קטנים תוקן באג בו מסכים עולים אחד על השני תוקנה בעיה של אי דיווח שגיאות במקרה של למשל הדיסק התמלא תוקנה בעיה שלא ביקשתי הרשאות למצלמה ל־UVC הוספתי זום לתוצאה של solver עכשיו הרבה הגדרות שלא נשמרו קודם נשמרות ניסיון לתקן העדר סימן "-" בטלפונים מסוימים במקלדת ב־WebView תוקן מסלול לא נכון שהודאות שגיאה בקיצור כרגע אני מקפיא את הגרסה לתיקוני באגים - או אם ייתגלה מחסור מאוד חמור במשהו שלא קיים. בבקשה הורידו את ה־APK תתקינו ונסו את האפליקציה!

מספר עדכונים שחררתי גרסה בטא 10... https://github.com/artyom-beilis/OpenLiveStacker/releases/ לא אפרט פה את רשימת השינויים, אבל בגדול מאז בטא 9: שיפורי plate-solving, תיקוני באגים ב־UI ועוד, שיפורי ביצועי בנושא ה־streaming ועוד. הכל זה נמצא בדף הפרויקט. אני רוצה לספר סיפור מעט שונה - אולי קצת מבולגן שלשום לקחתי את הטלפון, חיברתי מצלמה וישבתי במרפסת ובפעם הראשונה באמת ישבתי ועשיתי EAA בכיף (ולא במטרה לדבג/לבדוק וכד') די מהר עליתי על מספר באגים: כמו בעיה של Scrolling או בעיות שימוש ב־split screen ועוד. בכל מקרה מעבר לזה שפשוט צילמתי וראיתי כמה דברים דרך המסך בפעם הראשונה גיליתי הרבה דברים לתקן וזה מאוד עזר. גם הדיווחים מהמפתח של ASTAP מאוד עזרו וגם הוא סייע לי רבות לשפר את ה־plate-solving. אני מפתח תוכנה כבר משהו כמו 20 שנה. אחד הדברים הטובים שהיו - אני כותב קוד, בודק ואם אני לא מפשל יותר מידי אפשר לדעת אם הוא עובד. אולי פה ושם כמה תיקוני באגים. פה המצב קצת שונה. כדי לבדוק את האפליקציה אני צריך תנאים. יש דברים שאפשר לבדוק בסימולציה אבל בפועל כשמגיעים למצב האמתי מתגלות כל מיני בעיות קטנות (או גדולות) ויש לזה המון ערך. תכל'ס זה כיף לראות את מה שאתה עושה תופס צורה. מסקנה השימוש באפליקציה נותן ערך מטורף בשיפורים. חבל שיש מעט מאוד ימים בהם אפשר לצפות/לצלם והנה כמה תמונות הכל צולם עם אכרומט של סביבוני 60/400 מצלמה ASI224MC, מחובר לטלפון Galaxy A31 שגם שולט על חצובה עם synscan. זמני חשיפה של 5 שניות, ו־gain=300 עם darks בלי flats (התעצלתי) התמונות נאספו כפי שהן בלי שום עיבוד נוסף - רק חתכתי את המרכז כי האובייקטים קטנים יחסית M3 סהכ" 29 תמונות M53 סה"כ 34 תמונות M64 גלקסיית "העין השחורה" סה"כ 37 תמונות M104 גלקסיית סומבררו סה""כ 19 פריימים - עצרתי ברגע האחרון לפני שענן הרס לי את ה־stack קצת צילומי מסך כולל עבודה עם מסך מפוצל של synscan וה־openlivestacker

הדרך הפשוטה ביותר זה להצטרף לתצפית האגודה הישראלית לאסטרונומיה שפעם בחודש מוציאות תצפית מאורגנת בדרום. כך תוכל לראות גם מגוון טלסקופים וגם להבין מה רואים באמת לפני הרכישה. קח בחשבון שבנגב תנאים תצפית הם מאוד טובות, יש שם חושך ממש. ואפשר לראות עולם ומלואו. בתנאי העיר יכולת צפייה באובייקטים חלל עמוק עמומים תהיה הרבה יותר מוגבלת. אבל עדיין יש הרבה דברים שאפשר לראות מהעיר: כוכבי לכת, ירח, לפצל כפולים ואפילו חלק מגרמי חלל עמוק בהירים ביותר. לגבי הבדל בין דובסוני 5" לשובר אור 102 - ההבדל הוא בעיקר ובעיקר צורת ונוחות השימוש ומחיר. אני משער שאתה מתייחס לטלסקופ שולחני לעומת טלסקופ על חצובה. איזו חצובה? כמובן שאם מסתכלים על 6" לעומת 90ממ אז ההבדל יותר משמעותי מבחינת רמת הפרטים שתוכל לראות, אבל הנוחות בעיניי היא גורם משמעותי מאוד - לקחת את זה ברצינות. אז ההחלטה מה עדיף לך דובסוני שולחני, דובסוני קלאסי שיושב על הריצפה או שובר אור על חצובה - זה נושא מאוד אישי ופרקטי. פה באמת מה שחשוב זה התנאים שלך - מה הנוף מהמרפסת (כמה הוא פתוח) כמה אתה צריך ללכת כדי למקם את הטלסקופ או שאתה מתכנן בעיקר לרדת דרומה לתצפיות.

כמה עדכונים... לא תוכנה אלא יותר שפיכה של תסכול מתמשך מפלטפורמת האנדרואיד. כבר הרבה זמן הציקה לי התראה על התאמה לגרסה הישנה של אנדרואיד. אז שדרגתי ל־SDK העדכני ביותר 33 והדברים לא עבדו, החזרתי ל־SDK של אנדרואיד 10 (שזה 29) והכל חזר לעבוד. המשכתי הלאה. אבל החלטתי להסתכל מהו תנאי הסף לכניסה ל־Google Play כי בסוף צריך יהיה להיכנס לשם. אז אין מנוס - צריך לשדרג לגרסה 33 של SDK. בעיות עד עכשיו שמרתי את הקבצים ספריית DCIM ששם אמורים לשמור תמונות... לא כך? (כמובן היו לי פה ושם עוד קבצים שמתארים איזה תמונות אני שומר) פה התחיל הבלאגן. מסתבר שהחל מגרסה 11 של אנדרואיד היישומים לא מורשים לקרוא/לכתוב לכל בקובץ באיזור המשותף. אז פתאום אני לא יכול לכתוב. זה נכשל. חפרתי וחפרתי כמה ימים. שאלתי בפורומים - אין קול ואין עונה (רלוונטי) עד שגיליתי שבעצם שאם אני רוצה לשמור קובץ גנרי אני צריך לכתוב ל־Documents. לא נוראה. חשבתי שפתרתי את הבעיה. אבל לא... תוך כדי עבודה הסרתי אפליקציה התקנתי מחדש ופתאום אין גישה לספריה להיא יצרה! מסתבר קובץ שנוצר ע"י אפליקציה אחת יהיה חסום לגישה לאפליקציה אחרת גם אם ביקשת הרשאות גישה לאכסון המשותף (זה לא הרעיון?) אז מה, מקסימום למחוק את הספריה וזה? כן, ולא. התגלו שתי בעיות: אם אספת darks - זהו איבדת אותם. אם הסרת והתקנת אפליקציה צור darks חדשים אבל בעיות עוד יותר קשה זה גישה לבסיס הנתונים של ASTAP. לפני זה, פשוט הורדתי zip, פרסתי ושמתי בספרייה הרלוונטית וזה עובד. אבל לא ב־11! אתה לא יכול לפתוח קובץ שנוצר ע"י אפליקציה אחרת אפילו אם מדובר באכסון משותף! אז איך אפליקציות אנדרואיד ניגשות נגיד לתמונות שנוצרו ע"י אפליקציות אחרות? הם בנו API מיוחד שאחרי בקשה לגישה תוכל לקרוא את הקובץ עם ה־API המיוחד הזה! fopen פשוט לא יעבוד. אגב, עד עכשיו לא הצלחתי לפתוח את הקבצים גם דרך ה־API שלהם. אבל זה כנראה עניין שאפשר לפתור. אז כרגע אני צריך לממש 2 דברים כדי שמשהו יעבוד: ייבוא קובצי darks/flats וקובצי db של ASTOP מההתקנה הקודמת ע"י שימוש ב־API שלהם כנראה לטובת שפיות המשתמשים להוסיף הורדה אוטומטית של בסיס הנתונים. בקיצור - שיגעון מוחלט הפיתוח הזה לאנדרואיד. הם ישברו לך אפליקציות בלי לשאול את דעתך. מזל שהרוב כתוב ב־C++‎ עם ממשק web. כי כל השאר זה שיגעון מוחלט.

עוד עדכונים: https://github.com/artyom-beilis/OpenLiveStacker/releases/tag/beta8 בטא 8: תוקנה בעיה של "האפליקציה נבנתה לגרסה ישנה של אנדרואיד התווספה תגבלה על FPS לטובת צילום שמש/ירח - מניעת עומס יתר על אפליקציה תוקנה בעיית עיצוב שונות עדכנה גרסת ASTAP והיא קיימת גם ל־x86/x86_64 בטא 7: התווספה תמיכה ב־stacking ב־mono באמת ולא כמו שהיה קודם כשהפכתי mono ל־rgb פרמטרים של plate-solver נשמרים בין פתיחות אפליקציה תוקנו בעיות תצוה במסכים צרים התווספה תמיכה בהסרט לווינים תוך כדי stacking

שחררתי אתמול את הבטא ה־6ית שכללה תמיכה ב־AE ו־AWB במצלמות ASI תמיכה בפרמטרים של קירור (טעון בדיקה כי אין לי מצלמה מקוררת) בבטא ה־5ית לפני מספר ימים תוקנה בעיית ריצה באנדרואיד 7-8 בה ASTAP לא רץ תוקנה בעיית נוטיפיקציה שלא נמחקה באנדואיד 10 יש כרגע דיון מאוד פורה ב־CN בו מעורב המפתח של ASTAP שעוזר עם המון משוב משמעותי ועובד עם ASI1600MM הנה כמה נקודות לגרסאות הבאות להוסיף שמירת תוצאות ב־SD Card במקום בזכרון הטלפון מאוד שימוש לטפל בשמירה של פרמטרים שהוזנו לבנות presets שבלחיצת כפתור משנים הגדרות מצלמה רעיון למחיקת הלווינים מתמונות live (רעיון טעון המצאות דאטה מתאים) חלק מהדברים דורשים עבודת UI מאומצת.

שחררתי עוד גרסה של OpenLiveStacker: https://github.com/artyom-beilis/OpenLiveStacker/releases/tag/beta4 רשימת השינויים: תיקונים של ניהול ריצת OLS ברקע: יש notification שמראה שהאפליקציה רצה ברקע נפתרה בעיה של סגירת אפליקציה ע"י מערכת ההפעלה אחרי מספר דקות סודר עניין של יציאה מאפליקציה תוקנה בעיית ממשק משתמש בקביעת הפרמטרים של מצלמה - יש כפתור לכל פרמטר וחיוות אם הוא עודכן הוספתי תמיכה ב־plate solving של תמונות שעברו stacking כדי לשפר את הסיגנל הוספתי את ההזזה שצריך לבצע כדי להגיע במטרה ב־Alt-AZ ו־RA/DE הוספתי זריקה של stack לא מוצלח במקום שמירה

אתמול @שחר סיפר לי על הבעיה עם האפליקציה - שלא נתנה לו להגדיר זמן חשיפה או gain. בהתחלה לא הבנתי איך זה יכול להיות אבל אז תוך שיחה הבנתי שמה שבניתי לא עשה שכל. בממשק משתמש בניתי שאחרי שמזינים ערך של זמן חשיפה או gain אני צריך ללחוץ על enter וזה שולח את העדכון. אז מה הבעיות עם זה: זה לא ברור למשתמש שצריך ללחוץ על enter. הרבה יותר ברור ללחוץ על כפתור לטובת עדכון (והכפתור היחיד שהיה שם עשה עבודה אחרת) מכאן שזה לא עבוד. (לא רציתי שכל עדכון ישלח את הערך אוטומטית כי בצד השני יש מצלמה וזה יכול ליצור תופעות לא רצויות גם אין חיווי על זה שהערך נשלח/בוצע עדכון או לא. זו גם בעיה. גם הבנתי שיש פערי נוחות בשימוש ב־plate solving דברים קטנים אבל חשובים מאוד. זה ההבדל בין לפתח UI (ממשק משתמש) לבין UX (חווית משתמש) שיכולה להיות מאוד מפתיעה (בד"כ לא לטובה) בקיצור - אני אשמח אם עוד אנשים יעזרו בבדיקות גם אם אתם עובדים עם ּSharpCap ולא מתכוונים לעבור ל־tablet. כי מבחינתי החוויות הישירות של המשתמש הם בגדר זהב - הם נותנים לי מידע והבנה של מה חסר - במיוחד שאני לא מפתח UI במקצועי.

שחררתי גרסה שלישית https://github.com/artyom-beilis/OpenLiveStacker/releases/tag/beta3 בין השינויים: תמיכה ב־plate-solving עם astap תמיכה במצלמת watch-directory שמאשפרת להתחבר לכלים אחרים שינוי קונפיגורציה בלינוקס ה־SDK של ASI מעודכן עם תיקוני תמיכה באנדרואיד חדש ועוד

כמה נקודות. בשלב ראשון הייתי מוותר על צילום. גם אם זה נראה מפתה לשתף מה שאתה רואה זה כברת דרך מצפייה לצילום וזה מורכבות ברמה אחרת לגמרי (אלא אם מדובר בירח שאותו אפשר לצלם גם עם טלפון) לגבי goto כמו שיוסי כתב. זה ייקח לך נתח לא קטן מהתקציב. יש לא מעט פתרונות אחרים. ביניהם הפתרון הזה (גילוי נאות אני פיתחתי אותו) אם אתה מחפש דובסוני משהו כמו 8" מציע שתבדוק גם בחנויות בארץ (וודא זמינות במלאי לפני שמזמין) תחשוב גם עניין משקל, גודל ויכולת צפייה מהבית (גישה לחלקת שמיים פתוחים) ונגישות הטלסקופ: כי יש לא מעט דברים לראות גם מהבית (ירח כוכבי לכת כפולים ועוד)

הנה דוגמאות של stacking ו־autostretch שעשיתי חלק עשיתי ריצה מחדש ב־offline - אחרי שיפורי אלגוריתמים ותיקונים, אבל הכל אוטומטי בדיוק כמו שהיה מתבצע בזמן צילום live. הכל צולם ב־bortle 8 רחובות עם הריג למעלה: AZ GTi, SVBony sv501p 60mm/400m achromat, ASI ZWO 224MC, IR/UV cut Svbony filter M38 Starfish, 26 x 2s, with darks M82 Cigar Galaxy, 90 x 2s, with darks + flats + dark_flats M42 Orion Nebula, 42 x 5s, with darks M1 Crab Nebula, 139 x 1.5s, with darks NGC2024 Flame Nebula, 101 x 2s, with darks

עדכון: שחררתי עוד גרסה: https://github.com/artyom-beilis/OpenLiveStacker/releases יש הרבה תיקוני הקשורות ליציבות (מסתבר שהדרייבר של ASI של אנדרואיד ו־RTTI מתנגשים. כתבתי להם, מקווה שיתיחסו) שיפורי ביצועים רבים. כרגע האפליקציה בכיף עושה stacking לשתי תמונות 1920x1080 בשניה. אבל עם המשך שיפורים אני חושב שאצליח להגיע ל־4 תמונות בשניה - לטובת stacking ללא עקיבה שיפורים שונים: תמיכה ב־binning ב־ASI שיפורי UI קטנים (להגדיר שדות מספריים כמספריים) לטובת לינוקס/pi/אינטגרציה עם indi - הוספתי דרייבר שמאפשר להפוך ספריה שתמונות נכתבות לתוכה ל"מצלמה וירטואלית" מה שמאפשר באופן תיאורתי לעבוד עם כל מצלמה ש־KStars/EKOS יודעים לשמור תמונות עבורה הנה מדריך: https://github.com/artyom-beilis/OpenLiveStacker/wiki/Open-Live-Stacker-Manual#using-watch-directory-driver והנה תמונות של live action - לצערי מזג האוויר לא משתף פעולה יותר מידי בינתיים

בשנה הבאה מרתון EAA עם OpenLiveStacker? 🙂 מרשים ביותר!

אגב, לגבי פיינדר. פשוט הייתי שם red dot קל - יש כאלה שבאים עם 2 חורים ועולים גרושים. הפיינדר 24x6 אומנם עובד אבל הרבה פחות נוח מ־rdf.

רק תיקון קטן - גם אכרומט 70 מ"מ הוא דאבלט - רק לא ED אלא רגיל crone+flint אם זה היה סינגלט היית רואה את הכל בצבעי הקשת וכן, האכרומטים הפשוטים הם באמת אחלה

שחררתי גרסת בטא ראשונה של Open Live Stacker (או OLS בהמשך) פרוייקט: https://github.com/artyom-beilis/OpenLiveStacker הוראות שימוש: https://github.com/artyom-beilis/OpenLiveStacker/wiki/Open-Live-Stacker-Manual ה־APK להורדה: https://github.com/artyom-beilis/OpenLiveStacker/releases אז במה מדובר? אפילקציית live stacking (וגם תוכנה ללינוקס) שמאפשרת לחבר מצלמת ASI או מצלמה מבוססת פרוטוקול UVC (כמו SVBony 105/205) ישירות לטלפון/טאבלט של אנדרואיד לעבוד איתו ישירות בלי צורך במחשב נייד בשטח האפליקצייה שוחררה כקוד פתוח כמובן תחת GPL התוכנה/אפליקציה בנויה ב־C++‎ עם ממשק משתמש מבוסס דפדפן - כך שהיא רצה על לינוקס וגם על אנדרואיד. היא אמורה לעבוד גם על raspberry pi - אבל לא בדקתי כי אין לי כזה. רק צריך לבנות ולבדוק. דרייברים הם נטענים דינאמית ולמעשה אם יש API של מצלמה זה ממש לא אמור להיות מסובך לחבר אותו לאפליקציה בדקתי אותה עם ASI224MC ועם svbony sv105

אגב לפי הריג הזה R=1.4 (gain=200), F/5, 2.4um, QE=81, Mono החשיפה האופטימלית לפי ההרצאה: Bortle 8 - 1.6s Bortle 5 - 8.7s

כן. אבל צריך לשים לב שיש גם מדרגות ב־gain שהההגדלה שלו מורידה עד נקודה מסויימת רעש היחסי. או ליתר דיוק מאפשר לספור נכון כל אלקטרון... לכן רואים בגרפים ש־readout noise יורד עם הגדלה של gain אבל ברור שאתה גם מאבד טווח דינאמי. אבל גם אם מגזימים זה פוגע, עכשיו הסתכלתי בגרף של 224 ורואים שכשה־gain הוא 350 אז הטווח הדינאמי יורד 8 ביט בפועל. כך שנראה לי המקסימים שכדאי לי לעבוד עם 224 זה אולי 300 כי אחרת הטווח הדינאמי נפגע יותר מידי בלי להוסיף מידע. בהתחשב בעובדה שאפשר לעשות stretch אחר כך לא בטוח שכדאי לעבוד עם gain גבוהה מידי. מה שכן, מדגדג לי לבדוק מה תהיה התוצאה עם סביבוני 105 עם gain גבוהה.

זמן חשיפה אופטמלי הוא בסופו של דבר פונקציה של אופטימיזציה של רעש מול סיגנל ותו לא. (תסתכל בהרצאה, זו המתמטיקה שם) מבחינה הזו גם EAA וגם AP מנסים להגיע לתמונה עם הרבה פרטים, ההבדל הוא ב"איכות" התוצאה, ברעש ובעיבוד שאפשר לעשות. לכן, פה אני לא חושב שיש הבדל מהותי. שים לב, תוספת 5% ביחס לזמן חשיפה הכולל הסופי (קרי מספר תמונות כפול זמן חשיפה של תמונה בודדת). השאלה שנשאלת בהרצאה - בהנתן זמן קבוע על האובייקט, הוא זמן חשיפה של תמונה בודדת האופטימלי. (כאשר תמיד ארוך יותר טוב באופן תיאורתי) אבל אז נקודת אופטימום אומרת, אם אני מוכן לספוג תוספת קטנה ברעש, לכמה אוכל לקצר את זמן החשיפה. אם אתה מוכן לשלם 10% אז הפקטור C קטן מ־10 ל־5 ואז זמני החשיפה מתקצרים פי 2 (קרי בריג שלי שנייה 1 בבורטל 8 ו־5 שניות בבורטל5) בקיצור - אני מציע שתראה את ההרצאה. אני באמת לא הייתי הבדל בכמות הפרטים בין 2 שניות ו־5 שניות (אפילו 10 אבל אז היו לי בעיות של עקיבה)

שאלה מצוינת ואני אסביר: קודם כל יש הרצאה מאוד מעניינת על נושא בחירת זמן החשיפה: https://www.youtube.com/watch?v=3RH93UvP358 שלסיכום הכי מהיר זמן חשיפה אופטימלי הוא כאשר C=10 עבור מצב בו אתה יכול להרשות לעצמך 5% תוספת רעש, ה־R זה readout noise - במקרה של gain=200 זה יוצא בסביבות 1 ו־p זה light pollution factor שאפשר לחשב בעזרת הכלי הזה שפחות או יותר אומר כמה אלקטרונים לפיסקל לשניה מגיעים. אפשר לחשב אותו פה http://www.tools.sharpcap.co.uk במקרה שלי פיסקל צבעוני 3.75um ה־F/6.6, ה־quantum efficient = 75% ובורטל 8, הערך p = 4.92 מה שאומר שזמן החשיפה האופטימלי הוא בערך 2 שניות. כמובן ברגע שעוברים לבורטל 5 (נגיד מצפה משואה) אז זמן חשיפה אופטימלי מיד עולה לכ־12 שניות וביער חולדה (בורטל 6) זה כ־5 שניות. אם אני משתמש בפילטר צר אז עוד פעם, זמן חשיפה אופטימלי מתארך משמעותית מיד. ובאמת, לא ראיתי הבדל גדול בין 2 שניות ו־5 שניות בכמות הפרטים שאוכל להוציא. לכן הכי הרבה השתמשתי עד כה 5 שניות ולרוב 2 שניות. זה גם מאוד מקל על הדרישות מהחצובה. אני צריך לחכות זמן מה לפעמים 20-30 שניות עד שהתמונה תתייצב, כי אחרי ההזזה בד"כ יש drift חזק שמתייצב תוך בערך 30 שניות. לכן אני לא מתאמץ להגיע לזמני חשיפה ארוכים יותר בגלל שהם מאוד מתקרבים למגבלת החצובה. כשאגיע לעשות EAA במשואה או חולדה אז הסיפור יהיה שונה.

טוב עדכונים, ניסיתי כמה דברים: הוספתי flats + dark flats ניסיתי לעבוד עם gain גבוהה התחלתי לעבוד עם מאריך כדי לתקן את ה־tils נתחיל ב־flats הוספתי אצלי בתוכנה בקלות יחסית. השיפור מאוד ניכר. נעלמו סימנים של האבקים ואכן הרקע נהיה הרבה יותר אחיד. מה שמאפשר למתוח את התמונה הרבה יותר בקלות תיקון ה־tilt (כוכבים משולשים) מסתבר שהבעיה העיקרית היא שהמצלמה לא נכנסה עד הסוף ואז בעצם היישור שלך הסתמך על טבעת האחיזה בלבד. ברגע שמתי מאריך (חלק מברלו בלי עדשה) אז המצלמה נכנסה ישר עד הסוף ואז היא מייושרת ע"י השפה של המאריך ומשטח של המצלמה. גם המאריך נכנס עד הסוף לתוך פוקוסר ומייושר טוב. עדיין יש חופש מסויים בפוקוסר ולפעמים בכוכבים בהירים ממש אפשר להיות שהם לא מעגלים מושלמים, עדיין המצב הרבה־הרבה יותר טוב. עבודה עם gain גבוהה קודם כל ה־gain הגבוהה ביותר שורף הכל. אפילו רקע. ניסיתי לעבוד עם 75% של ה־gain. בסופו של דבר ראיתי שזה ממש לא חד משמעי ש־gain גבוה עוזר. לעתית הוא מקלקל ע"י זה שמייצר רקע יותר מידי רועש או שורף יותר מידי כוכבים. הנה תוצאות מאתמול m42 עם gain=75% וזמן חשיפה 5 שניות (6 תמונות) עצרתי כי לא אהבתי - בהחלט רואים יותר טוב את הענן אבל כל המרכז שרוף. זה צבירים פתוחים (לא זוכר איזה פרמטרים) אבל רואים שהחדות השתפרה וגם הכוכבים עגולים לרוב m41 m46 ועכשיו הגלקסיות. ngc2403 סה"כ 88 תמונות של 5 שניות. דווקא gain=200 עבד הרבה יותר טוב. עם gain=450 (שזה 75% יש יותר מידי רעש ברגע) מה שיפה שמתחילים לראות את זרועות הרקע מאוד אחיד (בגלל flats ואפשר לעשות מתיחה טובה) ובסוף m82 - יש עדיין רקע בהיר בגלל הבניין ליד אבל רואים טוב. צולם עם gain 450=75% u זמני חשיפה 2 שניות סה"כ 134 תמונות

כיוון שהוא לא היה על חצובה אלא על ידיים, פשוט הצמדתי למסך מחשב על רקע לבן עליו

טוב, כמה עדכונים. לגבי flats + dark_flats הוספתי אותם ב־offline (אני יודע שזה לא אותו דבר אחרי פירוק והרכבה, אבל בכל זאת ניסיתי. ההבדל משמעותי ביותר! למעלה זה זה m82 ו־ngc2403 אחרי התיקון ולמטה בלי תיקון של flats. זה בהחלט שיפר. כשמנסים להגיע לאובייקטים עמומים אני מתחיל להבין כמה זה נהיה משמעותי חייב להגיד שכאשר צילמתי את m82, זה היה ממש קרוב לגבול המרפסת ויכול להיות שאי אחידות/גרדיאנט בשדה נובעת מהאורות שבאים מהקירות

עוד שאלה... מה יכול להגרום לכוכבים להיות בצורת טיפות, זה במרכז FOV וגם חייב לציין שעם סביבוני 105 לא היו לי בעיות כאלה, הכוכבים היו עגולים אני חושד ב־tilt של סנסור... האם זה הגיוני?

אין vignette וסה"כ השדה די שטוח (אם אני לא שם רדיוסר) מדובר בסנסור קטן יחסית. כן רואים סימנים של אבקים לפעמים או קצת חוסר אחידות רקע. אז נראה לי אפשר וכדאי לנסות flats