이미지가 손실없이 회전하면 왜 파일 크기가 변경됩니까?

나는 무손실 이미지 회전 방법을 찾고 있었고이 질문에 대해 설명했습니다.

"Windows 사진 뷰어"회전이 손실되지 않습니까?

그래서 임의 픽셀 (Photoshop 클라우드 필터)이있는 256 × 256 JPEG를 만든 다음 Windows Picture Viewer를 사용하여 회전했습니다. 회전 후 파일 크기는 실제로 증가했지만 첫 번째 회전에서만 증가했습니다. 그 이후로 회전 할 때마다 파일 크기는 정적으로 유지됩니다. 눈에 띄지 않는 품질 손실없이 여러 번 회전했기 때문에 손실없이 회전한다는 것을 알고 있습니다. 반면 257 × 257 이미지가 20 번 회전하면 매우 손실됩니다.

이미지 데이터의 크기를 줄이기 위해 양자화 한 후 JPEG 압축의 최종 무손실 단계 인 엔트로피 코딩 이 원인 일 가능성이 높습니다 .

JPEG 이미지가 손실없이 회전하는 경우이 최종 무손실 인코딩 레이어를 취소하고 압축을 푼 DCT 계수를 섞은 다음 섞은 계수를 다시 엔트로피 코딩해야합니다. 엔트로피 코딩 층의 효율은 이미지를 회전시키는 각각의 블록 내의 DCT 계수의 순서에 의존하기 때문에, 회전 된 이미지 파일이 원본보다 몇 퍼센트 작거나 클 수 있다는 것은 놀라운 일이 아니다.

엔트로피 코딩 단계가 수행 될 수있는 몇 가지 다른 방법이 있기 때문에, 정확히 동일한 JPEG 이미지의 파일 크기는 인코딩을 수행하는 소프트웨어에 따라 달라질 수 있습니다. 엔코더 간의 잠재적 인 차이점 중 일부는 다음과 같습니다.

• 허프만 인코딩 (단순하고 표준적인) 대 산술 인코딩 (희소하지만 잠재적으로 더 효율적이며 특허를 받았던)의 선택;
• 순차적 (각 8x8 픽셀 블록은 한 번에 하나씩 인코딩 됨) vs. 점진적 (모든 블록의 저주파 성분은 고주파수 성분, 일반적으로 약간 더 소형화되기 전에 부호화 됨) 인코딩 순서의 선택;
• 각 이미지에 최적화 된 표준 Huffman 심볼 테이블 (빠르고 단순하며 매우 작은 이미지에 더 효율적일 수 있음) 대 각 이미지에 최적화 된 사용자 정의 테이블 (일반적으로 큰 이미지에 더 효율적이고 인코딩 속도가 느리고 복잡함)을 선택할 수 있습니다.
• 사용자 정의 허프만 테이블을 사용하는 경우 다른 인코더가 동일한 이미지 데이터에 대해 다른 테이블을 생성 할 수 있습니다.
• 데이터 스트림에 재시작 마커를 포함할지 여부 및시기와 같은 인코딩 프로세스 자체의 다양한 하위 레벨 세부 사항도 인코더마다 다를 수 있습니다.

또한, "JPEG 파일"사용자는 일반적으로 JFIF 또는 Exif 컨테이너에 래핑 된 JPEG 압축 이미지 데이터를 실제로 포함 합니다.이 이미지 데이터는 하나 이상의 메타 데이터 블록과 이미지 데이터를 결합하고 고유 한 합병증을 발생시킵니다. 이미지를 회전시키는 소프트웨어가 실제로 JFIF / Exif 메타 데이터를 실질적으로 변경하지 않더라도 단순히 데이터를 다시 정렬하면 파일 크기에 몇 바이트 영향을 줄 수 있습니다.

특히, JFIF / Exif 메타 데이터에는 전체 크기 이미지의 하나 이상의 썸네일 이 포함되어있을 수 있으며 이미지를 회전시키는 소프트웨어는 전체 이미지의 새로운 방향과 일치하도록 썸네일을 실제로 재생성 (또는 무손실 회전)해야합니다. 크기 이미지. 이것만으로도 관찰 된 크기 차이를 쉽게 설명 할 수 있습니다.

