실행 엔진 변경 로그

Workflows 실행 엔진의 버전별 변경 사항입니다.

아래에서 Execution Engine의 변경 내역을 확인할 수 있습니다.

미출시

변경 사항

사용자에게 보이는 컴파일 또는 실행 동작 변경 사항을 여기에 추가하세요. 유지관리자는 릴리스 시 이 제목을 Execution Engine 및 inference 버전으로 바꿉니다.

• 로컬 워크플로 모델을 로드하는 동안 발생한 모델 접근 실패는 이제 일반적인 HTTP 500 오류로 표시되는 대신 HTTP 402, 403, 423 상태를 유지합니다.

---

실행 엔진 v1.15.0 | inference 1.3.9

• 원격 HTTP 501 오류는 내부 URL을 노출하지 않고 상태를 유지합니다 — 원격으로 실행된 Workflow 단계가 HTTP 501을 반환하면, Execution Engine은 이제 내부 producer URL을 포함한 일반적인 HTTP 500 대신 동일한 상태와 API 메시지를 가진 클라이언트 원인 Workflow 오류를 표시합니다.

실행 엔진 v1.14.0 | inference 1.3.8

변경 사항

• 출력 직렬화가 문자열로 선언된 종류를 허용합니다 — 출력 종류가 일반 문자열(예: "string")로 선언되고 Kind 객체가 아닌 경우, 출력 직렬화가 TypeError: unhashable type: 'list'로 충돌하여 전체 Workflow 실행이 HTTP 500으로 표시되었습니다. 이제 이러한 종류는 이름으로 해석되므로, 일치하는 serializer가 적용됩니다(또는 해당 종류에 대해 serializer가 등록되어 있지 않으면 원시 값이 그대로 전달됩니다).

• 블록은 종속 리소스를 선언할 수 있습니다 — WorkflowBlockManifest 에 인스턴스 메서드가 추가됩니다 discover_dependent_resources() -> Optional[List[DependentResource]] 이 메서드는 파싱된 단계가 실행에 사용할 외부 리소스를 선언할 수 있게 하여, 호출자(플랫폼, 사전 로드 및 인증 사전 점검 도구)가 워크플로 정의에서 이를 정적으로 열거할 수 있게 합니다. 이 봉투는 Execution Engine이 규제하며, 리소스 유형은 roboflow_platform_model, roboflow_platform_project 및 third_party_model이며, 각각 유형이 있는 직렬화 가능한(pydantic) 메타데이터 엔터티를 가집니다. 플랫폼 모델 항목은 사용 목적의 성격도 추가로 명시합니다: required_action (access — 모델 엔터티는 플랫폼에서 도달 가능하기만 하면 됨, vs execution — 모델이 실행됨) 그리고 실행의 경우 execution_location (local / remote / environment_defined — 로컬/원격 여부는 WORKFLOWS_STEP_EXECUTION_MODE에 의해 런타임에 결정됩니다). 자체 로컬성 오버라이드가 적용되는 블록은 이를 그 자리에서 지정합니다 — SAM3 이미지 블록은 SAM3_EXEC_MODE=remote 일 때 아무것도 선언하지 않으며(프록시 실행은 구성된 model id를 무시하고 고정된 SAM3를 서버 측에서 실행), environment_defined 그 외의 경우에도 마찬가지입니다. None 을 반환하는 것(기본값)은 블록이 종속성을 선언하지 않는다는 뜻이며, 이는 []와는 다릅니다. 후자는 외부 리소스가 필요하지 않음을 선언합니다. 워크플로 선택자인 필드 값($inputs.<name> / $steps.<name>.<property>)은 그대로 보고되며, 각 메타데이터 엔터티는 이러한 참조를 구체적인 식별자와 구분하기 위해 requires_runtime_resolution() 을 노출합니다. 최종 id가 필드 값에서 합성되는 선언(예: 패밀리 접두사 clip/<version> , 카탈로그 조회)에는 추가로 비직렬화 가능한 model_id_resolver 호출 가능 객체가 붙는데, 이는 대체된 입력 값을 실행되는 id로 바꿉니다 — 직렬화, JSON 스키마 및 동등성 비교에서는 제외됩니다. 모델, Roboflow 프로젝트 또는 타사 호스팅 모델을 참조하는 모든 핵심 블록은 이 메서드를 구현하며, 각 구현은 run() 이 실제로 로드하는 모델 식별자(버전 필드에서 합성된 id 포함, 예: clip/<version>)를 그대로 반영합니다. 프로젝트 선언은 정적 manifest 값에서 결정되는 활성화 제어를 따릅니다: Roboflow 모델 블록은 disable_active_learning 이 문자 그대로 True (기본값)일 때 활성 학습 대상이 제거되며, 데이터셋 업로드 블록은 disable_sink 이 문자 그대로 True일 때 아무것도 선언하지 않습니다; 선택자에서 가져온 제어는 보수적인 may-need 선언을 유지합니다. introspection은 active_learning_target_dataset 속성에서 멈춥니다 — 활성 학습이 명시적 대상 없이 활성화된 경우 모델 id로부터 프로젝트가 파생되지 않습니다. 모델 관리자 외부에서 모델 가중치를 로드하는 블록(SAM2/SAM3 비디오 추적기, 즉 AutoModel.from_pretrained를 사용하는 블록)은 현재 의도적으로 이 메서드를 구현하지 않습니다 — 이들의 종속성은 선언되지 않은 상태로 유지됩니다(None).

