이미지 및 사진 · 소셜 이미지 크기 조정 도구
브라우저 이미지 크기 조정 작동 방식: 캔버스, drawImage 및 리샘플링
· 작동 방식
이미지 크기 조정 캔버스 브라우저 처리 중
브라우저는 서버 없이 사진을 디코딩하고 새로운 크기로 캔버스에 그린 다음 결과를 인코딩할 수 있습니다. 이 게시물은 해당 파이프라인을 따라가며 품질이 획득되거나 손실되는 위치를 설명하고 유일한 크기 제한이 장치 메모리인 이유를 보여줍니다.
업로드 없음, 서버 없음, 여전히 크기 조정됨 — 페이지가 20 메가픽셀 사진을 축소할 때 작업이 어디서 발생하는지에 대한 구체적인 질문입니다.
사진은 이미지 처리 서버를 방문하지 않고도 1350 인물 사진을 통해 1080이 될 수 있습니다. Social Image Resizer는 브라우저 선택기에서 파일을 수신하고 MIME 유형과 크기를 확인한 후 createImageBitmap을 호출합니다. 디코딩된 비트맵은 선택된 모든 출력의 소스로 유지되므로 하나의 로컬 개체가 여러 모양의 캔버스에 피드를 제공할 수 있습니다.
표시되는 미리보기는 네트워크 요청 뒤에 숨겨진 최종 내보내기가 아닙니다. 이는 동일한 프레이밍 상태(대상 비율, 확대/축소, 오프셋, 맞춤 모드 및 배경)의 더 작은 캔버스 렌더링입니다. 미리 설정된 크기로 렌더링되는 나중에 반복을 내보내고, Blob을 인코딩하고, Blob을 페이지의 다운로드 컨트롤에 전달합니다.
디코딩은 로컬이지만 이 도구는 40 MB 입력 제한도 적용합니다.
계획에는 장치 메모리가 유일한 실제 경계라고 나와 있지만 제공된 입력 경로에도 명시적인 40 MB 파일 제한이 있습니다. JPEG, PNG 및 WebP이 허용됩니다. 다른 유형은 디코딩 전에 거부됩니다. 해당 게이트 이후 createImageBitmap은 압축된 파일 바이트를 캔버스에서 사용할 수 있는 너비, 높이 및 디코딩된 픽셀로 변환하도록 브라우저에 요청합니다.
디코딩된 픽셀은 압축된 파일보다 훨씬 더 많은 메모리를 차지할 수 있으며 각 출력 캔버스에는 자체 할당이 필요합니다. 따라서 렌더러는 캔버스를 생성하기 전에 공유 픽셀 예산 가드를 호출합니다. 이는 40 MB 아래의 모든 파일이 모든 시스템에서 요청된 모든 출력에 적합하다고 약속하는 권한이 아닌 장치 중심의 두 번째 제약 조건입니다.
drawImage는 출력 캔버스 클립이 오버플로되는 동안 위치가 지정된 전체 비트맵의 크기를 조정합니다.
ToolAcre는 소스 자르기 직사각형을 계산하지 않고 drawImage에 8개의 소스 및 대상 인수를 전달합니다. 소스 및 대상 차원에서 크기를 계산하고 크기가 조정된 전체 비트맵을 배치한 다음 가장자리가 오버플로되는 부분이 잘리는 캔버스에 그립니다. 표지 모드에서는 클리핑이 자르기입니다. 포함 모드에서는 전체 비트맵이 계속 표시됩니다.
자르기와 크기 조정은 동의어가 아니기 때문에 구별이 중요합니다. 크기를 조정하면 비트맵이 샘플링되는 크기가 변경됩니다. 자르기는 유한 출력 프레임 외부에 있는 모든 것을 제거합니다. 하나의 drawImage 호출은 여기에서 두 가지 효과 모두에 참여할 수 있지만 먼저 소스 파일을 다시 작성하는 대신 프레임 형상 및 클리핑을 통해 자르기가 생성됩니다.
내부 리샘플링 — 스무딩 설정, '고품질' 힌트가 브라우저에 요청하는 것, 브라우저 간에 결과가 약간 다른 이유
그리기 전에 렌더러는 imageSmoothingEnabled를 활성화하고 imageSmoothingQuality를 높음으로 설정합니다. 이는 명명된 Lanczos, bicubic 또는 기타 커널에 대한 요청이 아닌 브라우저 캔버스 컨트롤입니다. API는 브라우저의 정확한 계수 테이블이 아닌 품질 힌트를 노출하므로 구현 시 엔진 전체에서 동일한 샘플을 약속할 수 없습니다.
유용한 비교는 소스, 출력 크기 및 브라우저를 고정한 다음 대각선 가장자리, 미세한 선 및 반복되는 텍스처를 검사합니다. 다른 브라우저가 약간 다르다고 해서 목표 비율이 변경된 것은 아닙니다. 이는 동일한 기하학적 요청이 다른 캔버스 구현을 통해 전달되었음을 의미하며, 이것이 바로 기사에서 발명된 성능 또는 품질 비율을 피하는 이유입니다.
출력 인코딩 — 캔버스를 다시 인코딩된 이미지 파일로 변환하고 다운로드할 수 있도록 제공
내보내기 캔버스는 해당 메서드가 존재하는 경우 OffscreenCanvas.convertToBlob을 통해 Blob이 되고 그렇지 않은 경우 HTMLCanvasElement.toBlob이 됩니다. 사용자는 JPEG, PNG 또는 WebP를 선택합니다. PNG은 JPEG 및 WebP와 같은 방식으로 손실 품질 제어를 사용하지 않지만 품질 값은 인코더에 제공됩니다. 결과 바이트 수는 추정되는 것이 아니라 측정됩니다.
선택한 여러 대상에 대해 도구는 각 Blob을 순서대로 빌드하고 실제 크기와 측정된 크기를 표시하며 이미 인코딩된 파일을 ZIP으로 패키징할 수 있습니다. ZIP 저장은 여기서 이미지 압축을 향상시키지 않습니다. 콘텐츠에는 해당 형식이 이미 압축되어 있다고 나와 있습니다. 개별 다운로드와 아카이브는 모두 로컬에서 생성된 바이트에서 시작됩니다.
이 구현은 웹 워커가 아닌 메인 스레드에서 내보내기 작업을 수행합니다.
통합 문서에는 무거운 작업이 일반적으로 Web Worker에서 실행된다고 나와 있지만 이 앱은 자르기 및 렌더링 기능을 직접 main.js로 가져오고 거기에서 대상을 반복합니다. 검사된 경로에는 작업자가 생성되지 않습니다. 페이지는 일반 작업에 계속 사용할 수 있지만 존재하지 않는 아키텍처로 인한 것이 아니라 응답성을 관찰해야 합니다.
네트워크 격리는 두 가지 종류의 증거로 지원됩니다. 핵심 테스트는 네트워크 가드를 설치하고 모든 사전 설정을 시도하지 않고 프레임하는 반면 제품 기록은 로컬 처리를 표시합니다. 런타임 네트워크 패널 검사를 통해 배포 증거를 추가할 수 있습니다. 전체 페이지가 요청을 하지 않는다고 주장하는 대신 이미지 업로드를 일반 페이지 자산 또는 공개된 분석과 구별해야 합니다.
여기서 다루지 않는 내용 — GPU 가속 크기 조정 라이브러리 및 서버 측 이미지 파이프라인
이 경로는 GPU 라이브러리나 원격 미디어 파이프라인이 아닌 브라우저 기본 요소를 기반으로 의도적으로 구축되었습니다. 선택 가능한 리샘플링 커널, 벤치마크 대체 알고리즘을 노출하거나 가속화된 배치 처리를 약속하지 않습니다. 하나의 소스 이미지는 여러 개의 자르기를 생성합니다. 관련되지 않은 많은 소스 파일은 다른 작업 흐름에 속합니다.
이러한 제외는 약속을 테스트 가능하게 유지합니다. 이 코드는 파일 유효성 검사, 비트맵 디코딩, 산술 프레이밍, 캔버스 그리기, Blob 인코딩 및 다운로드 어셈블리를 증명합니다. 서버 팜이 동일한 픽셀의 크기를 조정하는 방법이나 브라우저가 내부적으로 선택할 수 있는 GPU 경로를 증명하지는 않습니다. 클레임은 사용된 관찰 가능한 웹 API에서 중지됩니다.
요점: 귀하의 브라우저에는 이미 리사이저가 내장되어 있습니다. 소셜 이미지 리사이저가 이를 구동하여 파일을 업로드하지 않고도 플랫폼의 가로 세로 비율에 맞게 자르고 크기를 조정합니다.
브라우저는 이미 필수 작업을 제공하지만 유용한 결과는 주변의 올바른 형상에 따라 달라집니다. Social Image Resizer는 표지에 대한 최대 배율, 포함에 대한 최소 배율, 클램프 이동을 선택하고 안전 영역 지침을 별도로 미리 보고 정확한 대상 크기로 내보냅니다. 이러한 오케스트레이션은 낮은 수준의 그리기 API를 반복 가능한 사회 자산 워크플로우로 전환합니다.
이전에 축소된 복사본이 아닌 원본 이미지로 파이프라인을 테스트합니다. 현재 도구 사전 설정 또는 사용자 정의 비율을 선택하고, 피사체를 이동하고, 한 번 내보내고 다운로드한 크기를 검사하세요. 증거는 모든 브라우저가 동일한 숨겨진 리샘플러를 사용한다는 주장이 아니라 받은 로컬 파일과 이를 만든 코드 경로입니다.