Mve: Fountain_p11 مجموعة البيانات

لذا فإن الطريقة التي وصفتها بها تبدو جيدة - يمكنك إنشاء مشهد بالبرنامج النصي وتشغيل featurerecon . ومع ذلك ، فإن النص مخصص لميدلبري وليس لمجموعات بيانات Strecha. قد تضطر إلى تكييفها قليلاً.

• هل يمكنك إلقاء نظرة على ملف meta.ini بنفسك والمقارنة مع المعلمات من Strecha؟
• قبل تشغيل featurerecon ، هل يمكنك فحص المشهد باستخدام UMVE؟

حسنًا ، لأنه في Strecha fountain_p11 يحتوي على 11 صورة فقط ، قمت يدويًا بإنشاء fountain_par.txt لذا أعتقد أن البرنامج النصي Middelbury سيعمل بشكل جيد و meta.ini. هل صحيح أن _umve_ يعمل بشكل جيد أيضًا إذا تم تشغيله قبل _featurerecon_ فإنه يعرض كاميرات ذات دوران غريب عندما أقوم بتشغيل _featurerecon_ أحصل على 1000 نقطة فقط وشيء ما يشكل مخروطًا مثل الشكل. تحقق من الصورة أدناه

أيضًا إذا لاحظت أن Strecha قدم في مجموعة بياناته ملفين للكاميرا التي تحتوي على K و R و T. وملف آخر يسمى P والذي يحتوي على مصفوفة الإسقاط إذا أخذت I compute p = K * [R | t] أحصل على مصفوفة مشابهة لـ واحد في ملف P مع عمود واحد مختلفة تحقق من ضربة الصورة.

مجموعة البيانات هذه تزعجني كيف استخدمها الناس للتحقق من صحة الأشياء

من الصعب أن ترى ما هو الخطأ من الصورة. إذا حصلت على ميزات في شكل مخروطي ، فمن المحتمل أن تكون بعض معلمات الكاميرا خاطئة. قد تكون الكاميرات مقلوبة؟ أنت الرياضيات في لقطة الشاشة الثانية تبدو خاطئة بالنسبة لي. ألا يجب أن تحتوي RT على جميع الأصفار في الصف الأخير ، مع وجود واحد في الزاوية اليمنى السفلية؟

الرياضيات صحيحة وفقًا لطراز الكاميرا ذات الثقب R هي 3x3 t هي 3x1 و k هي 3x3 لماذا يجب أن أقوم بزيادة RT صفًا. أعني أنه يمكنك زيادة الإسقاط p إذا كنت تريد إجراء بعض التحول المتجانس.
كما أنني تحققت للتو على الشبكة اكتشفت أن Strecha يحسب إسقاطه P على النحو التالي: p = k * [R ^ T | -R ^ T t]
يعني "^ T" تبديل لكني لا أفهم هذا.
العودة إلى المشكلة:
fountain_par.txt هنا هو الملف الذي يمكنك تجربته تشغيل البرنامج النصي والميزات عليه بنفسك إذا كان لديك الوقت. أعتقد أن معلمات الكاميرا الواردة في مجموعة البيانات خاطئة أو أنها غير متوافقة مع MVE و SMVS

ربما يكون لدى شخص ما في الفريق الوقت للنظر في هذا ، لا أفعل. nmoehrle ،flanggut؟

شكرا لك. اكتشفت أيضًا أن جميع مجموعات بيانات Strecha حتى الجديدة منها هنا: https://cvlab.epfl.ch/data/strechamvs لا تعمل أيضًا ، لذا فإن هذا الدور هو افتراض أن معلمة الكاميرا خاطئة ويقودني إلى الاعتقاد بأن الأرض معلمة كاميرا الحقيقة بطريقة ما غير متوافقة مع MVE و SMVS

الرجاء نشر أحد ملفاتك meta.ini هنا.

عندما ألقي نظرة على لقطة شاشة UMVE أستطيع أن أرى أن التدويرات غير صحيحة ، من المفترض أن تشكل المشاهدات قوسًا يتجه نحو المركز. عندما جربت strecha ، كان لدي نصوص التحويل الخاصة بي ، وبما أنها مكتوبة بلغة python ، لم أحاول دمجها في MVE. هل يمكنك أن تريني البرنامج النصي الذي استخدمته لتحويل معلمات الكاميرا ، أو إعطاء رابط؟

أفضل تخميني هو أنك لم تقم بتحويل موضع الكاميرا (c المخزنة في ملفات الكاميرا strecha) إلى الترجمة (t = -R * c). علاوة على ذلك ، أعتقد أنه كان هناك بعض الغرابة في ملفات الكاميرا strecha ، مصفوفة الكاميرا في الصف الرئيسي ومصفوفة الدوران في العمود الرئيسي ، أو إذا صح التعبير ، يتم تخزين مصفوفة الدوران المنقولة (R ^ t).

simonfuhrmann هنا ملف التعريف
meta.txt
nmoehrle جيدًا لقد استخدمت هذا: https://github.com/simonfuhrmann/mve/wiki/Middlebury-Datasets للحصول على معلمات الكاميرا.
ونعم لم أفعل (t = -R * c) لذلك اعتقدت أن Strecha تمنحك متجه الترجمة t ما أربكني هو أن Stesha في الملف التمهيدي تقول p = k * [R ^ T | -R ^ T t ] إذا استبدل t بـ c -_-. سأحاول استخدام هذه المعلومات ومعرفة ما تقدمه

لا يمكن لهذا البرنامج النصي تحليل ملفات .camera الخاصة بمعيار strecha ، فهو يقرأ فقط تنسيق معلمات كاميرا midbury ، وهو سطر واحد يبدو كالتالي:
"imgname.png k11 k12 k13 k21 k22 k23 k31 k32 k33 r11 r12 r13 r21 r22 r23 r31 r32 r33 t1 t2 t3" .

تحتوي ملفات .camera على بنية مختلفة تمامًا:

| الخط | المحتوى |
| ------ | - |
| 1-3 | مصفوفة ك |
| 4 | غير معروف |
| 5-7 | R ^ t |
| 8 | ج |
| 9 | ارتفاع العرض |

nmoehrle نعم نعم ، أنا على علم بأنني قمت يدويًا بإنشاء ملف fountain_par.txt من. camera لـ 11 صورة (كسول لكتابة المحلل اللغوي الخاص بي) الشيء الوحيد الذي لم أفكر فيه هو (t = -R * c) i تستخدم ج المعطاة في. camera as t. سأقوم بإصلاح هذا لاحقًا ونشر النتائج

nmoehrle حسنًا ، أعتقد أن المشكلة تم حلها شكرًا لك

نعم هذه هي الطريقة التي أتذكرها :-)