• 동적(custom python) 블록은 알 수 없는 종속성을 보고합니다 — 동적 블록을 위해 합성된 manifest는 None 를 discover_dependent_resources()에서 반환합니다: python 본문은 정적 분석으로는 파악할 수 없으므로, "알 수 없음"이 유일하게 정직한 답입니다.

• 엔진 초기화 시 선언된 Roboflow 모델의 선택적 사전 로드 — ExecutionEngine.init(...) 은 새로운 선택적 매개변수 dependencies_pre_init 을 허용합니다(기본값 None): 사전 로드할 종속 리소스 유형 이름 목록이며, 현재 지원되는 값은 roboflow_platform_model 뿐입니다. 활성화되면 엔진은 컴파일된 모든 단계의 선언된 종속성을 추론하고(deduce_blocks_dependencies 를 compiler utils에서) 모델 관리자에 실행용으로 선언된 모든 구체적인 Roboflow 플랫폼 모델을 등록합니다(둘 다 init_parameters에서 가져오며, API 키도 마찬가지). 이는 init() 중에 수행되어 — 어떤 실행보다 먼저 — 첫 추론 지연을 예측 가능하게 합니다. 참조가 포함된 선언은 초기화 시 로드할 수 없으며, $inputs.<name> 첫 번째 실행에서만 — 런타임 입력 검증 후이므로, 잘못된 요청은 단일 시도 횟수를 소모하지도 다운로드를 유발하지도 않습니다 — 엔진은 제공된 런타임 매개변수(입력 기본값 적용 포함)에 대해 이를 해석하고, 연결된 경우 선언의 run() 를 적용합니다(예: 대체된 CLIP 버전이 사전 로드되도록 하며, 실행에서 사용하는 id와 정확히 동일함), 그리고 식별자가 구체화된 모델을 등록합니다. 리졸버가 model_id_resolver 를 반환하면 clip/<version>서명된 값을 정적으로 해석할 수 없음을 선언합니다(예: 다른 입력에 따라 최종 id가 결정되는 Qwen의 fine-tuned sentinel 라벨) — 종속성은 건너뛰고 실행 시점에 해석됩니다; 리졸버가 처리할 수 없는 제출된 입력 값(예: 알 수 없는 카탈로그 라벨)은 None RuntimeInputError 를 발생시킵니다. 등록은 각 블록의 실제 로더를 반영합니다: 선언은 비직렬화 가능한을 포함할 수 있습니다. model_registration_kwargs (예: endpoint_type=CORE_MODEL CLIP / OCR / SAM2 / YOLO-World 스타일 코어 모델용, load_core_model()과 일치). 각 사전 로드 패스 후 엔진은 등록된 모델이 아직 모델 관리자에 남아 있는지 확인하고, 크기/메모리 제한 관리자가 일부를 제거한 경우 경고를 기록합니다(이들은 실행 시점에 지연 로드됨). 사전 로드는 유효한 단계 실행 모드를 따릅니다(명시적 step_execution_mode init 매개변수 또는 WORKFLOWS_STEP_EXECUTION_MODE 기본값): environment_defined 선언은 단계가 로컬에서 실행될 때만 사전 로드되고, local 선언은 항상 사전 로드되며, 접근 전용 선언(가중치가 로드되지 않음), 원격 실행 및 $steps.…에서 가져온 식별자는 절대 사전 로드되지 않습니다. InferencePipeline.init_with_workflow(...) 은 이를 선택적 workflows_dependencies_pre_init 매개변수로 노출합니다(기본값 None — 사전 로드 없음) — 비디오 처리는 예측 가능한 시작 시점의 이점을 가장 많이 얻습니다.

실행 엔진 v1.13.0 | inference v1.3.7

변경 사항

• 오프라인 모드는 원격 Workflow 단계 실행을 거부합니다 — OFFLINE_MODE 가 활성화되면 컴파일러는 StepExecutionMode.REMOTE 를 단계 초기화 중에 거부합니다(WorkflowEnvironmentConfigurationError) 그래서 Workflows는 네트워크 접근 없이 원격 추론 클라이언트를 열 수 없습니다. 로컬 단계 실행은 캐시가 예열된 상태에서 계속 동작합니다.

• 올바른 모델 접근 실패 상태 코드 - 로컬 워크플로 모델을 로드하는 동안 발생한 모델 접근 실패는 이제 일반적인 HTTP 500 오류로 표시되는 대신 HTTP 402, 403, 423 상태를 유지합니다.

실행 엔진 v1.12.0 | inference v1.3.2

변경 사항

