모델
기본 URL과 필요한 API 키로 OpenAI 호환 또는 Anthropic 엔드포인트를 설정하고 연결을 테스트하세요. 로컬 모델 서버는 실행 중이어야 합니다. 원격 도구는 데이터를 별도로 전송할 수 있습니다.
● ● ●RowChisel●
작업 흐름 · 정렬된 RGB24 행 오프셋 ×
def bitmap_row_offset(width, height, row, top_down=False):
if any(type(v) is not int for v in (width, height, row)) or type(top_down) is not bool:
raise ValueError("bitmap.type")
if not 1 <= width <= 4096 or not 1 <= height <= 4096 or not 0 <= row < height:
raise ValueError("bitmap.range")
stride = ((3*width+3)//4)*4
physical_row = row if top_down else height-1-row
return physical_row*stride, stride✳정렬된 RGB24 행 오프셋
✓ 변경 사항적용하기 전에 검토하세요 ↗
작업 공간 예시 화면
프로젝트
패딩 너비와 양방향을 시험하고 잘못된 행과 불리언이 아닌 방향을 거부하세요.
적용하기 전에 검토하세요
실제 동작을 예상 결과와 비교하세요. 검사가 실패하면 다음 변경을 하기 전에 원인을 조사하세요.
작업 흐름
def bitmap_row_offset(width, height, row, top_down=False):
if any(type(v) is not int for v in (width, height, row)) or type(top_down) is not bool:
raise ValueError("bitmap.type")
if not 1 <= width <= 4096 or not 1 <= height <= 4096 or not 0 <= row < height:
raise ValueError("bitmap.range")
stride = ((3*width+3)//4)*4
physical_row = row if top_down else height-1-row
return physical_row*stride, stride이진 주소 계산을 읽는 형식에 맞춰 유지하세요
픽셀 값 자체가 맞아도 이진 형식 버그는 왜곡된 이미지로 나타날 수 있습니다. RowChisel은 그 증상 뒤의 주소 계산 코드를 살펴보는 Windows AI 코딩 소프트웨어입니다. 관련 읽기 코드와 작은 테스트 사례를 대화에 가져와 제안된 수정이 애플리케이션에서 실제로 지원하는 형식을 따르게 하세요.
유용한 작업 하나는 정렬된 RGB24 데이터의 행 오프셋 검토입니다. 연결된 모델에게 패딩이 필요한 너비를 보여주고 행이 위에서부터 저장되는지 아래에서부터 저장되는지 설명하세요. 산술을 바꾸기 전에 요청한 행을 계산 과정에서 추적하도록 하여, 논리적 위치와 물리적 저장 위치를 구분하세요.
버퍼 읽기 코드가 오프셋을 사용하는 방식을 검토하세요. 행 계산이 맞아도 제공된 버퍼에 충분한 바이트가 있음을 입증하지는 않으며, 스트라이드 변경은 이후의 모든 접근에 영향을 줄 수 있습니다. 두 저장 방향 모두에서 작은 테스트 사례를 실행하고 잘못된 행 처리를 살펴보세요. 보조 함수만 따로 검토하지 말고 제안 변경을 호출자의 범위 검사와 비교하세요.
RowChisel은 지원되는 OpenAI 호환 또는 Anthropic 엔드포인트에 연결합니다. 설정한 서비스가 제공하는 어블리터레이션 AI 모델을 선택할 수 있으며 도구 지원과 컨텍스트는 해당 설정이 정합니다. 바이트 수와 예상 오프셋에 근거해 검토한 뒤 자체 프로젝트 도구로 애플리케이션 출력을 검증하세요.
읽는 형식에 맞는 이진 주소 계산 유지 — 수정 전 질문
어떤 테스트 사례가 행 패딩 오류를 드러내나요?
원시 행 길이에 정렬 패딩이 필요한 폭이 좁은 RGB24 이미지를 사용하세요. 예상 스트라이드와 오프셋을 명시하세요. 이미 정렬된 이미지 너비는 결함을 숨겨 잘못된 계산도 맞아 보이게 할 수 있습니다.
요청에 저장 방향을 명시하는 이유는 무엇인가요?
논리적 행 번호와 물리적 순서가 다를 수 있기 때문입니다. 처음 저장된 행이 이미지의 위쪽인지 아래쪽인지 보여주세요. 모델이 주소 계산 코드 변경을 제안할 때 그 계약을 보존하도록 요청하세요.
유효한 오프셋이면 버퍼를 안전하게 읽을 수 있나요?
아니요. 읽기 코드는 필요한 바이트가 제공된 버퍼에 존재하는지도 확인해야 합니다. 특히 치수가 외부 데이터에서 오면 그 경계를 별도로 검토하세요. 오프셋 보조 함수와 함께 버퍼 검증도 드러나게 유지하세요.
스트라이드 산술을 바꾼 뒤 무엇을 확인해야 하나요?
스트라이드를 사용하는 모든 호출자를 살펴보고 첫 행과 마지막 행을 테스트하며 잘못된 행 인덱스가 거부되는지 검증하세요. 두 저장 방향의 테스트 사례를 실행하세요. 그런 다음 디코딩 출력을 살펴 산술 자체를 넘어선 통합 오류를 찾으세요.
RowChisel · 업데이트 2026-10-25