Execution Engine चेंजलॉग

Workflows Execution Engine में संस्करण-दर-संस्करण परिवर्तन।

नीचे आप Execution Engine के लिए परिवर्तन सूची देख सकते हैं।

अप्रकाशित

क्या बदला

यहाँ उपयोगकर्ताओं के लिए दिखने वाले संकलन या निष्पादन व्यवहार परिवर्तनों को जोड़ें। रिलीज़ करते समय मेंटेनर इस शीर्षक को Execution Engine और inference संस्करणों से बदल देते हैं।

• स्थानीय workflow मॉडल लोड करते समय उत्पन्न model-access विफलताएँ अब सामान्य HTTP 500 त्रुटियों के रूप में दिखने के बजाय HTTP 402, 403, और 423 स्थितियों को बरकरार रखती हैं।

---

Execution Engine v1.15.0 | inference 1.3.9

• दूरस्थ HTTP 501 त्रुटियाँ अपनी स्थिति को आंतरिक URLs उजागर किए बिना बरकरार रखती हैं — जब दूरस्थ रूप से निष्पादित किसी Workflow चरण से HTTP 501 लौटता है, तो Execution Engine अब आंतरिक producer URL वाले सामान्य HTTP 500 के बजाय समान स्थिति और API संदेश के साथ client-caused Workflow त्रुटि दिखाता है।

Execution Engine v1.14.0 | inference 1.3.8

क्या बदला

• आउटपुट serialization उन kinds को स्वीकार करती है जो strings के रूप में घोषित हैं — जब किसी output kind को एक साधारण string के रूप में घोषित किया गया था (जैसे "string") बजाय Kind object के, output serialization TypeError: unhashable type: 'list' के साथ क्रैश हो जाती थी, जिससे पूरी Workflow run के लिए HTTP 500 दिखता था। अब ऐसे kinds को नाम से हल किया जाता है, इसलिए मिलान करने वाला serializer लागू होता है (या जब उस kind के लिए कोई serializer पंजीकृत नहीं होता, तो raw value को वैसे ही पास कर दिया जाता है)।

• Blocks अपनी आश्रित संसाधनों की घोषणा कर सकते हैं — WorkflowBlockManifest एक instance method प्राप्त करता है discover_dependent_resources() -> Optional[List[DependentResource]] जो किसी parsed step को उन बाहरी संसाधनों की घोषणा करने देता है जिनका उसका निष्पादन उपयोग करेगा, ताकि caller (platform, preloading और auth pre-flight tooling) उन्हें workflow definition से स्थिर रूप से सूचीबद्ध कर सकें। envelope को Execution Engine नियंत्रित करता है: resource types roboflow_platform_model, roboflow_platform_project और third_party_model, प्रत्येक के साथ typed, serializable (pydantic) metadata entity। Platform-model प्रविष्टियाँ उपयोग की प्रकृति भी बताती हैं: required_action (access — मॉडल entity को केवल platform पर पहुँच योग्य होना चाहिए, बनाम execution — मॉडल निष्पादित किया जाता है) और, execution के लिए, execution_location (local / remote / environment_defined जब locality रनटाइम पर WORKFLOWS_STEP_EXECUTION_MODE द्वारा तय की जाती है)। जिन blocks की अपनी locality override होती है, वे इसे वहीं निर्धारित करते हैं — SAM3 image blocks SAM3_EXEC_MODE=remote होने पर कुछ भी घोषित नहीं करते (proxy execution configured model id को अनदेखा करता है और server-side पर एक fixed SAM3 चलाता है) और environment_defined अन्यथा। None लौटाना (default) का अर्थ है कि block अपनी dependencies घोषित नहीं करता — यह []से अलग है, जो यह घोषित करता है कि किसी बाहरी संसाधन की आवश्यकता नहीं है। Workflow selectors वाले field values ($inputs.<name> / $steps.<name>.<property>) ज्यों के त्यों रिपोर्ट किए जाते हैं; प्रत्येक metadata entity requires_runtime_resolution() प्रकट करती है ताकि ऐसे संदर्भों को concrete identifiers से अलग पहचाना जा सके। जिन declarations का अंतिम id field value से synthesized होता है (family prefixes जैसे clip/<version>, catalog lookups) वे अतिरिक्त रूप से एक non-serializable model_id_resolver callable संलग्न करते हैं जो substituted input value को निष्पादित id में बदलता है — serialization, JSON schema और equality से बाहर रखा गया। मॉडल, Roboflow projects या third-party hosted models का संदर्भ देने वाले सभी core blocks इस method को लागू करते हैं, और हर implementation उस model identifier को प्रतिबिंबित करती है जिसे run() वास्तव में लोड करता है (version fields से synthesized ids सहित, जैसे clip/<version>)। Project declarations अपने सक्षम करने वाले controls का पालन करती हैं, जो static manifest values से तय होते हैं: Roboflow model blocks active-learning target को हटा देते हैं जब disable_active_learning शाब्दिक रूप से True होता है (default), और dataset-upload blocks कुछ भी घोषित नहीं करते जब disable_sink शाब्दिक रूप से True होता है; selector-fed controls conservative may-need declaration बनाए रखते हैं। introspection active_learning_target_dataset property पर रुकती है — active learning सक्षम होने पर, बिना explicit target के, model id से कोई project derived नहीं किया जाता। जो blocks अपने model weights को model manager के बाहर लोड करते हैं (SAM2/SAM3 video trackers, जो AutoModel.from_pretrained का उपयोग करते हैं), वे फिलहाल जानबूझकर इस method को लागू नहीं करते — उनकी dependencies undeclared रहती हैं (None).

• Dynamic (custom python) blocks अज्ञात dependencies रिपोर्ट करते हैं — dynamic blocks के लिए synthesized manifests None से discover_dependent_resources() लौटाते हैं: python body स्थैतिक विश्लेषण के लिए opaque है, इसलिए "unknown" ही ईमानदार उत्तर है।