계속해서 실험을 반복하여 무슨 일이 일어나고 있는지 알아낼 수 있는지 확인했습니다.

순서

김프의 "솔리드 노이즈"필터 (필터> 렌더> 클라우드> 솔리드 노이즈 ...)를 사용하여 임의의 256 x 256 픽셀 RGB 이미지를 기본 설정 (아래 그림 참조)을 사용하여 생성했습니다.

그리고 결과 :

그런 다음 기본 설정을 사용하여 이미지를 JPEG로 저장했습니다.

그런 다음 이미지를 Windows로 전송하고 파일 탐색기에서 이미지를 마우스 오른쪽 단추로 클릭 하고 메뉴에서 미리보기 를 선택하여 Windows 사진 뷰어로 이미지를 열었습니다 . 그런 다음 하단의 버튼을 사용하여 이미지를 회전시키고 화살표 키를 사용하여 다음 이미지로 이동하여 이미지를 저장했습니다.

아래의 각 테스트마다 원본 이미지의 복사본으로 시작하여 저장하기 전에 해당 횟수만큼 회전 (회전 버튼 클릭)했습니다. 크기 조정 ( ls -l -r) 은 다음과 같습니다 .

                    size in bytes    last-modified date 
                          VVVVV        VVVVV
-rwxrwx--- 1 root vboxsf   6258 Nov  8 11:24 original.jpg
-rwxrwx--- 1 root vboxsf  23645 Nov  8 11:30 cw.jpg
-rwxrwx--- 1 root vboxsf  23636 Nov  8 11:30 cw-cw.jpg
-rwxrwx--- 1 root vboxsf  23649 Nov  8 11:30 cw-cw-cw.jpg
-rwxrwx--- 1 root vboxsf   6258 Nov  8 11:27 cw-cw-cw-cw.jpg
-rwxrwx--- 1 root vboxsf  23649 Nov  8 11:31 cw-cw-cw-cw-cw.jpg
-rwxrwx--- 1 root vboxsf  23649 Nov  8 11:29 ccw.jpg
-rwxrwx--- 1 root vboxsf  23636 Nov  8 11:29 ccw-ccw.jpg
-rwxrwx--- 1 root vboxsf  23645 Nov  8 11:29 ccw-ccw-ccw.jpg
-rwxrwx--- 1 root vboxsf   6258 Nov  8 11:27 ccw-ccw-ccw-ccw.jpg
-rwxrwx--- 1 root vboxsf  23649 Nov  8 11:30 ccw-ccw-ccw-ccw-ccw.jpg

즉각적인 관찰

• WPV (Windows 사진 뷰어)는 크기를 크게 늘립니다. 이 테스트에서 증가량은 약 4 배입니다!
• 모든 새로운 이미지는 거의 같은 크기로 증가하지만 동일하지는 않습니다.
• WPV는 이미지를 360 도의 배수로 회전 할 때 이미지를 다시 인코딩하거나 다시 저장하지 않습니다. (타임 스탬프 11:27은 파일이 처음 복사 된 시점입니다.)

cmp -l동일한 내용을 가져야하는 파일을 사용 하면 파일의 차이점을 알 수 있습니다.

robert@unity ../jpeg-rotate-test % cmp -l cw.jpg ccw-ccw-ccw.jpg
 2223  63  62
 2224  60  71
 2226  60  64
 2227  60  66
robert@unity ../jpeg-rotate-test % cmp -l cw-cw.jpg ccw-ccw.jpg
 2223  63  62
 2224  60  71
 2226  60  64
 2227  62  64
robert@unity ..jpeg-rotate-test % cmp -l ccw.jpg cw-cw-cw.jpg
 2223  62  63
 2224  71  60
 2226  64  60
 2227  61  64
robert@unity ../jpeg-rotate-test % cmp -l cw.jpg cw-cw-cw-cw-cw.jpg
 2221  60  61
 2223  63  61
 2224  60  66
 2226  60  61
 2227  60  61
robert@unity ../jpeg-rotate-test % cmp -l ccw.jpg ccw-ccw-ccw-ccw-ccw.jpg
 2223  62  63
 2224  71  60
 2226  64  65
 2227  61  64