미래 해석 - 일부 단계는 이제 Future 객체를 내보낼 수 있으며, 이 객체는 출력이 클라이언트에 의해 필요해질 때까지 출력 해석을 미룹니다. 다운스트림 블록의 경우 이러한 future는 step_input_assembler 에서 해석되며, 출력 구성은 output_constructor 에서 좌표 변환과 함께 수행됩니다.

실행 엔진 v1.11.0 | inference v1.3.1

변경 사항

• dict 단계 선택자에 대한 케이스별 실행 분기 - 흐름 제어 블록이 Dict[str, StepSelector] 속성 안에 단계 선택자를 선언하면( List[StepSelector]가 아니라), 컴파일러는 이제 딕셔너리 키마다 별도의 실행 분기를 생성합니다. 이전에는 단일 속성의 모든 선택자가 하나의 분기를 공유하여, 블록이 대상에 독립적으로 라우팅할 수 없었습니다. 이제 분기 이름에는 딕셔너리 키가 포함됩니다(예: Branch[$steps.switch -> cases[red]]). 리스트 속성(예: next_steps)에 들어 있는 선택자는 이전의 공유 분기 동작을 유지하므로 기존 블록에는 영향이 없습니다. 이 변경은 새로운 roboflow_core/switch_case@v1 블록(graph_constructor.establish_control_flow_edge).

• 수정: 반복되는 분기 이름이 있는 SIMD가 아닌 흐름 제어 마스크 - 단일 리스트 속성을 통해 하나 이상의 대상을 선택하는 SIMD가 아닌 흐름 제어 단계에서 Attempted to re-register maks for execution branch오류가 발생했습니다. 이제 분기 마스크 등록은 등록 전에 분기 이름을 중복 제거하여 충돌을 수정합니다(예: ContinueIf 여러 next_steps; execution_data_manager.manager._register_control_flow_output_for_non_simd_step).

실행 엔진 v1.10.1 | inference v1.2.12

변경 사항

• 중첩된 inner workflow의 동적 블록 - 컴파일러는 이제 루트 워크플로와 모든 중첩된 dynamic_blocks_definitions child를 깊이 우선으로 수집하고, inner_workflow 로 중복을 제거하며, manifest.block_type 기준으로 (첫 번째 항목이 우선되며, 중복이 건너뛰어질 때 경고가 기록됩니다) 병합된 목록을 루트 정의에 올린 뒤 compile_dynamic_blocks 및 인라인화를 수행합니다. 중첩된 워크플로 사양에만 정의된 사용자 정의 Python 블록 유형을 사용하는 자식 단계는 인라인화 후에도 올바르게 컴파일되고 실행됩니다.

실행 엔진 v1.10.0 | inference v1.2.10

변경 사항

• 값이 정적 값과 선택자의 혼합인 딕셔너리를 인식하는 기능이 추가되었습니다 - 이전 버전에서는 키를 선택자에 매핑하는 딕셔너리만 인식되어, 일부 블록은 런타임에 참조된 값에 올바르게 연결되지 않았습니다. 이 변경은 비파괴적이지만, 과거에 깨져 있던 특정 블록을 수정합니다.

실행 엔진 v1.9.0 | inference v1.2.0

새 기능: 컴파일 시 인라이닝을 통한 중첩 워크플로

이번 릴리스는 roboflow_core/inner_workflow@v1 블록을 추가하여 워크플로가 다른 워크플로 정의를 내장할 수 있게 합니다(인라인 JSON 또는 다음에서 해석됨 workflow_workspace_id / workflow_id / 선택적 workflow_version_id). 자식 입력은 parameter_bindings 를 통해 부모에서 연결됩니다(자식 inputs[].name → 부모 선택자). 컴파일 시 엔진은 인라인 처리하고 중첩 단계들을 부모 그래프로 넣습니다; 실행은 일반 단계와 동일한 경로를 사용합니다(별도의 중첩 런타임 없음).

변경 사항

• Inner workflow 블록 - 새 흐름 제어 블록 유형 roboflow_core/inner_workflow@v1 등록 위치 roboflow_core. 부모 출력은 자식 워크플로 JsonField 출력을 $steps.<inner_step_name>.<child_output_name> 로 참조할 수 있으며, 인라인화가 선택자를 다시 쓸 때까지 유지됩니다.

• 컴파일 파이프라인 - 루트 정의를 파싱하기 전에 컴파일러는: (1) 정규화하고 참조를 정규화합니다(기본값: Roboflow API + workflows_core.api_key, 또는 사용자 정의 workflows_core.inner_workflow_spec_resolver), (2) 구성을 검증하고 (비순환성, 최대 중첩 깊이, 최대 inner-workflow 수), (3) 인라인 처리하고 모든 inner workflow 단계를 일반 단계로 인라인 처리한 뒤, 파싱, 워크플로 사양 검증, 실행 그래프 구성으로 진행합니다.

• 제한 사항(환경 변수) - WORKFLOWS_MAX_INNER_WORKFLOW_DEPTH 을 허용합니다(기본값 4)는 루트로부터의 포함 깊이를 제한합니다; WORKFLOWS_MAX_INNER_WORKFLOW_COUNT 을 허용합니다(기본값 32)는 중첩 정의의 총 inner_workflow 단계 수를 제한합니다.