• Engine init पर घोषित Roboflow models की opt-in pre-loading — ExecutionEngine.init(...) एक नया वैकल्पिक parameter स्वीकार करता है dependencies_pre_init (default None): pre-load करने के लिए dependent-resource type names की सूची, जिसमें roboflow_platform_model अब तक केवल समर्थित मान है। सक्षम होने पर, engine सभी compiled steps की घोषित dependencies निकालता है (deduce_blocks_dependencies compiler utils में) और execution के लिए घोषित प्रत्येक concrete Roboflow platform model को model manager में पंजीकृत करता है (दोनों लिए गए हैं init_parameters से, जैसे API key भी) दौरान init() — किसी भी run से पहले, ताकि first-inference latency पूर्वानुमेय रहे। जो declarations $inputs.<name> को संदर्भित करती हैं, उन्हें init पर लोड नहीं किया जा सकता; पहले पहली run() केवल — runtime-input validation के बाद, ताकि अवैध request न तो एकमात्र प्रयास को consume करे न downloads trigger करे — engine उन्हें दिए गए runtime parameters (input defaults लागू करके) के विरुद्ध resolve करता है, attached होने पर declaration का model_id_resolver लागू करता है (ताकि उदाहरण के लिए substituted CLIP version pre-load हो clip/<version>वही id जिसे execution उपयोग करता है), और उन models को पंजीकृत करता है जिनके identifiers concrete हो गए। एक resolver जो None लौटाता है, यह घोषित करता है कि substituted value statically unresolvable है (जैसे Qwen का fine-tuned sentinel label, जिसका अंतिम id किसी अन्य input पर निर्भर करता है) — dependency को छोड़ा जाता है और execution समय पर resolve होता है; ऐसा submitted input value जिसे resolver संभाल नहीं सकता (जैसे कोई unknown catalog label) उत्पन्न करता है RuntimeInputError। Registration हर block के वास्तविक loader को प्रतिबिंबित करती है: declarations में non-serializable model_registration_kwargs हो सकते हैं (जैसे endpoint_type=CORE_MODEL CLIP / OCR / SAM2 / YOLO-World-style core models के लिए, जो load_core_model() से मेल खाते हैं)। हर pre-loading pass के बाद engine जाँचता है कि पंजीकृत मॉडल अभी भी model manager में मौजूद हैं और जब size/memory-bounded manager ने उनमें से कुछ को evict कर दिया हो तो warning लॉग करता है (वे execution समय पर lazily पुनः लोड होते हैं)। Pre-loading effective step execution mode का पालन करता है (explicit step_execution_mode init parameter, या WORKFLOWS_STEP_EXECUTION_MODE default): environment_defined declarations केवल तब pre-load होती हैं जब steps स्थानीय रूप से execute होते हैं, local declarations हमेशा होती हैं, और access-only declarations (कोई weights नहीं खींचे जाते), remote execution और $steps.…-fed identifiers कभी pre-load नहीं होते। InferencePipeline.init_with_workflow(...) इसे opt-in workflows_dependencies_pre_init parameter के रूप में प्रस्तुत करता है (default None — कोई pre-loading नहीं) — वीडियो processing को पूर्वानुमेय startup से सबसे अधिक लाभ मिलता है।

Execution Engine v1.13.0 | inference v1.3.7

क्या बदला

• Offline mode remote Workflow step execution को अस्वीकार करता है — जब OFFLINE_MODE सक्षम होता है, compiler StepExecutionMode.REMOTE को step initialization के दौरान अस्वीकार करता है (WorkflowEnvironmentConfigurationError) ताकि Workflows नेटवर्क access के बिना remote inference clients न खोल सकें। स्थानीय step execution warmed caches के विरुद्ध काम करती रहती है।

• उचित model access failure status codes - स्थानीय workflow models लोड करते समय उत्पन्न model-access विफलताएँ अब सामान्य HTTP 500 त्रुटियों के रूप में दिखने के बजाय HTTP 402, 403, और 423 स्थितियों को बरकरार रखती हैं।

Execution Engine v1.12.0 | inference v1.3.2

क्या बदला

भविष्य समाधान - कुछ steps अब Future objects उत्पन्न कर सकते हैं, जो output resolution को तब तक स्थगित करते हैं जब तक clients को outputs की आवश्यकता न हो। downstream blocks के लिए इन futures को step_input_assembler में resolve किया जा रहा है, जबकि output construction output_constructor में coordinate conversion के साथ किया जा रहा है।

Execution Engine v1.11.0 | inference v1.3.1

क्या बदला

• dict step selectors के लिए प्रति-केस execution branches - जब कोई flow-control block एक Dict[str, StepSelector] property के अंदर step selectors घोषित करता है ( List[StepSelector] के बजाय), compiler अब dictionary key के अनुसार एक अलग execution branch बनाता है। पहले एक ही property के हर selector के लिए एक ही branch साझा होती थी, इसलिए block अपने targets को स्वतंत्र रूप से route नहीं कर सकता था। Branch names में अब dictionary key शामिल होता है (जैसे Branch[$steps.switch -> cases[red]])। list properties में रखे गए selectors (जैसे next_steps) पहले जैसा shared-branch व्यवहार बनाए रखते हैं, इसलिए मौजूदा blocks प्रभावित नहीं होते। यही परिवर्तन नए roboflow_core/switch_case@v1 block (graph_constructor.establish_control_flow_edge).

• सुधार: दोहराए गए branch names वाले non-SIMD flow-control masks - एक non-SIMD flow-control step जिसने एक ही list property के माध्यम से एक से अधिक target चुने, ने Attempted to re-register maks for execution branch उत्पन्न किया। Branch-mask registration अब पंजीकरण से पहले branch names को deduplicate करती है, जिससे crash ठीक हो गया (उदाहरण के लिए ContinueIf के साथ कई next_steps; execution_data_manager.manager._register_control_flow_output_for_non_simd_step).

Execution Engine v1.10.1 | inference v1.2.12

क्या बदला

• नेस्टेड inner workflows में dynamic blocks - compiler अब dynamic_blocks_definitions को root workflow और हर nested inner_workflow child (depth-first) से एकत्र करता है, manifest.block_type के आधार पर deduplicate करता है (पहली occurrence मान्य रहती है; duplicate छोड़े जाने पर warning लॉग होती है), और merged list को compile_dynamic_blocks और inlining से पहले root definition पर ऊपर चढ़ा देता है। केवल nested workflow spec पर परिभाषित custom Python block types का उपयोग करने वाले child steps inlining के बाद सही ढंग से compile और run होते हैं।

Execution Engine v1.10.0 | inference v1.2.10

क्या बदला

• ऐसी dictionaries को पहचानने की क्षमता जो static values और selectors के मिश्रण वाली values रखती हैं - पिछले संस्करणों में केवल ऐसे dicts पहचाने जाते थे जो keys को selectors से map करते थे, जिससे runtime में कुछ blocks संदर्भित values से सही तरह नहीं जुड़े थे। यह परिवर्तन non-breaking है, लेकिन कुछ blocks को ठीक करता है जो पहले टूटे हुए थे।

Execution Engine v1.9.0 | inference v1.2.0

नई सुविधा: compile-time inlining के माध्यम से nested workflows

यह रिलीज़ roboflow_core/inner_workflow@v1 block जोड़ती है ताकि workflow किसी अन्य workflow definition को embed कर सके (inline JSON या workflow_workspace_id / workflow_id / वैकल्पिक workflow_version_id से resolved)। Child inputs को parent से parameter_bindings के साथ जोड़ा जाता है (child inputs[].name → parent selectors)। Compile समय पर engine inlines nested steps को parent graph में; execution वही path उपयोग करती है जो साधारण steps उपयोग करते हैं (कोई अलग nested runtime नहीं)।

क्या बदला

• Inner workflow block - नया flow-control block प्रकार roboflow_core/inner_workflow@v1 में पंजीकृत roboflow_core। Parent outputs, child workflow JsonField outputs को तब तक संदर्भित कर सकते हैं $steps.<inner_step_name>.<child_output_name> जब तक inlining selectors को फिर से न लिख दे।

• Compile pipeline - root definition को parse करने से पहले, compiler: (1) normalize करता है references को (default: Roboflow API + workflows_core.api_key, या custom workflows_core.inner_workflow_spec_resolver), (2) composition को validate करता है (acyclicity, max nesting depth, max inner-workflow count), (3) inlines सभी inner workflow steps को ordinary steps में बदल देता है, फिर parse, workflow specification validation, और execution graph construction जारी रखता है।