이 파일들은 단지 4 바이트 (실제로 타임 스탬프) 만 다릅니다. 이는 WPV가 매번 같은 일을한다는 것을 의미합니다. 이제 우리는 그것이 무엇인지 알아 내면됩니다.

자세한 관찰

이를 위해 JPEGsnoop 을 사용 하여 이미지의 내용이 정확히 무엇인지 확인했습니다.

출력이 상당히 길기 때문에 gist로 연결했습니다 . 차이점에 대한 요약은 다음과 같습니다.

• 김프는 메타 데이터에 APP0(JFIF) 및 COM(코멘트) 세그먼트 만 사용합니다 . WPV는 APP0세그먼트를 건드리지 않지만 주석에 널 바이트를 흥미롭게 추가하여 널로 종료합니다.

• WPV는 APP1Exif와 XMP 메타 데이터 인 두 개의 세그먼트를 추가합니다 . 이 세그먼트는 각각 4286 및 12726 바이트입니다. 그들은 함께 파일 크기의 거의 모든 증가를 설명합니다.

• 김프는 프로그레시브 JPEG를, WPV는베이스 라인 (비 프로그레시브) JPEG를 생성합니다. 이러한 이유로 김프의 이미지에는 여러 스캔 세그먼트가 있지만 WPV 이미지에는 하나의 스캔 세그먼트 만 있습니다. 내 경험상 프로그레시브 이미지는 때때로 약간 작습니다.

• 김프는 1 × 1 크로마 서브 샘플링을 사용했고 WPV는 2 × 2 서브 샘플링을 사용했습니다. 이것은 WPV가 흑백 이미지임을 감지 할 수 없다면 "진정한"무손실 회전을 사용하지 않는다고 믿게합니다.

이 문제를 해결하기 위해 두 번째 테스트를 실행했습니다.

순서

첫 번째 테스트와 비슷한 단계를 수행했습니다. 다음 설정을 사용하여 RGB 노이즈 필터 (필터> 코> RGB 코 ...)를 사용하여 임의 256 × 256 RGB 이미지를 만들었습니다.

결과는 다음과 같습니다.

다음 설정을 사용하여 파일을 JPEG로 내보냈습니다.

프로그레시브 가 꺼져 있지만 서브 샘플링 은 여전히 ​​4 : 4 : 4 ( 1x1 서브 샘플링의 다른 이름)로 설정되어 있습니다. 품질이 98로 향상되었습니다.

이미지를 복사하고 사본을 시계 방향으로 회전했습니다. 그런 다음 회전 된 버전을 복사하고 해당 사본을 시계 반대 방향으로 회전하여 원본과 WPV 처리 사본 간의 품질을 직접 비교할 수 있습니다.

결과

-rwxrwx--- 1 root vboxsf 159774 Nov  8 16:21 original-random.jpg
-rwxrwx--- 1 root vboxsf 222404 Nov  8 16:24 cw-random.jpg
-rwxrwx--- 1 root vboxsf 222467 Nov  8 16:24 cw-ccw-random.jpg

이 시간의 증가는 상대적인 측면 (약 40 %)에서 더 작지만 절대 증가는 62kB 정도입니다. 이는 WMV가 덜 효율적인 인코딩을 사용하고 있음을 나타냅니다.

ImageMagick 을 사용하여 두 이미지를 비교 하겠습니다 .

robert@unity ../jpeg-rotate-test % compare -verbose -metric AE original-random.jpg cw-ccw-random.jpg null:
original-random.jpg JPEG 256x256 256x256+0+0 8-bit sRGB 160KB 0.000u 0:00.009
cw-ccw-random.jpg JPEG 256x256 256x256+0+0 8-bit sRGB 222KB 0.010u 0:00.010
Image: original-random.jpg
  Channel distortion: AE
    red: 0
    green: 0
    blue: 0
    all: 0
original-random.jpg=> JPEG 256x256 256x256+0+0 8-bit sRGB 0.050u 0:00.020

있다 다른 제로 픽셀 원본과 회전 사본 사이는. 따라서 WPV가 "실제"무손실 회전을 사용하지 않더라도 충분한 작업을 수행하고 있습니다. 나는 무슨 일이 일어나고 있는지 알고 있으며 JPEG 압축의 수학에 약간의 전환을 설명 할 것이라고 생각합니다.