• 문서 - Inner workflows (nested definitions) 를 참조하여 사용법, 바인딩, 제한 사항, 예제를 확인하세요.

실행 엔진 v1.8.0 | inference v1.1.1

부작용이 최소로 예상되는 버그 수정으로 인한 추가 변경 + 1개의 파괴적 변경

이번 릴리스는 Execution Engine을 확장하여 흐름 제어에 의해 게이트되는 단계(예: ContinueIf 블록 데이터 유래 lineage가 없어도 실행할 수 있게 합니다 - 즉, 상위 단계로부터 배치 지향 입력을 받지 않는 경우에도 가능합니다. 이제 lineage와 실행 차원성은 흐름 제어 선행 단계에서 파생될 수 있습니다. 기존 워크플로에는 영향이 없습니다.

도입된 하나의 파괴적 변경은 버그 수정 때문이며 Batch.remove_by_indices 가 중첩 배치에서 동작하는 방식에 영향을 줍니다(아래 참조); 영향은 최소일 것으로 예상됩니다.

변경 사항

• 흐름 제어 lineage - 컴파일러는 이제 흐름 제어 단계에서 오는 lineage를 추적합니다(예: ContinueIf뒤의 분기). 새로운 개념의 흐름 제어 lineage 지원 은 단계에 배치 지향 데이터 입력이 없지만 흐름 제어 단계가 앞에 올 때 사용됩니다: 단계의 실행 슬라이스와 배치 구조는 해당 흐름 제어 선행 단계에서 가져옵니다.

• 완화된 호환성 검사 - 이전에는 verify_compatibility_of_input_data_lineage_with_control_flow_lineage 가 ControlFlowDefinitionError 를 흐름 제어 선행 단계는 있지만 데이터 유래 lineage는 없는 모든 단계에 대해 발생시켰기 때문에, 이러한 단계는 컴파일할 수 없었습니다. 이제 그 검사는 완화되었습니다: 단계에 입력 데이터 lineage가 없으면 호환성은 강제되지 않으며, 대신 단계의 lineage는 흐름 제어 선행 단계 lineage에서 파생됩니다. 엄격한 검사는 단계가 실제로 데이터 유래 lineage를 가지고 있을 때만 계속 실행되어, 흐름 제어와 데이터 lineage가 호환되도록 보장합니다.

• 새로운 단계 패턴 - 흐름 제어에 의해서만 트리거되고 배치 데이터를 소비하지 않는 단계가 이제 올바르게 실행됩니다. 예를 들어, ContinueIf 과 같은 파라미터에 데이터를 연결하지 않고도 이메일 알림을 보내거나 다른 부작용 단계들을 실행할 수 있습니다. message_parameters; 단계는 제어 단계에서 가져온 lineage와 차원성을 사용하여 흐름 제어 분기당 한 번씩 실행됩니다.

• Batch.remove_by_indices 중첩 배치(동작 수정) - Batch.remove_by_indices를 통해 인덱스를 제거할 때, 중첩 Batch 요소는 이제 동일한 인덱스 집합으로 재귀적으로 필터링됩니다. 그 결과 제거된 인덱스의 항목( None 값 포함)도 중첩 배치에서 올바르게 제거됩니다. 이전에는 최상위 배치만 필터링되었고, 중첩 배치는 변경되지 않은 채로 남아 있었습니다.

  기본적으로 WorkflowBlock, accepts_empty_values()는 False입니다. 이 검사를 우회하는 동안 이러한 입력을 소비하는 블록은 예를 들어 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]
      ...

  이 변경이 영향을 미치는 유일한 핵심 블록은 DimensionCollapseBlockV1 블록입니다. None 값을 필터링하지 않고 개별 입력을 배치로 감싸고 있었기 때문입니다.

  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]}

  이 블록의 출력을 사용할 때 다운스트림 애플리케이션은 이 값을 직접 필터링하지 않으면 아예 실패하거나 None 값을 조용히 처리할 수 있었습니다.

  위에서 언급한 바와 같이 영향은 최소일 것으로 봅니다.

실행 엔진 v1.7.0 | inference v0.59.0

워크플로에서 단계 오류와 관련된 파괴적 변경

invalid HTTP responses codes와 관련된 버그를 수정하기 위해 inference-server 에서 Workflow 실행 요청을 처리하는 과정에서, Execution Engine의 오류 처리 기본 메커니즘을 변경해야 했습니다. 이 변경의 결과로, Roboflow Hosted Platform 및 inference>=0.59.0에서 즉시 적용되며, 클라이언트 설정 오류(잘못된 Roboflow API 키, 잘못된 모델 ID 등)로 실패하는 Roboflow 플랫폼과 상호작용하는 Workflow 블록은 StepExecutionError 를 발생시키는 대신(그리고 서버의 HTTP 500 응답) ClientCausedStepExecutionError 를 발생시키며(그리고 400, 401, 403, 404 같은 관련 HTTP 응답 코드를 반환합니다).