• सीमाएँ (environment variables) - WORKFLOWS_MAX_INNER_WORKFLOW_DEPTH (default 4) root से containment depth को सीमित करता है; WORKFLOWS_MAX_INNER_WORKFLOW_COUNT (default 32) nested definition में inner_workflow steps की कुल संख्या सीमित करता है।

• दस्तावेज़ीकरण - देखें Inner workflows (nested definitions) उपयोग, bindings, सीमाओं और एक उदाहरण के लिए।

Execution Engine v1.8.0 | inference v1.1.1

छोटे अपेक्षित प्रभाव के साथ additive change + एक breaking change, bug fix के कारण

यह रिलीज़ Execution Engine को विस्तारित करती है ताकि control flow द्वारा gated steps (जैसे एक ContinueIf block के बाद) तब भी चल सकें जब उनके पास कोई data-derived lineage न हो - अर्थात, जब उन्हें upstream steps से batch-oriented inputs नहीं मिलते। अब lineage और execution dimensionality control flow predecessor steps से प्राप्त की जा सकती है। मौजूदा workflows अप्रभावित हैं।

एक breaking change introduced हुई है उस bug fix के कारण जो Batch.remove_by_indices को nested batches के साथ प्रभावित करती है (नीचे देखें); प्रभाव न्यूनतम होने की अपेक्षा है।

क्या बदला

• Control flow lineage - compiler अब control flow steps (जैसे ContinueIf के बाद branches) से आने वाली lineage को ट्रैक करता है। control flow lineage support की एक नई अवधारणा तब उपयोग होती है जब किसी step के पास batch-oriented data inputs नहीं होते लेकिन उसके पहले control flow steps होते हैं: उस step के execution slices और batch structure उन control flow predecessors से लिए जाते हैं।

• compatibility check को ढीला किया गया - पहले, verify_compatibility_of_input_data_lineage_with_control_flow_lineage ने ControlFlowDefinitionError किसी भी ऐसे step के लिए उठाया जो control flow predecessors रखता था लेकिन data-derived lineage नहीं, इसलिए ऐसे steps compile नहीं हो सकते थे। वह check अब ढीला कर दिया गया है: जब किसी step के पास input data lineage नहीं होती, compatibility लागू नहीं की जाती और step की lineage इसके बजाय control flow predecessor step lineage से प्राप्त की जाती है। strict check अभी भी तब चलता है जब step के पास होती है data-derived lineage, ताकि control flow और data lineage संगत बने रहें।

• नए step patterns - जो steps केवल control flow द्वारा trigger होते हैं और batch data consume नहीं करते, वे अब सही ढंग से चलते हैं। उदाहरण के लिए, आप email notifications भेज सकते हैं (या अन्य side-effect steps चला सकते हैं) एक ContinueIf के बाद, बिना किसी data को इस तरह के parameters में wire किए जैसे message_parameters; step प्रत्येक control flow branch के लिए एक बार execute होगा, और lineage तथा dimensionality controlling step से ली जाएगी।

• Batch.remove_by_indices nested batches के साथ (व्यवहारिक सुधार) - जब Batch.remove_by_indices के माध्यम से indices हटाए जाते हैं, nested Batch elements अब उसी index set द्वारा recursively filter किए जाते हैं। परिणामस्वरूप, हटाए गए indices पर मौजूद entries (including None values) अब nested batches से भी सही ढंग से हट जाती हैं। पहले केवल top-level batch filter होती थी; nested batches अपरिवर्तित रहते थे।

  डिफ़ॉल्ट रूप से एक WorkflowBlock, accepts_empty_values() है False। जबकि यह bypass किया गया था, ऐसे inputs consume करने वाले blocks सीधे fail कर रहे थे, जैसे उदाहरण के लिए StitchDetectionsBatchBlock:

  def run(
      self,
      images: Batch[WorkflowImageData],
      images_predictions: Batch[Batch[sv.Detections]],
  ) -> BlockResult:
      result = []
      for image, image_predictions in zip(images, images_predictions):
          image_predictions = [deepcopy(p) for p in image_predictions if len(p)]
          for p in image_predictions:
              coords = p["parent_coordinates"][0]
      ...

  एकमात्र core block जिस पर यह परिवर्तन असर डालता है, वह है DimensionCollapseBlockV1 block, क्योंकि यह None values को फ़िल्टर किए बिना अलग-अलग inputs को batch में लपेट रहा था।

  class DimensionCollapseBlockV1(WorkflowBlock):
  
    @classmethod
    def get_manifest(cls) -> Type[WorkflowBlockManifest]:
        return BlockManifest
  
    def run(self, data: Batch[Any]) -> BlockResult:
        return {"output": [e for e in data]}

  इस block के output का उपयोग करते समय downstream applications या तो सीधे fail कर सकती थीं या None values को चुपचाप process कर सकती थीं, जब तक कि वे स्वयं उन values को filter न करें।

  ऊपर दिए गए को देखते हुए हमारा अनुमान है कि प्रभाव न्यूनतम होगा।

Execution Engine v1.7.0 | inference v0.59.0

workflows में step errors के संबंध में breaking change

में invalid HTTP response codes से संबंधित एक bug को ठीक करने के लिए inference-server Workflows execution requests को handle करते समय हमें Execution Engine में errors को handle करने के लिए जिम्मेदार default mechanism बदलना पड़ा। इस परिवर्तन के परिणामस्वरूप, Roboflow Hosted Platform पर और inference>=0.59.0 में, Roboflow platform से interact करने वाले Workflow blocks जो client misconfiguration (invalid Roboflow API key, invalid model ID, आदि) के कारण fail होते हैं, वे StepExecutionError (और server से HTTP 500 response) उठाने के बजाय ClientCausedStepExecutionError (और संबंधित HTTP response codes, जैसे 400, 401, 403, 404) उठाएँगे।

इस परिवर्तन से प्रभावित scenarios की सूची:

• Roboflow model का उपयोग करने वाला block अमान्य model ID परिभाषित करता है - अब ClientCausedStepExecutionError स्थिति code 400 के साथ उठाएगा

• Roboflow model का उपयोग करने वाला block अमान्य API key परिभाषित करता है - अब ClientCausedStepExecutionError स्थिति code 401 के साथ उठाएगा

• Roboflow model का उपयोग करने वाला block अमान्य API key परिभाषित करता है या resource access के लिए scope वाली वैध key गायब है - अब ClientCausedStepExecutionError स्थिति code 403 के साथ उठाएगा

• Roboflow model का उपयोग करने वाला block ऐसा model परिभाषित करता है जो मौजूद नहीं है - अब ClientCausedStepExecutionError स्थिति code 404 के साथ उठाएगा

वापस लाना विरासत त्रुटि-नियंत्रण

ज़रूरत पड़ने पर त्रुटि हैंडलर के विरासत व्यवहार को वापस लाना संभव है, जो संक्रमण अवधि में उपयोगी हो सकता है - इसके लिए केवल पर्यावरण चर सेट करना होता है DEFAULT_WORKFLOWS_STEP_ERROR_HANDLER=legacy.