JPEG 압축 알고리즘은 이미지를 8 × 8 픽셀 블록으로 나눕니다. 이 블록들 각각은 이산 코사인 변환 (DCT) 을 받는다 . 결과 DCT 계수는 블록을 다른 주파수 파의 합으로 설명합니다. 그런 다음이 알고리즘은 노이즈와 매우 작은 세부 사항에 해당하는 고주파 파의 일부 정보를 "버립니다". 디코딩 과정은 DCT를 반대로하여 저장된 파동을 합쳐서 블록을 되 찾는다.

실제로 변환을 취소하고 다시 실행하지 않고 DCT "파동"을 회전 할 수 있습니다 (기본적으로 모든 수평 파를 수직 파로 또는 그 반대로 전환). WPV에서 내가 생각하는 것은 이미지가 실제로 디코딩되고 회전 된 다음 다시 인코딩된다는 것입니다. 재 인코딩 과정에서 이미지의 크기는 두 차원 모두에서 8의 배수이기 때문에 각각의 새로운 블록은 원래 블록 중 하나에 해당합니다. 중요하게, 각 블록에는 고주파수 성분이 없기 때문에 알고리즘은 어떠한 정보도 버리지 않으며 "진정한"무손실 회전이 가질 수있는 올바른 DCT 성분을 정확하게 찾습니다.

마지막으로 JPEG 파일의 구성 요소를 다시 살펴 보겠습니다. 결과는 다시 요점으로 연결됩니다 . 두 비교 :

• WPV 이미지에는 추가 4286 + 2 바이트의 Exif 메타 데이터, 주석에 1 개의 추가 바이트 및 12,726 + 2 바이트의 XMP 메타 데이터가 포함되어 있습니다. 총 17,017 바이트의 추가 메타 데이터입니다. 그 데이터는 무엇에 사용됩니까? 나는 신뢰할 수있는 16 진수 편집기와 관련 표준 사본을 사용하여 파일을 들여다 보았습니다.

  • Exif 메타 데이터는 많은 태그를 포함하는 TIFF 이미지와 같이 구조화되어 있습니다 ( 더 복잡한 방법이 있지만 바로 건너 뜁니다). Exif 세그먼트의 대부분의 바이트는 태그 번호 EA1C(십진수 59,932)의 두 개의 동일한 태그에 포함됩니다 . 그 태그 번호는 내가 찾을 수있는 곳 어디에도 문서화되어 있지 않습니다. 두 태그 모두 "정의되지 않은"유형의 2060 바이트를 포함하며 처음 6 개 ( 1C EA 00 00 00 08)를 제외한 모두 널 바이트 입니다. 이 태그가 무엇인지, 왜 태그가 2 개 있는지, 왜 각각 2kB가되어야하는지 모르겠습니다.

  • XMP 메타 데이터는 실제로 이름 공간이 있고 긴 UUID가 포함 된 전체 임베디드 XML 문서이며 WPV 버전 문자열 (Exif 메타 데이터에 이미 있음) 만 포함합니다. 그러나 약 400 바이트 만 차지합니다. 세그먼트의 나머지 부분은 100 개의 공백을 122 번 반복 한 다음 줄 바꿈 입니다. 총 12,000 바이트가 넘는 공간이 낭비되었습니다.

• 이전 테스트와 마찬가지로 김프와 WPV는 동일한 DCT 양자화 테이블을 사용합니다. 이것은 그들이 정확히 동일한 DCT 계수를 계산해야 함을 의미하므로 이미지가 정확히 동일합니다. WPV가 동일한 양자화 테이블을 사용하고 있는지 또는 입력에서 테이블을 복사하는지 확실하지 않습니다.

• 이전 테스트와 달리 이번에는 WPV에서 1x1 서브 샘플링을 사용하므로 실제로 이것이 컬러 이미지임을 감지 할 수 있습니다 (또는 이미지를 손실없이 다시 인코딩하려면 최소한 더 높은 샘플이 필요함).