이 변경의 영향을 받는 시나리오 목록:

• Roboflow 모델을 사용하는 블록이 잘못된 모델 ID를 정의함 - 이제 ClientCausedStepExecutionError 상태 코드 400으로 발생

• Roboflow 모델을 사용하는 블록이 잘못된 API 키를 정의함 - 이제 ClientCausedStepExecutionError 상태 코드 401로 발생

• Roboflow 모델을 사용하는 블록이 모델에 접근할 수 있는 권한 범위가 없는 잘못된 API 키 또는 유효한 키 누락을 정의함 - 이제 ClientCausedStepExecutionError 상태 코드 403으로 발생

• Roboflow 모델을 사용하는 블록이 존재하지 않는 모델을 정의함 - 이제 ClientCausedStepExecutionError 상태 코드 404로 발생

복원하기 레거시 오류 처리

필요한 경우 오류 핸들러의 레거시 동작을 복원할 수 있으며, 이는 전환 기간에 도움이 될 수 있습니다. 필요한 작업은 환경 변수를 설정하는 것뿐입니다. DEFAULT_WORKFLOWS_STEP_ERROR_HANDLER=legacy.

실행 엔진 v1.6.0 | inference v0.53.0

변경 사항에 주의가 필요할 수 있습니다

이 릴리스에는 다음을 포함하는 업그레이드 및 새 기능이 도입됩니다 변경 불필요 기존 워크플로에 대해. 일부 블록은 최신 Execution Engine 기능을 활용하기 위해 업그레이드해야 할 수 있습니다.

이전 버전의 Execution Engine에는 특정 유형의 블록, 특히 단일 명령어 다중 데이터(SIMD) 모드로 작동하는 블록과 상호작용할 때 상당한 제한이 있었습니다. 이러한 블록은 입력 배치를 한 번에 처리하고, 각 요소에 동일한 작업을 적용하며, 전체 배치에 대한 결과를 반환하도록 설계되었습니다.

예를 들어, run(...) 이러한 블록의 메서드는 다음과 같을 수 있습니다:

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

매니페스트에서 image 필드는 배치를 허용하는 것으로 선언됩니다.

문제는 입력 이미지가 배치에서 작동하지 않는 블록에서 왔을 때 발생했습니다. 이러한 경우 Execution Engine은 개별 이미지로부터 배치를 구성할 수 없었으며, 이로 인해 다음과 같은 답답한 컴파일 오류가 자주 발생했습니다:

단계 `$steps.model`의 속성 `images`에 연결된 잘못된 참조가 감지되었습니다 - 단계 속성은 
엄격히 배치 지향 입력을 요구하지만, 입력 선택기는 비배치 지향 입력을 보유하고 있습니다 - 이는 다음을 나타냅니다 
워크플로 구성 문제 - 일반적으로 문제는 비배치 지향 단계 입력이 
비배치 지향 단계의 출력 또는 비배치 지향 입력으로 채워질 때 발생합니다.

Execution Engine에서 v1.6.0, 이 제한이 제거되어 다음 동작이 도입되었습니다:

• 주어진 입력이 배치 지향이어야 한다고 감지되면, 자동 배치 캐스팅 이라는 절차가 적용됩니다. 이는 입력을 자동으로 Batch[T]로 변환합니다. 모든 배치 모드 입력은 이미 매니페스트에 명시적으로 표시되어 있었으므로, 대부분의 블록은(아래에 언급된 예외 제외) 내부 변경 없이 이 업그레이드의 이점을 얻습니다.

• 자동 배치 캐스트 매개변수의 차원 수(중첩 수준)는 워크플로 내 특정 블록의 컨텍스트와 해당 매니페스트를 기반으로 컴파일 시점에 결정됩니다. 다른 배치 지향 입력이 존재하는 경우(이를 계보 지원이라고 함), Execution Engine은 자동 캐스팅된 배치를 구성할 때 이를 참조로 사용합니다. 이를 통해 각 배치 차원의 요소 수가 단계에 공급되는 다른 데이터와 일치하도록 보장합니다(실제 배치 입력이 제공되었다면 검증되었을 내용을 시뮬레이션함). 계보 지원가 없거나 블록 매니페스트가 이를 요구하는 경우(예: 입력 차원 오프셋이 설정된 경우), 누락된 차원은 다음과 유사하게 생성됩니다 torch.unsqueeze(...) 연산.

• 그런 다음 단계 출력은 자동 배치 캐스팅 컨텍스트의 존재 여부에 따라 평가됩니다. 평가 결과에 따라 출력은 배치 또는 스칼라로 저장되며, 블록 자체가 도입한 출력 차원 변경을 제외하고 캐스팅의 효과가 로컬하게 유지되도록 합니다. 부수적으로 이제 다음이 가능해졌습니다:

  • 스칼라에서 출력 배치 생성 (단계가 차원 수를 증가시킬 때), 그리고

  • 배치를 스칼라로 축소 (블록이 차원 수를 감소시킬 때).