Execution Engine v1.6.0 | inference v0.53.0

परिवर्तन पर ध्यान देने की आवश्यकता हो सकती है

यह रिलीज़ अपग्रेड और नई सुविधाएँ लेकर आती है कोई बदलाव आवश्यक नहीं मौजूदा वर्कफ़्लो में। नवीनतम Execution Engine क्षमताओं का लाभ लेने के लिए कुछ ब्लॉक्स को अपग्रेड करने की आवश्यकता हो सकती है।

Execution Engine के पिछले संस्करणों में कुछ प्रकार के ब्लॉक्स के साथ इंटरैक्ट करते समय महत्वपूर्ण सीमाएँ थीं - विशेष रूप से वे जो Single Instruction, Multiple Data (SIMD) मोड में काम करते हैं। ये ब्लॉक्स एक साथ इनपुट्स के बैचों को प्रोसेस करने, उसी ऑपरेशन को प्रत्येक तत्व पर लागू करने, और पूरे बैच के लिए परिणाम लौटाने के लिए बनाए गए हैं।

उदाहरण के लिए, run(...) ऐसे किसी ब्लॉक की मेथड इस तरह दिख सकती है:

def run(self, image: Batch[WorkflowImageData], confidence: float):
    pass

मैनिफ़ेस्ट में, image फ़ील्ड को बैच स्वीकार करने वाला घोषित किया जाता है।

समस्या तब उत्पन्न हुई जब इनपुट इमेज ऐसे ब्लॉक से आई जो बैचों पर काम नहीं करता था। ऐसे मामलों में, Execution Engine व्यक्तिगत इमेजों से बैच बनाने में असमर्थ था, जिसके परिणामस्वरूप अक्सर निराशाजनक कंपाइलेशन त्रुटियाँ आती थीं, जैसे:

स्टेप `$steps.model` की प्रॉपर्टी `images` में प्लग किए गए अमान्य संदर्भ का पता चला - स्टेप प्रॉपर्टी 
सख्ती से बैच-उन्मुख इनपुट्स की आवश्यकता रखती है, जबकि इनपुट सेलेक्टर में गैर-बैच-उन्मुख इनपुट है - यह संकेत देता है 
कि आपके वर्कफ़्लो के निर्माण में समस्या है - आम तौर पर समस्या तब आती है जब गैर-बैच-उन्मुख स्टेप इनपुट्स को 
गैर-बैच-उन्मुख स्टेप्स या गैर-बैच-उन्मुख इनपुट्स के आउटपुट्स से भरा जाता है।

Execution Engine में v1.6.0, यह सीमा हटा दी गई है, जिससे निम्न व्यवहार पेश किया गया है:

• जब यह पता चलता है कि किसी दिए गए इनपुट को बैच-उन्मुख होना चाहिए, तो Auto Batch Casting नामक प्रक्रिया लागू की जाती है। Auto Batch Casting यह इनपुट को स्वचालित रूप से परिवर्तित करके Batch[T]में बदल देती है। चूँकि सभी बैच-मोड इनपुट पहले से ही मैनिफ़ेस्ट में स्पष्ट रूप से दर्शाए गए थे, इसलिए अधिकांश ब्लॉक्स (नीचे उल्लिखित अपवादों के साथ) किसी भी आंतरिक बदलाव के बिना इस अपग्रेड का लाभ उठाते हैं।

• ऑटो-बैच कास्ट पैरामीटर की आयामिता (नेस्टिंग का स्तर) कंपाइलेशन समय पर, वर्कफ़्लो में विशिष्ट ब्लॉक के संदर्भ और उसके मैनिफ़ेस्ट के आधार पर निर्धारित की जाती है। यदि अन्य बैच-उन्मुख इनपुट मौजूद हैं (जिन्हें लाइनिएज सपोर्ट्सकहा जाता है), तो Execution Engine ऑटो-कास्ट किए गए बैचों का निर्माण करते समय उन्हें संदर्भ के रूप में उपयोग करता है। यह सुनिश्चित करता है कि प्रत्येक बैच आयाम में तत्वों की संख्या स्टेप में दिए गए अन्य डेटा से मेल खाए (जैसे कि वास्तविक बैच इनपुट प्रदान किए जाने पर जो assert किया जाता, उसका अनुकरण करते हुए)। यदि कोई लाइनिएज सपोर्ट्सनहीं हैं, या यदि ब्लॉक मैनिफ़ेस्ट इसकी आवश्यकता करता है (जैसे, इनपुट आयामिता ऑफ़सेट सेट हो), तो गायब आयाम torch.unsqueeze(...) ऑपरेशन के समान तरीके से उत्पन्न किए जाते हैं.

• फिर स्टेप आउटपुट्स का मूल्यांकन Auto Batch Casting संदर्भ की उपस्थिति के विरुद्ध किया जाता है। मूल्यांकन के आधार पर, आउटपुट्स को बैच या स्केलर के रूप में सहेजा जाता है, जिससे कास्टिंग का प्रभाव स्थानीय बना रहता है, और एकमात्र अपवाद ब्लॉक स्वयं द्वारा किए गए आउटपुट आयामिता परिवर्तनों का होता है। इसके परिणामस्वरूप, अब यह संभव है कि:

  • स्केलर्स से आउटपुट बैच बनाए जाएँ (जब स्टेप आयामिता बढ़ाता है), और

  • बैचों को स्केलर्स में समेटा जाए (जब ब्लॉक आयामिता घटाता है)।

• दो संभावित घर्षण बिंदु उत्पन्न होते हैं - पहला जब कोई ब्लॉक बैच स्वीकार नहीं करता (और इसलिए बैच-स्वीकार करने वाले इनपुट्स को निर्दिष्ट नहीं करता) आउटपुट आयामिता घटाता है। पिछले संस्करणों में, Execution Engine ने इसे आयामिता रैपिंग लागू करके संभाला: सभी बैच-उन्मुख इनपुट्स के साथ एक अतिरिक्त Batch[T] आयाम run(...) जोड़ा जाता था, जिससे ब्लॉक की get_parameters_enforcing_auto_batch_casting(...)मेथड को सूची आयाम पर reduce ऑपरेशनों को करने की अनुमति मिलती थी। Auto Batch Casting के साथ, हालांकि, ऐसे ब्लॉक अब Execution Engine को इस बारे में स्पष्ट संकेत नहीं देते कि कुछ इनपुट स्केलर्स हैं या बैच, जिससे कास्टिंग अनिर्धारित हो जाती है। इसे संबोधित करने के लिए, एक नई मैनिफ़ेस्ट मेथड पेश की गई:

नई मेथड का मौजूदा ब्लॉक्स पर प्रभाव

को परिभाषित करने की आवश्यकता get_parameters_enforcing_auto_batch_casting(...) मेथड, ऊपर वर्णित मामले में Auto Batch Casting सुविधा का पूरी तरह उपयोग करने के लिए, गैर-कठोर है। यदि ब्लॉक में बदलाव नहीं किया जाएगा, तो एकमात्र प्रभाव यह होगा कि वे वर्कफ़्लो जो पहले विफल हो रहे थे कंपाइलेशन त्रुटि के साथ, वे काम कर सकते हैं या रनटाइम त्रुटिके साथ विफल हो सकते हैं, यह ब्लॉक के विवरणों पर निर्भर करेगा run(...) मेथड इम्प्लीमेंटेशन।