• 김프와 WPV는 다른 허프만 테이블 (엔트로피 코딩 단계의 일부)을 사용합니다. WPV에 대한 테이블은 총 279 바이트로 더 크며, 어떤 경우에는 7 배 많은 코드가 포함됩니다.

  JPEGsnoop의 통계를 보면 이러한 코드 중 일부가 거의 사용되지 않음을 알 수 있습니다. 예를 들어, ID: 1, Class: AC표에서 정의 된 119 16 비트 코드 중 23 개만 실제로 사용됩니다. 실제 스캔 세그먼트는 WPV 버전에서 28.5 % 더 큽니다.

요약

• WPV는 "실제"무손실 회전을 수행하지 않을 수 있지만 실제로는 무손실 회전 인 것 같습니다.

• 여분의 크기는 부분적으로 고정 된 양의 메타 데이터와 부분적으로 덜 효율적인 엔트로피 코딩에 기인한다.

버전 정보 :

• OS (Linux) ( uname -a) :

  Linux unity 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u1 (2016-09-03) x86_64 GNU/Linux
  

• OS (Windows) :

  

• 김프 (Linux) : 2.8.14 (패키지 gimp, 버전 2.8.14-1+deb8u1)

  

• Window Photo Viewer (이미지 메타 데이터에 따름) :

  Microsoft Windows Photo Viewer 10.0.10586.0
  

^{편집 :이 대답은 파일 크기가 약 9 KiB (256x256 이미지의 경우 9055 바이트, 512x512 이미지의 경우 9612 KiB) 증가 함을 알기 전에 게시되었습니다.}

아마 이미지를 처음 회전했을 때 Windows Picture Viewer는 다음 중 하나를 수행했습니다.

1. 원본 JPEG 이미지에없는 EXIF ​​태그 (아마도 방향 태그)를 추가했습니다.
2. 이미 존재하는 태그 (아마도 소프트웨어 처리 또는 이미지 소프트웨어 태그)에 정보를 수정 / 추가했습니다.

추가 EXIF ​​태그 및 / 또는 기존 태그에 대한 추가 데이터로 인해 파일 크기가 증가했습니다.

WPV가 추가 / 수정했을 모든 태그 및 / 또는 태그 데이터가 이미 존재했기 때문에 후속 회전은 파일 크기를 늘리지 않았습니다. 방향 태그 값만 변경되었습니다 (날짜 / 시간 태그 값도 가능).

편집 :이 설명이 파일에서 약 9 KiB의 추가 데이터를 설명 할 수 없다는 것이 거의 확실합니다. 또한, 크기 증가에 대한 다른 이유가 없다면,이 설명은 크기 증가가 다소 일정 할 것으로 예상 할 것이다 (숫자 데이터의 문자열 표현들 사이의 모듈러스 길이 차이, 아마도 몇 바이트). 그것은 분명히 여기서 일어나는 일이 아니며, 적어도 완전한 설명이 아닙니다.

jpeg en / decoder를 리버스 엔지니어링하지 않으면 확실히 말할 수 없습니다. 실제로 많은 JPEG 표준이 있으며 대중의 믿음과는 달리 모든 인코딩을 다시 인코딩하지 않고 수정할 수는 없습니다.

첫 번째 저장 은 선호하는 jpeg 풍미로 손실 다시 쓰기 일 수 있으며 후속 회전은 간단한 메타 데이터 조정 또는 DCT 테이블에서 직접 조작 (일부 인코딩 체계에서 가능)입니다.

파일 크기의 증가에는 일부 추가 메타 데이터가 포함될 수도 있지만 9k는 많이 보이지만 가능합니다. 김프의 출력에 포함되지 않은 썸네일을 추가하여 증가를 설명 할 수도 있습니다. WPV 이전 및 이후에 파일에서 직접 추가 정보를 얻을 수 있습니다.

어쨌든 jpeg로 느슨하게 작업하는 것은 특정 이미지 크기에서만 유용하기 때문에 실제로는 어리석은 일입니다. 모든 디코더와 인코더가 동일하지는 않으며 편집기가 jpeg 내용으로 직접 작업해야합니다. 사실 ... 지금 그렇게한다고해서 앞으로도 계속 될 것이라는 의미는 아닙니다.

더 나은 방법은 무손실 형식으로 작업하고 고통을 완전히 피하는 것입니다.