• 두 가지 잠재적인 마찰 지점이 발생합니다 - 첫 번째는 배치를 허용하지 않는 블록이 (따라서 배치를 허용하는 입력을 표시하지 않는) 출력 차원 수를 감소시킬 때. 이전 버전에서는 Execution Engine이 차원 래핑을 적용하여 이를 처리했습니다. 모든 배치 지향 입력은 추가 Batch[T] 차원으로 래핑되어 블록의 run(...) 메서드가 목록 차원 전체에 대해 축소 연산을 수행할 수 있었습니다. 그러나 자동 배치 캐스팅에서는 이러한 블록이 특정 입력이 스칼라인지 배치인지에 대한 명확한 신호를 더 이상 Execution Engine에 제공하지 않으므로 캐스팅이 비결정적이 됩니다. 이를 해결하기 위해 새 매니페스트 메서드가 도입되었습니다: get_parameters_enforcing_auto_batch_casting(...). 이 메서드는 차원 수가 감소할 때 배치 캐스팅을 강제해야 하는 매개변수 목록을 반환해야 합니다. 다른 컨텍스트에서 사용할 것으로 예상되지 않습니다.

새 메서드가 기존 블록에 미치는 영향

정의 요구 사항 get_parameters_enforcing_auto_batch_casting(...) 메서드를 정의하여 위에서 설명한 경우에 자동 배치 캐스팅 기능을 완전히 사용하는 것은 엄격한 요구 사항이 아닙니다. 블록을 변경하지 않으면 유일한 효과는 워크플로가 이전에 실패했던 컴파일 오류와 함께 작동하거나 실패할 수 있다는 것이며 런타임 오류, 이는 블록의 세부 사항에 따라 달라집니다 run(...) 메서드 구현.

• 두 번째 마찰 지점은 배치와 스칼라를 모두 지원하는 입력 필드를 선언한 블록이 다음을 사용하여 존재할 때 발생합니다 get_parameters_accepting_batches_and_scalars(...) - 기본적으로 Execution Engine은 이러한 매개변수에 대한 자동 캐스팅을 건너뜁니다. 역사적으로 이 메서드는 블록 자체가 스칼라를 배치로 브로드캐스트할 수 있는 능력이 있음을 선언하는 방법이었기 때문입니다 - 다음을 참조하세요 다음의 구현 roboflow_core/detections_transformation@v1 블록. 어떤 의미에서 자동 배치 캐스팅은 중복됩니다 이러한 블록에서는 - 따라서 그대로 두고 다음을 사용하도록 업그레이드할 것을 제안합니다 get_parameters_enforcing_auto_batch_casting(...) 대신 get_parameters_accepting_batches_and_scalars(...) 이러한 블록의 새 버전에서.

• 이전 버전에는 엄격한 제약이 있었습니다. 차원 축소는 2 이상 수준(즉, 중첩된 배치에서만)에서만 발생할 수 있었습니다. 이제 이 제한이 제거되었습니다. 차원 축소 블록은 스칼라에서도 작동할 수 있으며, 출력 차원은 0 기준점에서 “튕겨 나옵니다”.

한 가지 출력 생성 방식의 주요 변경 사항이 있습니다. 이전 버전의 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[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에 의해.

실행 엔진 v1.5.0 | inference v0.38.0

변경 사항에 별도의 조치가 필요하지 않습니다

이 변경 사항은 Workflows 사용자에게 어떠한 변경도 요구하지 않습니다. 이는 단지 성능 최적화입니다.

• 다음의 init 메서드에 새 매개변수 노출 BaseExecutionEngine 클래스 - executor Python의 인스턴스를 허용할 수 있는 ThreadPoolExecutor 를 Execution Engine에서 사용합니다. 이 변경 덕분에 각 BaseExecutionEngine.run(...) 이 더 이상 전용 인스턴스를 요구하지 않으므로 처리가 더 빨라질 것입니다 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)

실행 엔진 v1.4.0 | inference v0.29.0

• 새 kind 추가 - secret 자격 증명을 나타내기 위한 것입니다. 조치 불필요 기존 블록의 경우에는 해당하지만, 시간이 지나면 블록 개발자는 블록이 매개변수로 비밀 값을 허용할 때마다 이 kind를 사용해야 합니다.

• 다음에서 도입된 결과 직렬화 문제 수정 v1.3.0 - 실수로 Execution Engine이 비배치 지향 출력을 직렬화하지 않았습니다.

• 단계 입력 준비와 관련된 Execution Engine 버그를 수정했습니다. 이전에는 런타임에 비SIMD 단계의 입력을 수집할 때 WorkflowBlockManifest.accepts_empty_input() 메서드 결과가 무시되어 하나의 비SIMD 단계가 다운스트림 블록에 빈 값을 공급할 때 버그가 발생했습니다. 또한 다음에서 이루어진 변경 사항에 비추어 볼 때 v1.3.0, 이로 인해 비SIMD 블록이 다운스트림 SIMD 단계에 쉽게 입력을 공급할 수 있으므로 업스트림 비SIMD 블록이 비어 있지 않은 결과를 산출했는지 확인해야 합니다(SIMD 블록은 빈 결과를 허용하지 않을 수 있음). 이 검사가 추가되었습니다. 조치 불필요 기존 블록의 경우에는 해당하지만, 이 수정으로 이전에 손상된 Workflows가 수정될 수 있습니다.