• दूसरा घर्षण बिंदु तब उत्पन्न होता है जब कोई ऐसा ब्लॉक हो जो get_parameters_accepting_batches_and_scalars(...) का उपयोग करके बैचों और स्केलर्स दोनों को समर्थन देने वाले इनपुट फ़ील्ड्स घोषित करता है - डिफ़ॉल्ट रूप से, Execution Engine ऐसे पैरामीटर्स के लिए ऑटो-कास्टिंग छोड़ देगा, क्योंकि यह मेथड ऐतिहासिक रूप से हमेशा यह घोषित करने का एक तरीका रहा है कि स्वयं ब्लॉक में स्केलर्स को बैचों में ब्रॉडकास्ट करने की क्षमता है - देखें का इम्प्लीमेंटेशन roboflow_core/detections_transformation@v1 ब्लॉक का। एक तरह से, Auto Batch Casting अनावश्यक उन ब्लॉक्स के लिए है - इसलिए हम प्रस्ताव करते हैं कि उन्हें जस का तस छोड़ दिया जाए और नए संस्करणों में get_parameters_enforcing_auto_batch_casting(...) के बजाय उपयोग किया जाए get_parameters_accepting_batches_and_scalars(...) ऐसे ब्लॉक्स के।

• पहले के संस्करणों में, एक सख्त बाधा थी: आयामिता संकुचन केवल स्तर ≥ 2 पर ही हो सकता था (अर्थात केवल नेस्टेड बैचों पर)। यह सीमा अब हटा दी गई है। आयामिता-संकुचन ब्लॉक्स स्केलर्स पर भी काम कर सकते हैं, और आउटपुट आयामिता शून्य आधार से 'टकराकर' वापस उछलती है।

एक महत्वपूर्ण बदलाव आउटपुट्स के निर्माण के तरीके में है। Execution Error के पहले के संस्करणों में, किसी ब्लॉक को सीधे Batch[X] पहले आयाम स्तर पर उत्पन्न करने की अनुमति नहीं थी - वह स्थान इनपुट बैचों पर मैपिंग के लिए आरक्षित था। संस्करण v1.6.0से शुरू होकर, यह प्रतिबंध हटा दिया गया है।

पहले, आउटपुट्स हमेशा तत्वों की सूची के रूप में लौटाए जाते थे:

• जो इनपुट बैचों के साथ संरेखित होती थी, या

• यदि इनपुट के रूप में केवल स्केलर्स दिए गए हों, तो एक-तत्व सूची।

इससे एक प्रश्न उठता था: यदि कोई ब्लॉक अब पहले आयाम स्तर पर बैच उत्पन्न करता है, तो क्या होना चाहिए? हम इसे बस zip(...) करके इनपुट-आधारित आउटपुट्स के साथ नहीं जोड़ सकते, क्योंकि इन नए उत्पन्न बैचों का आकार इनपुट तत्वों की संख्या से मेल न भी खा सकता है - जिससे ऑपरेशन अस्पष्ट हो जाता है।

इसे हल करने के लिए, हमने निम्न नियम अपनाया:

• स्थिति को ऐसे समझें जैसे कि आकार 1 का एक "डमी" इनपुट बैच.

• स्केलर इनपुट्स से उत्पन्न सभी बैचों को उनकी वास्तविक उपस्थिति से एक स्तर गहराई में माना जाए।

• यह ब्रॉडकास्टिंग के सिद्धांत का अनुसरण करता है, जिससे ऐसे आउटपुट सभी तत्वों में सुसंगत रूप से विस्तारित हो सकते हैं।

• एक्ज़ीक्यूशन के परिणामस्वरूप इनपुट बैच गायब हो सकता है, लेकिन जब ऐसा होता है और नया प्रथम-स्तरीय आयाम प्रकट होता है, तब भी आउटपुट्स की सुसंगतता सुनिश्चित करने के लिए उसे आभासी रूप से नेस्टेड रखा जाएगा।

उदाहरण:

(कोई इनपुट नहीं)    IMAGE FETCHER BLOCK --> image --> OD MODEL --> predictons --> CROPS --> आउटपुट होगा: ["crops": [<crop>, <crop>, ...]] 

यह ध्यान देना महत्वपूर्ण है कि पहले बनाए गए वैध वर्कफ़्लो से उत्पन्न परिणाम समान होंगे और यह परिवर्तन केवल नई कार्यक्षमताओं का उपयोग करने के लिए बनाए गए नए वर्कफ़्लो को प्रभावित करेगा।

माइग्रेशन गाइड

`get_parameters_enforcing_auto_batch_casting(...)` मेथड जोड़ना

जो ब्लॉक्स आउटपुट आयामिता को घटाते हैं और बैच-उन्मुख इनपुट्स को परिभाषित नहीं करते, उन्हें उन सभी इनपुट्स की घोषणा करनी होगी जिन्हें इम्प्लीमेंटेशन के अनुसार `Batch` में लपेटा जाना अपेक्षित है Batch[T] ब्लॉक मैनिफ़ेस्ट की नई क्लास मेथड के साथ जिसे कहा जाता है get_parameters_enforcing_auto_batch_casting(...)

from typing import List, Literal, Type, Union

import supervision as sv

from inference.core.utils.drawing import create_tiles
from inference.core.workflows.execution_engine.entities.base import (
    Batch,
    OutputDefinition,
    WorkflowImageData,
)
from inference.core.workflows.execution_engine.entities.types import (
    IMAGE_KIND,
    OBJECT_DETECTION_PREDICTION_KIND,
    Selector,
)
from inference.core.workflows.prototypes.block import (
    BlockResult,
    WorkflowBlock,
    WorkflowBlockManifest,
)

class BlockManifest(WorkflowBlockManifest):
    type: Literal["my_plugin/tile_detections@v1"]
    crops: Selector(kind=[IMAGE_KIND])
    crops_predictions: Selector(
        kind=[OBJECT_DETECTION_PREDICTION_KIND]
    )
    scalar_parameter: Union[float, Selector()]

    @classmethod
    def get_output_dimensionality_offset(cls) -> int:
        return -1

    @classmethod
    def get_parameters_enforcing_auto_batch_casting(cls) -> List[str]:
        return ["crops", "crops_predictions"]

    @classmethod
    def describe_outputs(cls) -> List[OutputDefinition]:
        return [
            OutputDefinition(name="visualisations", kind=[IMAGE_KIND]),
        ]

class TileDetectionsBlock(WorkflowBlock):

    @classmethod
    def get_manifest(cls) -> Type[WorkflowBlockManifest]:
        return BlockManifest

    def run(
        self,
        crops: Batch[WorkflowImageData],
        crops_predictions: Batch[sv.Detections],
        scalar_parameter: float,
    ) -> BlockResult:
        print("यह वह पैरामीटर है जिस पर ऑटो-बैच कास्ट लागू नहीं होगा!", scalar_parameter)
        annotator = sv.BoxAnnotator()
        visualisations = []
        for image, prediction in zip(crops, crops_predictions):
            annotated_image = annotator.annotate(
                image.numpy_image.copy(),
                prediction,
            )
            visualisations.append(annotated_image)
        tile = create_tiles(visualisations)
        return {"visualisations": tile}