이미지 크기가 블록 크기의 배수 (일반적으로 [/ always?] 8) 인 경우 경계 아티팩트를 도입하지 않고 JPEG 손실없이 만 회전 할 수 있습니다. 관련된 내용에 대한 자세한 내용 은 jpegtran 매뉴얼 페이지를 참조하십시오 (죄송합니다. 정규적인 링크가 없습니다. 찾으면 자유롭게 편집하십시오).

조옮김 변환에는 이미지
크기 에 대한 제한이 없습니다 . 이미지 크기가 iMCU 크기의 배수가 아닌 경우 (보통 8 또는 16 픽셀) 다른 변환은 원하는 방식으로 DCT 계수 데이터의 전체 블록 만 변환 할 수 있기 때문에 다소 이상하게 작동합니다.

홀수 크기 이미지를 변환 할 때 jpegtran의 기본 동작 은 변환 세트의
정확한 가역성과 수학적
일관성 을 유지하도록 설계되었습니다 . 언급 한 바와 같이, 조옮김은
전체 이미지 영역을 뒤집을 수 있습니다. 수평 미러링은 오른쪽 가장자리의 일부 iMCU 열을 그대로 유지하지만 이미지의 모든 행을 뒤집을 수 있습니다. 마찬가지로 수직 미러링은 하단 가장자리의 일부 iMCU 행을 그대로 유지하지만 모든 열을 뒤집을 수는 있습니다. 다른 변환은 전치 및 뒤집기 시퀀스로 구축 될 수 있습니다. 일관성을 위해, 에지 픽셀에 대한 이들의 동작은 대응하는 전치 및 플립 시퀀스의 최종 결과와 동일하게 정의된다.

실제로 사용하려면 변환 된 이미지
의
오른쪽 및 / 또는 아래쪽 가장자리를 따라 이상한 모양의 스트립이있는 것보다 변형 할 수없는 가장자리 픽셀 을 삭제하는 것이 좋습니다 . 이렇게하려면 -trim 스위치를 추가하십시오.

이미지 크기가 실제로 무손실 회전을 수행하지 않고 8의 배수가 아닌 경우 무손실 동작을 시뮬레이션하기 위해 압축 해제 및 초 고품질 재 압축을 수행하여 Windows 사진 뷰어가이 문제를 피하고 있다고 생각합니다. 좋은 유틸리티는 전체 이미지의 품질을 떨어 뜨리고 파일 크기를 늘리기보다는 실제로 무손실, 아티팩트 및 모두를 수행하거나 몇 픽셀을 떨어 뜨릴 것입니다.

나는 명확한 대답은 없지만 왜 그런 일이 있었는지에 대한 가능한 이론을 가지고 있습니다. 일부 파일 형식은 해당 파일 형식의 이미지에 대해 서로 다른 두 가지 코드가 서로 다른 이미지를 생성하지는 않습니다. 예를 들어 PNG 파일 형식은 투명한 배경을 허용하지만 투명한 배경을 가진 이미지와 같은 배경이 흰색 인 것을 제외하고는 동일한 이미지를 표시하는 방식으로 작동합니다. 이미지 파일은 픽셀 당 3 바이트 미만의 메모리를 차지하는 경우 압축되었다고합니다. 투명한 배경을 가진 것을 제외하고 두 개의 PNG 파일이 정확히 동일한 이미지를 생성하지 않는다고 생각합니다. 이미지를 PNG로 저장하면 이미지가 원본 이미지를 생성하는 코드로 변환되며 각 픽셀이 2 ^ 24 색상의 임의 색상 인 이미지와 같은 매우 특이한 이미지는 제외하고, 이 코드는 픽셀 당 3 바이트보다 적은 메모리를 사용하므로 PNG는 손실이없는 압축으로 저장됩니다. 한편, 메모리를 절약하기 위해 JPEG 이미지 파일의 코드에 의해 특정 이미지 만 생성 될 수있다. JPEG 파일 형식이 두 개 이상있을 수 있으며 해당 파일 형식의 서로 다른 두 이미지가 정확히 동일한 이미지를 생성 할 수 있다는 속성이 있는지 모르겠습니다. 나는 당신이 방금 이미지를 회전 한 다음 JPEG로 저장했다고 가정하고 그것이 내가 사실인지 알지 못하는 가정이라는 가정하에 일어난 일에 대해 설명 할 것입니다. 회전하고 저장하기 전과 똑같은 이미지 파일 코드를 되돌릴 수있는 방법이 있다면 회전은 손실이 없습니다. 실제로 무손실 회전을 수행 한 것이 정확하지 않을 수 있습니다. 정말 무손실이라면