실행 엔진 v1.3.0 | inference v0.27.0

• 각 kind가 직렬화기와 역직렬화기를 정의할 수 있도록 하는 변경 사항을 도입했습니다. 이 변경으로 Workflows 플러그인이 Execution Engine과 분리되고, 와이어를 통한 데이터 전송이 필요한 외부 시스템과 생태계를 통합할 수 있게 됩니다. 블록 번들링 페이지가 해당 변경 사항을 반영하도록 업데이트되었습니다.

• Kinds 다음에 정의된 roboflow_core 플러그인에 적절한 직렬화기와 역직렬화기가 제공되었습니다

• Workflows Compiler와 Execution Engine이 다음을 지원하도록 개선되었습니다 모든 kind의 배치 지향 입력을, 이전 버전과 달리 v1.3.0, 이전 버전은 다음만 받을 수 있었습니다 image 및 video_metadata kind를 배치 지향 입력으로(불행하고 불필요한 kind와 내부 데이터 형식의 결합이 도입된 결과로 Execution Engine 수준에서). 변경 결과:

  • 새 입력 유형이 도입되었습니다: WorkflowBatchInput 는 이제부터 배치 지향 입력을 나타내는 데 사용해야 합니다(그리고 다음과 명확히 구분합니다 WorkflowParameters). WorkflowBatchInput 사용자가 둘 다 정의할 수 있게 합니다 kind 데이터의 차원 수. 새 입력 유형은 사실상 이전의 모든 배치 지향 입력의 상위 집합입니다: WorkflowImage 및 WorkflowVideoMetadata, 이들은 계속 지원되지만, 그러나 Execution Engine에서 제거될 예정입니다 v2. 새 입력 형식으로 조정할 것을 권장하지만, 현재 요구 사항은 엄격하지 않습니다 - Execution Engine이 이제 입력 데이터의 명시적 정의를 요구하기 때문입니다 kind 적절한 데이터 역직렬화기를 선택하기 위해. 대부분의 경우 배치 지향 데이터는 kind 컴파일러가 추론할 수 있으므로 향후에는 그렇지 않을 수 있습니다(그러나 이 기능은 현재 구현되지 않았습니다).

  • 새 선택기 유형 어노테이션이 도입되었습니다 - 단순히 다음으로 명명되었습니다 Selector(...). Selector(...) 는 다음을 대체해야 합니다 StepOutputSelector, WorkflowImageSelector, StepOutputImageSelector, WorkflowVideoMetadataSelector 및 WorkflowParameterSelector 블록 매니페스트에서, 개발자가 특정 단계 매니페스트 속성이 특정 항목의 선택기를 보유할 수 있음을 표현할 수 있게 합니다 kind. 언급된 이전 어노테이션 유형은 더 이상 사용되지 않는 것으로 간주해야 합니다, 다음으로 마이그레이션할 것을 권장합니다 Selector(...).

  • 선택기 유형 어노테이션의 단순화로 인해 이전 선택기는 더 이상 블록의 어느 매개변수가 run(...) 메서드가 Execution Engine에 의해 다음으로 래핑되어 전달되는지에 대한 정보를 제공하지 않습니다 Batch[X] 컨테이너. 이전 선택기 유형 어노테이션 및 block_manifest.accepts_batch_input() 메서드 대신, 배치 지향 데이터가 공급될 것으로 예상되는 매개변수를 명시적으로 정의하는 두 메서드로 전환할 것을 제안합니다(block_manifest.get_parameters_accepting_batches()) 및 둘 다 받을 수 있는 매개변수 배치 및 스칼라 값 (block_manifest.get_parameters_accepting_batches_and_scalars()). 의 반환 값 block_manifest.accepts_batch_input() 는 두 새 메서드의 결과를 기반으로 구성됩니다. 이 변경은 호환성을 깨지 않습니다, 배치를 처리할 수 있었던 기존 블록은 반드시 다음을 구현했어야 하기 때문입니다 block_manifest.accepts_batch_input() 다음을 반환하는 메서드 True 및 배치 지향 데이터를 나타내는 적절한 선택기 유형 어노테이션을 사용합니다.

• 변경 결과, 이제 다음이 가능해졌습니다 임의의 워크플로를 단계 하위 집합을 실행하는 여러 개의 워크플로로 분할, 디버거와 같은 도구를 구축할 수 있습니다.

예정된 호환성 파괴 변경 - Execution Engine v2.0.0

• WorkflowImage 및 WorkflowVideoMetadata 입력은 Workflows 생태계에서 제거될 예정입니다.