• पंक्तियों में 34-36 उन फ़ील्ड्स की घोषणा जोड़नी होगी जो अनिवार्य ऑटो-बैच कास्टिंग के अधीन होंगी

• उपरोक्त के परिणामस्वरूप, run मेथड के इनपुट पैरामीटर्स (पंक्तियों 53-54) को लपेट दिया जाएगा Batch[T] Execution Engine द्वारा।

Execution Engine v1.5.0 | inference v0.38.0

कोई कार्रवाई आवश्यक नहीं

इस परिवर्तन के लिए Workflows उपयोगकर्ताओं से किसी बदलाव की आवश्यकता नहीं है। यह केवल प्रदर्शन अनुकूलन है।

• के init मेथड में नया पैरामीटर उजागर किया गया BaseExecutionEngine क्लास - executor जो Python के instance को स्वीकार कर सकता है ThreadPoolExecutor जिसका उपयोग execution engine द्वारा किया जा सके। इस परिवर्तन के कारण, प्रोसेसिंग तेज होनी चाहिए, क्योंकि प्रत्येक BaseExecutionEngine.run(...) को अब समर्पित instance की आवश्यकता नहीं होगी ThreadPoolExecutor जैसा अब तक था। इसके अतिरिक्त, हम थ्रेड्स के निर्माण को काफी सीमित कर रहे हैं, जो कुछ इंस्टॉलेशनों में लाभकारी भी हो सकता है।

• परिवर्तन के बावजूद, Execution Engine एक साथ निष्पादित होने वाले स्टेप्स की सीमा बनाए रखता है - एक समय में executor के माध्यम से चलने वाले स्टेप्स की संख्या सीमित करके (क्योंकि अब Execution Engine ThreadPoolExecutor के निर्माण पर नियंत्रण नहीं रखता, और संभव है कि पूल में अधिक वर्कर्स उपलब्ध हों)।

`ThreadPoolExecutor` को Execution Engine में कैसे इंजेक्ट करें?

from concurrent.futures import ThreadPoolExecutor
workflow_init_parameters = { ... }
with ThreadPoolExecutor(max_workers=...) as thread_pool_executor:
    execution_engine = ExecutionEngine.init(
        init_parameters=workflow_init_parameters,
        max_concurrent_steps=4,
        workflow_id="your-workflow-id",
        executor=thread_pool_executor,
    )
    runtime_parameters = {
      "image": cv2.imread("your-image-path")
    }
    results = execution_engine.run(runtime_parameters=runtime_parameters)

Execution Engine v1.4.0 | inference v0.29.0

• नया kind जोड़ा गया - secret क्रेडेंशियल्स को दर्शाने के लिए। कोई कार्रवाई आवश्यक नहीं मौजूदा ब्लॉक्स के लिए, फिर भी अपेक्षा है कि समय के साथ ब्लॉक्स के डेवलपर्स इस kind का उपयोग करें, जब भी कोई ब्लॉक पैरामीटर के रूप में secret मान स्वीकार करे।

• में प्रस्तुत परिणामों की सीरियलाइज़ेशन संबंधी समस्या ठीक की गई v1.3.0 - गलती से, Execution Engine गैर-बैच-उन्मुख आउटपुट्स को सीरियलाइज़ नहीं कर रहा था।

• स्टेप्स के लिए इनपुट तैयार करने में Execution Engine की बग ठीक की गई। पहले गैर-SIMD स्टेप्स के लिए, रनटाइम में इनपुट्स एकत्र करते समय, WorkflowBlockManifest.accepts_empty_input() मेथड का परिणाम अनदेखा किया जा रहा था - जिससे वह बग उत्पन्न हुआ जब एक गैर-SIMD स्टेप डाउनस्ट्रीम ब्लॉक्स को खाली मान दे रहा था। इसके अतिरिक्त, में किए गए परिवर्तनों के प्रकाश में v1.3.0, जिनकी वजह से गैर-SIMD ब्लॉक्स आसानी से डाउनस्ट्रीम SIMD स्टेप्स के लिए इनपुट्स दे सकते हैं - यह जाँचना आवश्यक है कि अपस्ट्रीम गैर-SIMD ब्लॉक ने गैर-खाली परिणाम दिए हैं या नहीं (क्योंकि SIMD ब्लॉक खाली परिणाम स्वीकार नहीं कर सकता)। यह जाँच जोड़ दी गई। कोई कार्रवाई आवश्यक नहीं मौजूदा ब्लॉक्स के लिए, लेकिन यह सुधार पहले से टूटे हुए Workflows को ठीक कर सकता है।

Execution Engine v1.3.0 | inference v0.27.0

• ऐसा परिवर्तन पेश किया गया जिसमें प्रत्येक kind के लिए serializer और deserializer परिभाषित किए जा सकें। यह परिवर्तन Workflows plugins को Execution Engine से अलग करता है और ऐसा संभव बनाता है कि इकोसिस्टम को बाहरी प्रणालियों के साथ एकीकृत किया जा सके जिन्हें वायर के माध्यम से डेटा ट्रांसफ़र की आवश्यकता होती है। ब्लॉक्स बंडलिंग पेज को उस परिवर्तन को प्रतिबिंबित करने के लिए अपडेट किया गया।

• प्रकार में परिभाषित roboflow_core प्लगइन को उपयुक्त serializers और deserializers दिए गए

