यह बेंचमार्क असल में क्या साबित करता है?
यह कि किसी नामित स्कैनर की कोई नामित फ़ाइल, अपने असली आकार में, रिलीज़ बिल्ड में खुलती है और स्क्रीन पर पिक्सेल दिखाती है। न इससे ज़्यादा, न इससे कम। फ़ॉर्मैट-सपोर्ट सूची किसी क्षमता का दावा करती है; यह उसे मापता है। अगर कोई वेंडर लेआउट डिकोडर को मात दे देता है, तो वह फ़ाइल विफलता तालिका में उसी एरर टेक्स्ट के साथ दिखती है जो उपयोगकर्ता देखेगा, न कि गायब पंक्ति के रूप में।
यह एक वेंडर परीक्षण है — सॉफ़्टवेयर हमने लिखा और परीक्षण भी हमने ही चलाया। फिर भी इसे पढ़ना सार्थक है, क्योंकि आप इसे जाँच सकते हैं: कॉर्पस सार्वजनिक हैं, रनर हमारी डेस्कटॉप रिपॉज़िटरी में है, और हर फ़ाइल के रॉ परिणाम इसी पेज पर हैं।
फ़ाइलों का परीक्षण कैसे किया गया
हर फ़ाइल एक डिस्पोज़ेबल चाइल्ड प्रोसेस को दी जाती है, जो वही लोडर बनाता है जो ऐप्लिकेशन बनाता है, इमेज के आयाम पढ़ता है, एक प्लेन डिकोड करता है, और उसे उसी Qt रेंडर पाथ से कन्वर्ट करता है जिसका व्यूअर उपयोग करता है। कोई खराब फ़ाइल अगर किसी नेटिव कोडेक को बंद कर दे, तो केवल वही चाइल्ड प्रोसेस खत्म होता है; सुपरवाइज़र दर्ज करता है कि उस समय कौन-सी फ़ाइल चल रही थी और आगे बढ़ जाता है। इसी डिज़ाइन की वजह से कई गीगाबाइट के वेंडर स्कैन पर बेंचमार्क पूरा हो पाता है, और इसी वजह से यह तालिका "क्रैश" श्रेणी को ईमानदारी से शून्य बता सकती है।
- रनर:
slidescope-desktop/scripts/publish_format_benchmark.py — SlideScope डेस्कटॉप रिपॉज़िटरी में एक कमांड, जो तीनों पास चलाती है और ठीक वही JSON लिखती है जिसे यह पेज दिखाता है: python scripts/publish_format_benchmark.py --dataset <corpus> --output format-benchmark.json
- कॉर्पस: Open Microscopy Environment का सार्वजनिक संदर्भ कॉर्पस, OpenSlide की प्रकाशित टेस्ट स्लाइड,
czitools और nd2 लाइब्रेरी का टेस्ट डेटा, और वे वेंडर सैंपल जिनका sha256 हमने प्रकाशक से मिलाकर सत्यापित किया।
- दायरा: होल स्लाइड और वेंडर माइक्रोस्कोपी फ़ॉर्मैट। वेंडरों के थोक डंप से आई अलग-अलग सिंगल-प्लेन TIFF फ़ाइलें शामिल नहीं हैं — वे ऐसा कुछ नहीं बतातीं जो एक पिरामिडल WSI TIFF बेहतर ढंग से न बताता हो।
- हर फ़ाइल के लिए दर्ज: पहचाना गया फ़ॉर्मैट, लोडर, डिकोड किए गए T/Z/C/Y/X आयाम, पिक्सेल प्रकार, रेंडर किया गया आकार, और विफलता होने पर एक्सेप्शन का प्रकार और उपयोगकर्ता को दिखने वाला संदेश।
होल स्लाइड इमेज फ़ॉर्मैट
ये स्कैनर फ़ॉर्मैट हैं — वे फ़ाइलें जो Aperio, Hamamatsu, 3DHISTECH, Leica, Ventana, Akoya या Agilent उपकरण से आती हैं और अक्सर कई गीगाबाइट की होती हैं।
माइक्रोस्कोपी और मेडिकल इमेजिंग फ़ॉर्मैट
बहु-आयामी अधिग्रहण फ़ॉर्मैट, जहाँ दिलचस्प सवाल फ़ाइल का आकार नहीं, बल्कि यह है कि कितने चैनल, Z प्लेन और टाइमपॉइंट स्क्रीन तक सही-सलामत पहुँचते हैं।
हर वह फ़ाइल जो नहीं खुली, और उसका कारण
792 में से 25 फ़ाइलें नहीं खुलीं, और यह एक नहीं बल्कि दो अलग कहानियाँ हैं। 9 असली सीमाएँ हैं: ऐसी वास्तविक इमेज जिसे हम फ़िलहाल नहीं पढ़ सकते। बाकी 16 ऐसी फ़ाइलें हैं जिनमें कोई इमेज है ही नहीं, और वहाँ मना करना ही सही जवाब है। दोनों को एक साथ गिनना हमें बेहतर दिखाता — इस रन में विफलताओं की ईमानदार संख्या 9 है, 25 नहीं।
असली सीमाएँ: 9 फ़ाइलें जिन्हें हम नहीं पढ़ सकते
इनमें से हर फ़ाइल बिल्कुल सही-सलामत है — चेकसम प्रकाशक से मेल खाते हैं — इसलिए ये डिकोडर और वेंडर-लेआउट की सीमाएँ हैं, खराब सैंपल नहीं। ये रिग्रेशन कवरेज के रूप में हमेशा कॉर्पस में रहती हैं, और इसी तरह हमें पता चलता है कि जिस दिन इनमें से कोई काम करने लगे।
पैटर्न वेंडर लेआउट का है, मोडैलिटी का नहीं। फ़्लोरेसेंस NDPI और फ़्लोरेसेंस MIRAX दोनों सामान्य रूप से खुलती हैं; बैकएंड कुछ खास संरचनात्मक रूपों को ही अस्वीकार करते हैं — ऐसी SCN जिसमें कोई पहचानने योग्य मुख्य इमेज नहीं, ऐसी BIF जिसमें अनपेक्षित direction एट्रिब्यूट है, HDF5 से पहले का "Imaris Classic" कंटेनर। हर संदेश फ़ाइल को करप्ट कहने के बजाय कारण बताता है, क्योंकि इनमें से हर मामले में फ़ाइल ठीक है और कमी हमारी है।
विफलताएँ नहीं: 16 ऑब्जेक्ट जिनमें कोई इमेज नहीं
DICOM जितना इमेज फ़ॉर्मैट है, उतना ही डॉक्यूमेंट फ़ॉर्मैट भी। DICOMDIR किसी डिस्क का इंडेक्स होता है; प्रेज़ेंटेशन स्टेट यह दर्ज करता है कि किसी ने कभी किसी स्टडी की विंडोइंग कैसे की थी; अन्य ऑब्जेक्ट में रिपोर्ट या माप होते हैं। इनमें से किसी में पिक्सेल नहीं होते। इन्हें खोलने वाले व्यूअर के पास दिखाने को कुछ नहीं होगा, इसलिए SlideScope कारण बताकर मना कर देता है — यह सही व्यवहार है, और इसे अलग गिना गया है ताकि यह किसी भी कॉलम को बढ़ा-चढ़ाकर न दिखाए।
पूरे नामों के साथ, ताकि किसी श्रेणी के पीछे कुछ छिपा न रहे: DICOMDIR, PS_0026, PS_0108, PS_0128, PS_0154, PS_0181, XX_0027, XX_0109, XX_0155, XX_0182, XX_0183।
जहाँ SlideScope ने फ़ाइल खोली और गलत चीज़ दिखाई
यह सबसे अहम विफलता है, और फ़ॉर्मैट तालिकाएँ इसे कभी स्वीकार नहीं करतीं, इसलिए यह रहा हमारा मामला।
एक मल्टीप्लेक्स Akoya .qptiff स्कैन — Vectra की सात-रंगों वाली संदर्भ फ़ाइल — बिना किसी एरर के खुल गया। फ़ाइल में 33 पेजों में 34,560 × 24,960 पर पाँच फ़ुल-रिज़ॉल्यूशन सिंगल-चैनल फ़्लोरेसेंस पेज (DAPI, FITC, CY3, Texas Red, CY5) हैं, जिसकी पुष्टि tifffile से स्वतंत्र रूप से की गई। SlideScope हर .qptiff को अपने OpenSlide बैकएंड पर भेजता था, जो एक ब्राइटफ़ील्ड रीडर है, इसलिए उसने एक ही चैनल बताया और एक RGB स्लाइस लौटाई। फ़्लोरेसेंस चैनल तक पहुँचा नहीं जा सकता था और चैनल कंट्रोल के पास देने को कुछ नहीं था।
आपको कोई चेतावनी नहीं मिली। उसी कॉर्पस के ब्राइटफ़ील्ड H&E QPTIFF स्कैन पूरी तरह ठीक खुलते हैं, और ठीक इसी वजह से यह किसी की नज़र में नहीं आया।
SlideScope 1.8.48 (18 सितंबर 2026) में ठीक किया गया: बैकएंड अब एक्सटेंशन के आधार पर नहीं, हर फ़ाइल के आधार पर चुना जाता है। मल्टीप्लेक्स स्कैन ऐसे रीडर पर जाता है जो पाँचों चैनल लौटाता है; ब्राइटफ़ील्ड QPTIFF, OpenSlide और उसकी फ़ुल-रिज़ॉल्यूशन टाइलिंग पर ही रहता है। इसका समझौता छिपाया नहीं, बताया गया है: मल्टीप्लेक्स QPTIFF कम रिज़ॉल्यूशन पर दिखता है, और फ़ाइल विवरण पैनल यह बताता है। इस पेज का रन पहले से इस सुधार को दर्शाता है — QPTIFF की पंक्ति में दोनों लोडर और पाँच चैनल दर्ज हैं।
फ़ाइल का खुलना इस रन से साबित होता है। पिक्सेल का सही होना एक अलग सवाल है, और उसका परीक्षण हम अलग से करते हैं: दूसरा स्वीप उन्हीं प्लेन को मूल लाइब्रेरी से डिकोड करता है और उनकी तुलना लोडर के लौटाए परिणाम से करता है। QPTIFF का मामला इसी तरह पकड़ा गया।
SlideScope क्या खोलने से मना करता है
कोई सामान्य फ़ॉलबैक रीडर नहीं है, और कोई व्यूअर उस फ़ाइल को कैसे संभालता है जिसके लिए वह कभी बना ही नहीं, यह उतना ही मायने रखता है जितना कि वे फ़ाइलें जिनके लिए वह बना है। हमने संदर्भ कॉर्पस में हर असमर्थित एक्सटेंशन की सबसे छोटी असली फ़ाइल ली — कुल 93 — और हर एक को रिलीज़ हुई लोडर फ़ैक्टरी से गुज़ारा।
93 में से 93 को स्पष्ट संदेश के साथ अस्वीकार किया गया। कोई क्रैश नहीं हुआ। कोई भी आधा-अधूरा खुलकर ऐसा कुछ नहीं बना जो इमेज जैसा दिखे पर हो नहीं। सूची में वे फ़ॉर्मैट शामिल हैं जिन्हें लोग खोलने की कोशिश कर सकते हैं — .jpg, .lof, .nii, .oib, .oir, .png, .psd, .raw, .vsi — इस रन के समय इनमें .png और .jpg भी थे, जिन्हें अनुमान लगाने के बजाय संदेश के साथ अस्वीकार किया गया।
इस रन के बाद से: SlideScope 1.10.0 (16 अक्टूबर 2026) 18 और फ़ॉर्मैट खोलता है, जिनमें यहाँ अस्वीकार किए गए कई फ़ॉर्मैट शामिल हैं: Olympus .vsi, .oib और .oir, Leica .lof और .xlef, Hamamatsu .ndpis, और PNG, JPEG व अन्य रोज़मर्रा की इमेज। इस पेज की संख्याएँ 18 सितंबर के रन की हैं, जैसा मापा गया; 1.10.0 में जोड़े गए फ़ॉर्मैट इसका हिस्सा नहीं थे। SlideScope 1.20.0 पाँच और फ़ॉर्मैट खोलता है जिनका इस रन में परीक्षण नहीं हुआ: Philips .isyntax, KFBio .kfb, ICS/IDS, Gatan .dm3 और .dm4, और Olympus .sis। मौजूदा सूची के लिए फ़ाइल कम्पैटिबिलिटी संदर्भ देखें।
यह बेंचमार्क आपको क्या नहीं बताता
- दो फ़ॉर्मैट का असली फ़ाइलों पर कोई कवरेज नहीं है। कोई सार्वजनिक
.vmu या .svslide सैंपल मौजूद नहीं है — OpenSlide इनमें से कोई प्रकाशित नहीं करता — इसलिए इन लोडर का परीक्षण केवल सिंथेटिक एज केस से होता है। हम इनके लिए परीक्षित सपोर्ट का दावा नहीं कर रहे।
- यह स्पीड बेंचमार्क नहीं है। पहला पिक्सेल दिखने का समय आपकी डिस्क पर निर्भर करता है, और ये रन लोकल थे।
- ऊपर बताए गए पिक्सेल-तुलना स्वीप के अलावा यह सटीकता का ऑडिट नहीं है, और यह क्लिनिकल वैलिडेशन भी नहीं है। SlideScope रिसर्च, शिक्षा और समीक्षा के लिए है — निदान के लिए नहीं।
- यह एक स्नैपशॉट है। तारीख 2026-09-18, उस दिन की मौजूदा रिलीज़ पर। डिकोडर अपग्रेड इन संख्याओं को दोनों दिशाओं में बदल सकते हैं।
इस बेंचमार्क के बारे में प्रश्न
SlideScope असल में कौन-से माइक्रोस्कोपी और होल स्लाइड फ़ॉर्मैट खोलता है?
अठारह फ़ाइल एक्सटेंशन: .svs, .ndpi, .mrxs, .scn, .bif, .vms, .vmu, .svslide, .qptiff, .avs, .czi, .nd2, .lif, .ims, .dcm, .dicom, .tif और .tiff। कोई सामान्य फ़ॉलबैक रीडर नहीं है — इस सूची से बाहर की किसी भी फ़ाइल को खराब तरीके से खोलने के बजाय साफ़ संदेश के साथ अस्वीकार किया जाता है।
क्या यह बेंचमार्क स्वतंत्र है?
नहीं। SlideScope इसे SlideScope के बारे में प्रकाशित करता है, इसलिए इसे थर्ड-पार्टी ऑडिट नहीं, वेंडर परीक्षण मानें। स्वतंत्रता के बदले हम जाँचने की सुविधा दे सकते हैं: कॉर्पस सार्वजनिक हैं, रनर हमारी खुली स्क्रिप्ट डायरेक्टरी में है, रॉ परिणाम फ़ाइल का लिंक इस पेज पर है, और विफलताएँ उतने ही विस्तार से सूचीबद्ध हैं जितनी सफलताएँ।
कुछ फ़ाइलें विफल क्यों होती हैं?
लगभग हमेशा इसलिए कि किसी वेंडर ने ऐसा लेआउट लिखा जिसे मूल ओपन-सोर्स बैकएंड नहीं पढ़ सकता — उदाहरण के लिए, फ़्लोरेसेंस SCN पर OpenSlide का "Can't find main image" बताना। ये अपस्ट्रीम सीमाएँ हैं, जिन्हें हम छिपाने के बजाय सामने रखते हैं। विफल फ़ाइलें बिल्कुल सही-सलामत हैं: उनके चेकसम प्रकाशक के चेकसम से मेल खाते हैं।
क्या फ़ाइल खुलने का मतलब है कि इमेज सही है?
अपने आप में नहीं, इसीलिए हम दोनों का परीक्षण करते हैं। फ़ाइल का खुलना इस रन से साबित होता है; पिक्सेल का सही होना अलग से sweep_format_reference.py से साबित होता है, जो उन्हीं प्लेन को मूल लाइब्रेरी से डिकोड करता है और उनकी तुलना SlideScope के रेंडर से करता है। एक ज्ञात मामला — मल्टीप्लेक्स Akoya QPTIFF — बिना एरर के खुला और फिर भी गलत चीज़ दिखाता रहा, जब तक SlideScope 1.8.48 ने इसे ठीक नहीं किया। यह इस पेज पर दर्ज है।
क्या मैं इसे दोहरा सकता हूँ?
हाँ। Open Microscopy Environment संदर्भ कॉर्पस सार्वजनिक डाउनलोड है, वेंडर सैंपल OpenSlide और फ़ॉर्मैट लाइब्रेरी के अपने टेस्ट डेटा से आते हैं, और रनर SlideScope डेस्कटॉप रिपॉज़िटरी में मौजूद है। इस पेज की हर तालिका के पीछे का रॉ JSON ऊपर लिंक किया गया है।
क्या SlideScope क्लिनिकल निदान के लिए स्वीकृत है?
नहीं। SlideScope रिसर्च, शिक्षा और समीक्षा के लिए है। यह कोई डायग्नोस्टिक डिवाइस नहीं है और इसका उपयोग प्राथमिक निदान के लिए नहीं किया जाना चाहिए।
असली परीक्षण वही है जो आप करते हैं
हमारा कॉर्पस आपकी स्लाइड की दराज़ नहीं है। SlideScope इंस्टॉल करें, वे फ़ाइलें खोलें जो सच में आपको परेशान करती हैं, और अगर उनमें से कोई विफल हो, तो उसे हमें भेजें — इस पेज की विफलताएँ यहाँ इसलिए पहुँचीं क्योंकि किसी ने ऐसा किया।
SlideScope डाउनलोड करें