• StepOutputSelector, WorkflowImageSelector, StepOutputImageSelector, WorkflowVideoMetadataSelector및블록 매니페스트에서 사용되는 WorkflowParameterSelector` 유형 어노테이션은 Workflows 생태계에서 제거될 예정입니다. {% endhint %}

마이그레이션 가이드

Kinds의 직렬화기 및 역직렬화기

Workflows 플러그인을 생성할 때 Workflows용 사용자 지정 직렬화기와 역직렬화기를 도입할 수 있습니다 kinds. 이를 위해 플러그인의 메인 모듈에 다음 딕셔너리를 배치하기만 하면 됩니다(다음을 배치하는 곳과 동일한 곳) load_blocks(...) 함수):

from typing import Any

def serialize_kind(value: Any) -> Any:
  # 여기에 사용할 코드를 작성합니다
  # 내부 Workflows 데이터 표현을 변환하기 위한 
  # 외부 표현으로(JSON에서 와이어를 통해 전송할 수 있으며,
  # Python의 기본 JSON 인코더 사용).
  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,
}

선택기를 위한 새 유형 어노테이션 - `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]) 

선택자에 대한 새로운 타입 주석 - `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:
        return 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"]

다음을 지적해 주세요:

• 그 데이터 원래 예시의 속성은 둘 다 허용할 수 있었습니다 배치 데이터와 스칼라 값은 배치 지향 데이터 선택자(StepOutputSelector) 및 스칼라 data(WorkflowParameterSelector). 이제 동일한 내용은 Selector(...) 타입 주석과 get_parameters_accepting_batches_and_scalars(...) 메서드의 반환값에 의해 나타납니다.

Workflow 정의의 새로운 입력

다음 중 하나를 사용한 사람은 누구나 WorkflowImage 또는 WorkflowVideoMetadata 자신의 Workflow 정의에서 입력을 사용할 수 있으며 선택적으로 다음으로 마이그레이션할 수 있습니다 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"]
    }
  ]
}

비워 두면 kind 필드를 비워 두면 이미지와 같은 일부 데이터가 올바르게 역직렬화되지 않을 수 있습니다.

참고

데이터가 직렬화되는 방식이 roboflow_core 플러그인에서 마음에 들지 않는다면, kinds함수를 플러그인에 등록하고 Execution Engine에 로드하기만 하면 됩니다. 마지막에 정의된 serializer/deserializer가 사용됩니다.

실행 엔진 v1.2.0 | inference v0.23.0

• 그 video_metadata kind 는 더 이상 사용되지 않게 되었으며, 우리는 앞으로 블록을 구축할 때 이 사용을 중단할 것을 강력히 권장합니다. 대안으로, image kind 는 다음과 동일한 메타데이터를 지원하도록 확장되었습니다: video_metadata kind, 이제 선택적으로 제공할 수 있습니다. 이번 업데이트는 호환성을 깨지 않습니다 기존 블록에는 일부 오래된 블록은 이미지를 생성하는 호환되지 않게 될 수 있습니다 와 미래의 비디오 처리 블록.

블록 간 잠재적 비호환성

앞서 언급했듯이, video_metadata 의 내부 표현에 선택적 필드로 추가하는 것은 image kind (WorkflowImageData 클래스)에 기존 블록과의 일부 마찰을 일으킬 수 있습니다. 이 블록들은 image kind 그리고 다음에 의존하는 미래의 비디오 처리 블록들 사이에서 video_metadata 의 일부인 것을 image 표현.

문제는, 우리가 제공할 수는 있지만 기본 값을 video_metadata 에서 image 입력에서 명시적으로 복사하지 않아도, 업스트림에서 추가된 기본값이 아닌 메타데이터는 손실될 수 있기 때문입니다. 이로 인해 다음에 의존하는 다운스트림 블록이 video_metadata 예상대로 작동하지 않을 수 있습니다.

우리는 기존의 모든 roboflow_core 블록을 이 점을 반영하도록 업데이트했지만, 외부 저장소에서 이 변경 전에 생성된 블록은 출력 이미지가 비디오 처리 블록에서 사용되는 워크플로에서 문제를 일으킬 수 있습니다.

• 더 이상 사용되지 않는 video_metadata kind 는 여전히 사용할 수 있지만, Execution Engine 버전에서 완전히 제거될 예정입니다 v2.0.0.

예정된 호환성 파괴 변경 - Execution Engine v2.0.0

video_metadata kind 더 이상 사용되지 않게 되었으며 다음에서 제거될 예정입니다 v2.0.0

• 위에서 언급한 변경 사항의 결과로, 다음의 내부 표현은 image kind 새로운 video_metadata 속성이 포함되도록 업데이트되었습니다. 이 속성은 생성자에서 선택적으로 설정할 수 있으며, 제공되지 않으면 적절한 기본값이 사용됩니다. 블록 내에서 메타데이터 조작을 단순화하기 위해 두 개의 새로운 클래스 메서드를 도입했습니다: WorkflowImageData.copy_and_replace(...) 및 WorkflowImageData.create_crop(...). 자세한 내용은 업데이트된 WoorkflowImageData 사용 가이드.