• Workflows Compiler और Execution Engine को बेहतर बनाया गया ताकि वे किसी भी प्रकारके बैच-उन्मुख इनपुट्स का समर्थन कर सकें, इसके विपरीत संस्करणों से पहले v1.3.0, जो केवल image और video_metadata प्रकारों को बैच-उन्मुख इनपुट्स के रूप में ले सकते थे (Execution Engine के स्तर पर प्रस्तुत kind को आंतरिक डेटा प्रारूप से दुर्भाग्यपूर्ण और अनावश्यक रूप से जोड़ने के परिणामस्वरूप Execution Engine के स्तर पर)। परिवर्तन के परिणामस्वरूप:

  • नया input type पेश किया गया: WorkflowBatchInput अब से बैच-उन्मुख इनपुट्स को दर्शाने के लिए इसका उपयोग किया जाना चाहिए (और उन्हें स्पष्ट रूप से WorkflowParameters). WorkflowBatchInput से अलग करने के लिए) ताकि उपयोगकर्ता दोनों परिभाषित कर सकें प्रकार डेटा का और उसके आयामिता। नया input type प्रभावी रूप से सभी पिछले बैच-उन्मुख इनपुट्स का सुपरसेट है: WorkflowImage और WorkflowVideoMetadata, जो समर्थित बने रहेंगे, लेकिन Execution Engine में हटा दिए जाएँगे v2। हम नए input format के अनुसार समायोजित करने की सलाह देते हैं, फिर भी इस समय आवश्यकता सख्त नहीं है - क्योंकि Execution Engine अब input data की स्पष्ट परिभाषा की मांग करता है प्रकार ताकि डेटा deserializer को सही ढंग से चुना जा सके। भविष्य में ऐसा नहीं भी हो सकता है, क्योंकि अधिकांश मामलों में बैच-उन्मुख डेटा प्रकार कंपाइलर द्वारा अनुमानित किया जा सकता है (हालाँकि यह सुविधा अभी के लिए लागू नहीं की गई है)।

  • नया selector type annotation पेश किया गया - जिसे सरल रूप से नाम दिया गया है Selector(...). Selector(...) को प्रतिस्थापित करने के लिए माना जाता है StepOutputSelector, WorkflowImageSelector, StepOutputImageSelector, WorkflowVideoMetadataSelector और WorkflowParameterSelector ब्लॉक मैनिफ़ेस्ट में, जिससे डेवलपर्स यह व्यक्त कर सकें कि किसी विशिष्ट स्टेप मैनिफ़ेस्ट प्रॉपर्टी में किसी विशिष्ट प्रकारका सेलेक्टर रखा जा सकता है। उल्लिखित पुराने annotation types को अप्रचलित माना जाना चाहिए, हम इसमें माइग्रेट करने की सलाह देते हैं Selector(...).

  • सेलेक्टर प्रकार एनोटेशनों के सरलीकरण के परिणामस्वरूप, पुराना selector अब ब्लॉक्स की run(...) मेथड के किस पैरामीटर को Execution Engine द्वारा Batch[X] कंटेनरमें लपेटकर शिप किया गया है, इसकी जानकारी प्रदान नहीं करेगा। पुराने selectors type annotations और block_manifest.accepts_batch_input() मेथड के बजाय, हम दो मेथड्स पर स्विच करने का प्रस्ताव करते हैं जो स्पष्ट रूप से उन पैरामीटर्स को परिभाषित करती हैं जिनमें बैच-उन्मुख डेटा दिए जाने की अपेक्षा है (block_manifest.get_parameters_accepting_batches()) और ऐसे पैरामीटर्स जो दोनों बैच और स्केलर मानों को स्वीकार कर सकते हैं (block_manifest.get_parameters_accepting_batches_and_scalars())। का return value block_manifest.accepts_batch_input() दो नई मेथड्स के परिणामों पर आधारित है। यह परिवर्तन non-breakingहै, क्योंकि कोई भी मौजूदा ब्लॉक जो बैचों को प्रोसेस करने में सक्षम था, उसे block_manifest.accepts_batch_input() मेथड return True करने और उपयुक्त selector type annotation का उपयोग करने के लिए लागू किया गया होगा, जो बैच-उन्मुख डेटा को इंगित करता था।

• परिवर्तनों के परिणामस्वरूप, अब यह संभव है कि किसी भी मनमाने वर्कफ़्लो को स्टेप्स के उपसमूहों को निष्पादित करने वाले कई वर्कफ़्लो में विभाजित किया जा सके, जिससे डिबगर जैसे टूल बनाए जा सकें।

आगामी ब्रेकिंग परिवर्तन - Execution Engine v2.0.0

• WorkflowImage और WorkflowVideoMetadata इनपुट्स Workflows इकोसिस्टम से हटा दिए जाएंगे।

• StepOutputSelector, WorkflowImageSelector, StepOutputImageSelector, WorkflowVideoMetadataSelectorऔरब्लॉक मैनिफ़ेस्ट में उपयोग किए गए `StepOutputSelector` और `WorkflowParameterSelector` प्रकार एनोटेशन Workflows इकोसिस्टम से हटा दिए जाएंगे। {% endhint %}

माइग्रेशन गाइड

प्रकारों के serializers और deserializers

अपना Workflows plugin बनाते समय आप Workflows प्रकारोंके लिए custom serializers और deserializers पेश कर सकते हैं। ऐसा करने के लिए, बस प्लगइन के मुख्य मॉड्यूल में निम्न dictionaries रखें (उसी स्थान पर जहाँ आप load_blocks(...) फ़ंक्शन रखते हैं):

from typing import Any

def serialize_kind(value: Any) -> Any:
  # यहाँ वह कोड रखें जिसका उपयोग
  # आंतरिक Workflows डेटा प्रतिनिधित्व को 
  # बाहरी प्रतिनिधित्व में बदलने के लिए किया जाएगा (जिसे JSON में वायर के माध्यम से भेजा जा सकता है, Python के
  # डिफ़ॉल्ट JSON encoder का उपयोग करके)।
  pass

def deserialize_kind(parameter_name: str, value: Any) -> Any:
  # यहाँ वह कोड रखें जिसका उपयोग 
  # वायर के माध्यम से Execution Engine को भेजे गए डेटा को डीकोड करने के लिए किया जाएगा
  # और उसे उचित आंतरिक Workflows डेटा प्रतिनिधित्व में बदलने के लिए
  # जिसे ब्लॉक्स समझते हैं।
  pass

KINDS_SERIALIZERS = {
    "name_of_the_kind": serialize_kind,
}
KINDS_DESERIALIZERS = {
    "name_of_the_kind": deserialize_kind,
}

सेलेक्टर्स के लिए नया type annotation - `Batch[X]` इनपुट्स के बिना ब्लॉक्स

ब्लॉक मैनिफ़ेस्ट को वैकल्पिक रूप से निम्न प्रकार से उपयोग करने के लिए अपडेट किया जा सकता है Selector :

from typing import Union
from inference.core.workflows.prototypes.block import WorkflowBlockManifest
from inference.core.workflows.execution_engine.entities.types import (
    INSTANCE_SEGMENTATION_PREDICTION_KIND,
    OBJECT_DETECTION_PREDICTION_KIND,
    FLOAT_KIND,
    WorkflowImageSelector,
    StepOutputImageSelector,
    StepOutputSelector,
    WorkflowParameterSelector,
)

class BlockManifest(WorkflowBlockManifest):

    reference_image: Union[WorkflowImageSelector, StepOutputImageSelector]
    predictions: StepOutputSelector(
        kind=[
            OBJECT_DETECTION_PREDICTION_KIND,
            INSTANCE_SEGMENTATION_PREDICTION_KIND,
        ]
    )
    confidence: WorkflowParameterSelector(kind=[FLOAT_KIND]) 

को बस इसमें बदला जाना चाहिए:

from inference.core.workflows.prototypes.block import WorkflowBlockManifest
from inference.core.workflows.execution_engine.entities.types import (
    INSTANCE_SEGMENTATION_PREDICTION_KIND,
    OBJECT_DETECTION_PREDICTION_KIND,
    FLOAT_KIND,
    IMAGE_KIND,
    Selector,
)

class BlockManifest(WorkflowBlockManifest):
    reference_image: Selector(kind=[IMAGE_KIND])
    predictions: Selector(
        kind=[
            OBJECT_DETECTION_PREDICTION_KIND,
            INSTANCE_SEGMENTATION_PREDICTION_KIND,
        ]
    )
    confidence: Selector(kind=[FLOAT_KIND]) 

सेलेक्टरों के लिए नया type annotation - `Batch[X]` इनपुट वाले ब्लॉक्स