이것 뒤에 이유는 몇 가지

이미지가 코딩되고 압축되는 방식은 압축 알고리즘으로 인해 단순히 크기를 변경합니다. 비트 맵으로 저장 한 다음 회전하여 테스트 할 수 있습니다. 해당 형식 또는 모든 원시 형식에서 크기는 동일하게 유지되어야합니다. 그렇지 않은 경우 이미지를 저장하는 프로그램은 새로운 데이터를 추가하거나 메타 데이터 등을 추가 할 수 있습니다.

그런데 왜 JPEG를 20 번 돌리고 있습니까?

이미지 압축 방식 때문에 . PNG 또는 JPG와 같은 형식은 일반적으로 회전 후 파일 크기를 유지하지 않습니다.

컴프레서에게 회전 된 이미지는 다른 이미지 일뿐입니다. 압축 휴리스틱 작동 방식으로 인해 회전 된 이미지를 동일하게 압축 할 것이라는 보장은 없습니다 .

물론 압축이 손실이없는 경우 이미지를 4 번 4 번 회전하면 이미지가 다시 동일하게됩니다 (원래로 기울어 질 때까지 회전 됨). 그렇지 않은 경우 다시 동일한 압축 크기가되어야합니다. 다음 이유 중 하나 때문입니다 .

• 메타 데이터 추가 : 프로그램이 어떤 이유로 텍스트를 추가했습니다.
• 압축기 변경 : 프로그램은 변경 사항이 없으면 이미지를 원본으로 다시 저장하도록 선택할 수 있지만 변경 사항 (4도 회전 90도)을 적용하면 자체 이미지를 사용하여 이미지를 다시 압축하기로 결정할 수 있습니다 압축기 (프로그램은 더 이상 여전히 동일한 이미지임을 알지 못합니다).
• 일반적으로 동일한 압축기 (libPNG 또는 libJPG)는 다른 구현, 동일한 라이브러리의 다른 버전 및 다른 압축 매개 변수를 사용하여 매우 다른 결과를 산출합니다 (운영 체제와 컴파일러는 때때로 차이를 만듭니다).

이미지 압축은 이미지를 4x4 또는 다른 크기의 청크로 압축하여 작동합니다. 일반적으로 컴프레서는 회전 된 이미지를 다른 이미지로 인식하지만 압축 된 픽셀 청크는 선형 분해이므로 이미지의 청크가 동일하면 선형 분해 매트릭스를 효과적으로 동일하게 유지하면서 조옮김 / 미러링 할 수 있습니다. 품질:

이것은 기능별 로 구현되어야 하며 첫 번째 회전에서 size => 초기 증가에 대해 설명합니다. 이미지를 회전 가능한 덩어리로 압축하려고합니다.

• 그렇지 않으면 이미지 품질이 저하됩니다.

• 성공하면 크기를 한 번만 늘리면 모든 회전이 동일한 품질을 유지합니다.

• 이 작업은 이미지가 동일한 청크로 이루어진 경우에만 성공합니다. (이미지 크기는 청크 크기의 배수입니다).

scottbb 답변이 잘못되었으며 간단한 테스트를 수행 할 수 있습니다.

• 원본 이미지 열기 : 스크린 샷
• WPV로 이미지를 4 번 회전 : 스크린 샷
• 2 개의 스크린 샷 비교

이미지가 변경된 것을 볼 수 있습니다 (첫 번째 회전시 다시 압축 됨). 그러나 해당 변경 시간이 제한되어 있으므로 품질 손실없이 이미지를 다시 회전 할 수 있습니다 (이미지의 크기가 8의 배수 인 경우)

OP에 직접 답변하려면 :

나는 그것이 무손실 회전한다는 것을 안다

무손실 회전이 아니라 최소한 한 번 품질을 잃습니다 (첫 번째 회전시 : 회전 할 수있는 방식으로 압축해야하기 때문에).