ब्लॉक मैनिफ़ेस्ट को वैकल्पिक रूप से निम्न प्रकार से उपयोग करने के लिए अपडेट किया जा सकता है Selector :

from typing import Union
from inference.core.workflows.prototypes.block import WorkflowBlockManifest
from inference.core.workflows.execution_engine.entities.types import (
    INSTANCE_SEGMENTATION_PREDICTION_KIND,
    OBJECT_DETECTION_PREDICTION_KIND,
    FLOAT_KIND,
    WorkflowImageSelector,
    StepOutputImageSelector,
    StepOutputSelector,
    WorkflowParameterSelector,
)

class BlockManifest(WorkflowBlockManifest):

    reference_image: Union[WorkflowImageSelector, StepOutputImageSelector]
    predictions: StepOutputSelector(
        kind=[
            OBJECT_DETECTION_PREDICTION_KIND,
            INSTANCE_SEGMENTATION_PREDICTION_KIND,
        ]
    )
    data: Dict[str, Union[StepOutputSelector(), WorkflowParameterSelector()]]
    confidence: WorkflowParameterSelector(kind=[FLOAT_KIND]) 

    @classmethod
    def accepts_batch_input(cls) -> bool:
        True लौटाएँ

को बस इसमें बदला जाना चाहिए:

from inference.core.workflows.prototypes.block import WorkflowBlockManifest
from inference.core.workflows.execution_engine.entities.types import (
    INSTANCE_SEGMENTATION_PREDICTION_KIND,
    OBJECT_DETECTION_PREDICTION_KIND,
    FLOAT_KIND,
    IMAGE_KIND,
    Selector,
)

class BlockManifest(WorkflowBlockManifest):
    reference_image: Selector(kind=[IMAGE_KIND])
    predictions: Selector(
        kind=[
            OBJECT_DETECTION_PREDICTION_KIND,
            INSTANCE_SEGMENTATION_PREDICTION_KIND,
        ]
    )
    data: Dict[str, Selector()]
    confidence: Selector(kind=[FLOAT_KIND]) 

    @classmethod
    def get_parameters_accepting_batches(cls)W -> List[str]:
        return ["predictions"]

    @classmethod
    def get_parameters_accepting_batches_and_scalars(cls) -> List[str]:
        return ["data"]

कृपया यह स्पष्ट करें कि:

• यह डेटा मूल उदाहरण में property दोनों को स्वीकार कर सकती थी बैच डेटा और स्केलर मानों को batch-oriented डेटा के selector के कारण (StepOutputSelector) और स्केलर डेटा (WorkflowParameterSelector)। अब वही इसके द्वारा प्रदर्शित होता है Selector(...) type annotation और return value द्वारा get_parameters_accepting_batches_and_scalars(...) विधि।

वर्कफ़्लो परिभाषाओं में नए इनपुट

कोई भी जिसने WorkflowImage या WorkflowVideoMetadata इनपुट्स का उपयोग अपनी Workflows परिभाषा में किया हो, वह वैकल्पिक रूप से पर माइग्रेट कर सकता है WorkflowBatchInput. नीचे परिवर्तन दर्शाया गया है:

{
  "inputs": [
    {"type": "WorkflowImage", "name": "image"},
    {"type": "WorkflowVideoMetadata", "name": "video_metadata"}
  ]
}

को बस इसमें बदला जाना चाहिए:

{
  "inputs": [
    {
      "type": "WorkflowBatchInput",
      "name": "image",
      "kind": ["image"]
    },
    {
      "type": "WorkflowBatchInput",
      "name": "video_metadata",
      "kind": ["video_metadata"]
    }
  ]
}

छोड़ना प्रकार फ़ील्ड खाली छोड़ने से images जैसे कुछ डेटा के सही ढंग से डीसिरियलाइज़ होने में बाधा आ सकती है।

नोट

यदि आपको यह पसंद नहीं है कि डेटा किस तरह serialize होता है roboflow_core plugin में, तो आप बेझिझक serialization methods बदल सकते हैं प्रकारों, बस function को अपने plugin में register करके और उसे Execution Engine में load करके - आख़िर में परिभाषित serializer/deserializer उपयोग में रहेगा।

Execution Engine v1.2.0 | inference v0.23.0

• यह video_metadata प्रकार को अप्रचलित कर दिया गया है, और हम इसके उपयोग को blocks बनाने के लिए आगे जारी रखने की दृढ़ता से अनुशंसा नहीं करते. एक विकल्प के रूप में, image प्रकार को समान metadata का समर्थन करने के लिए विस्तारित किया गया है जैसा video_metadata प्रकार, जिसे अब वैकल्पिक रूप से प्रदान किया जा सकता है। यह अपडेट non-breaking मौजूदा blocks के लिए है, लेकिन कुछ पुराने blocks जो images उत्पन्न करते हैं असंगत हो सकते हैं के साथ भविष्य के video processing blocks.

संभावित blocks असंगतता

जैसा कि पहले बताया गया, जोड़ने से video_metadata को आंतरिक representation में एक वैकल्पिक फ़ील्ड के रूप में image प्रकार (WorkflowImageData class) मौजूदा blocks के बीच कुछ friction पैदा कर सकता है जो output करते हैं image प्रकार और भविष्य के video processing blocks जो निर्भर करते हैं video_metadata के image representation का हिस्सा होने पर।

समस्या इसलिए आती है क्योंकि, जबकि हम प्रदान कर सकते हैं डिफ़ॉल्ट मान video_metadata के लिए image में बिना उन्हें input से स्पष्ट रूप से copy किए, upstream जोड़ा गया कोई भी non-default metadata खो सकता है। इससे downstream blocks जो निर्भर करते हैं video_metadata अपेक्षा के अनुसार काम न करें।

हमने सभी मौजूदा roboflow_core blocks को इसके अनुसार अद्यतन किया है, लेकिन external repositories में इस परिवर्तन से पहले बनाए गए blocks उन workflows में समस्याएँ पैदा कर सकते हैं जहाँ उनके output images video processing blocks द्वारा उपयोग किए जाते हैं।

• जबकि deprecated video_metadata प्रकार अभी भी उपयोग के लिए उपलब्ध है, इसे Execution Engine version में पूरी तरह हटा दिया जाएगा v2.0.0.

आगामी ब्रेकिंग परिवर्तन - Execution Engine v2.0.0

video_metadata प्रकार को अप्रचलित कर दिया गया है और इसे हटाया जाएगा v2.0.0

• ऊपर बताए गए परिवर्तनों के परिणामस्वरूप, का आंतरिक representation image प्रकार को एक नया शामिल करने के लिए अपडेट किया गया है video_metadata property. इस property को constructor में वैकल्पिक रूप से सेट किया जा सकता है; यदि प्रदान नहीं की जाती, तो उचित default values वाला default value उपयोग किया जाएगा। blocks के भीतर metadata manipulation को सरल बनाने के लिए, हमने दो नए class methods पेश किए हैं: WorkflowImageData.copy_and_replace(...) और WorkflowImageData.create_crop(...). अधिक विवरण के लिए, अपडेटेड देखें WoorkflowImageData उपयोग गाइड.