하드 디스크 공간을 절약하는 이상한 방법에 대해

또 다른 사용자는 하드 드라이브에 새 데이터를 쓰고 싶어하지만 이를 수행할 여유 공간이 충분하지 않습니다. 또한 "모든 것이 매우 중요하고 필요하기 때문에" 아무것도 삭제하고 싶지 않습니다. 그리고 우리는 그것으로 무엇을 해야 합니까?

아무도 이런 문제가 없습니다. 하드 드라이브에는 테라바이트급의 정보가 있으며 이 양은 줄어들지 않습니다. 하지만 얼마나 독특합니까? 결국 모든 파일은 특정 길이의 비트 집합일 뿐이며 새 파일은 이미 저장된 파일과 크게 다르지 않을 가능성이 높습니다.

하드 드라이브에 이미 저장된 정보를 검색하는 것은 실패는 아니지만 적어도 효과적인 작업이 아니라는 것은 분명합니다. 반면에 차이가 작다면 조금 조정하면 되는데...

TL;DR - JPEG 파일을 사용하여 데이터를 최적화하는 이상한 방법에 대해 이야기하려는 두 번째 시도가 이제 더 이해하기 쉬운 형식으로 제공됩니다.

비트와 차이에 대하여

완전히 무작위로 두 개의 데이터 조각을 취하면 평균적으로 포함된 비트의 절반이 일치합니다. 실제로 각 쌍('00, 01, 10, 11')에 대해 가능한 레이아웃 중 정확히 절반은 동일한 값을 가지며 여기에서는 모든 것이 간단합니다.

하지만 물론 두 개의 파일을 가져와서 하나를 두 번째 파일에 맞추면 그 중 하나가 손실됩니다. 변경 사항을 저장하면 간단히 재창조할 수 있습니다. 델타 인코딩, 일반적으로 동일한 목적으로 사용되지는 않지만 우리 없이도 완벽하게 존재합니다. 더 작은 시퀀스를 더 큰 시퀀스에 삽입하려고 시도할 수 있지만 그럼에도 불구하고 모든 것에 무모하게 사용하면 중요한 데이터 세그먼트를 잃을 위험이 있습니다.

그러면 무엇과 무엇 사이의 차이가 없어질 수 있습니까? 즉, 사용자가 작성한 새 파일은 단지 일련의 비트일 뿐이며 자체적으로는 아무것도 할 수 없습니다. 그런 다음 하드 드라이브에서 차이를 저장하지 않고도 변경할 수 있는 비트를 찾아서 심각한 결과 없이 손실을 견딜 수 있어야 합니다. 그리고 FS 자체의 파일뿐만 아니라 그 안에 있는 덜 민감한 정보도 변경하는 것이 합리적입니다. 하지만 어느 것이, 어떻게?

피팅 방법

손실이 있는 압축 파일이 구출됩니다. 이러한 모든 jpeg, mp3 및 기타 파일에는 비록 손실이 있는 압축이기는 하지만 안전하게 변경할 수 있는 많은 비트가 포함되어 있습니다. 다양한 인코딩 단계에서 구성 요소를 눈에 띄지 않게 수정하는 고급 기술을 사용하는 것이 가능합니다. 기다리다. 고급 기술... 눈에 띄지 않는 수정... 조금씩 다른 부분으로... 거의 비슷합니다. 스테가노그래피!

실제로 하나의 정보를 다른 정보에 삽입하는 것은 그녀의 방법을 연상시킵니다. 나는 또한 인간의 감각에 일어난 변화를 감지할 수 없다는 사실에 깊은 인상을 받았습니다. 경로가 갈라지는 곳은 비밀입니다. 우리의 임무는 사용자가 하드 드라이브에 추가 정보를 입력하는 것입니다. 이는 사용자에게 해를 끼칠 뿐입니다. 그는 다시 잊어버릴 것이다.

따라서 사용할 수는 있지만 몇 가지 수정이 필요합니다. 그런 다음 기존 방법 중 하나와 일반적인 파일 형식의 예를 사용하여 설명하고 보여 드리겠습니다.

자칼 소개

정말 짜면 세상에서 가장 압축하기 쉬운 것입니다. 물론 우리는 JPEG 파일에 대해 이야기하고 있습니다. 데이터를 삽입하기 위한 수많은 도구와 기존 방법이 있을 뿐만 아니라 지구상에서 가장 인기 있는 그래픽 형식입니다.

그러나 개 사육에 참여하지 않으려면 이 형식의 파일에서 활동 분야를 제한해야 합니다. 과도한 압축으로 인해 나타나는 단색 사각형을 좋아하는 사람은 아무도 없으므로 이미 압축된 파일로만 작업해야 합니다. 녹음 방지. 보다 구체적으로, 데이터 손실을 담당하는 작업(DCT 및 양자화) 후에 남아 있는 정수 계수를 사용하면 인코딩 체계에 완벽하게 표시됩니다(Bauman National Library의 wiki 덕분에).

JPEG 파일을 최적화하는 방법에는 여러 가지가 있습니다. 무손실 최적화(jpegtran)가 있고 최적화가 있습니다."무손실', 실제로 다른 것에 기여하지만 우리는 그것에 관심이 없습니다. 결국 사용자가 여유 디스크 공간을 늘리기 위해 한 정보를 다른 정보에 삽입할 준비가 되었다면 그는 오래 전에 이미지를 최적화했거나 품질 저하가 두려워 이 작업을 전혀 원하지 않는 것입니다.

F5

전체 알고리즘 제품군이 이러한 조건에 적합하며 이에 익숙해질 수 있습니다. 이 좋은 발표에. 그 중 가장 발전된 것은 알고리즘이다. F5 인간의 눈은 변화에 가장 덜 민감하기 때문에 밝기 구성 요소의 계수를 사용하여 작업하는 Andreas Westfeld의 글입니다. 또한, 매트릭스 인코딩을 기반으로 한 임베딩 기술을 사용하므로 동일한 양의 정보를 임베딩할 때 사용되는 컨테이너의 크기가 클수록 변경 사항이 적습니다.

변경 사항 자체는 특정 조건(즉, 항상 그런 것은 아님)에서 계수의 절대값을 5씩 줄이는 것으로 요약됩니다. 이를 통해 FXNUMX를 사용하여 하드 드라이브의 데이터 저장을 최적화할 수 있습니다. 요점은 이러한 변경 후의 계수는 JPEG 값의 통계적 분포로 인해 허프만 인코딩 후 더 적은 비트를 차지할 가능성이 높으며 RLE를 사용하여 인코딩할 때 새로운 XNUMX이 이득을 제공한다는 것입니다.

필요한 수정은 리소스와 실행 시간을 절약하는 비밀 유지(비밀번호 재배열)를 담당하는 부분을 제거하고 한 번에 하나씩이 아닌 많은 파일을 작업할 수 있는 메커니즘을 추가하는 것으로 요약됩니다. 독자는 변경 프로세스에 대해 더 자세히 관심을 가질 것 같지 않으므로 구현에 대한 설명으로 넘어가겠습니다.

하이 테크

이 접근 방식이 어떻게 작동하는지 보여주기 위해 순수 C로 메서드를 구현하고 실행 속도와 메모리 측면에서 여러 가지 최적화를 수행했습니다(DCT 이전에도 압축 없이 이러한 그림의 무게가 얼마나 되는지 상상할 수 없습니다). 라이브러리 조합을 사용하여 크로스 플랫폼 달성 libjpeg, PCRE и 작은디르, 우리는 그들에게 감사드립니다. 이 모든 것은 'make'에 의해 통합되므로 Windows 사용자는 평가를 위해 Cygwin을 직접 설치하거나 Visual Studio 및 라이브러리를 스스로 처리하기를 원합니다.

구현은 콘솔 유틸리티 및 라이브러리 형태로 제공됩니다. 관심 있는 분들은 Github 저장소의 추가 정보에서 후자를 사용하는 방법에 대해 자세히 알아볼 수 있습니다. 이 링크는 게시물 끝에 첨부하겠습니다.

사용 방법은?

주의하여. 패키징에 사용되는 이미지는 지정된 루트 디렉터리에서 정규식을 사용하여 검색하여 선택됩니다. 완료되면 파일을 경계 내에서 마음대로 이동하고, 이름을 바꾸고, 복사할 수 있으며, 파일 및 운영 체제 등을 변경할 수 있습니다. 그러나 매우 주의해야 하며 어떤 방식으로든 즉각적인 내용을 변경하지 않아야 합니다. 단 XNUMX비트의 값도 손실되면 정보를 복구하는 것이 불가능해질 수 있습니다.

완료되면 유틸리티는 사용된 이미지에 대한 데이터를 포함하여 압축 풀기에 필요한 모든 정보가 포함된 특수 아카이브 파일을 남깁니다. 그 자체의 무게는 약 XNUMXKB이며 점유된 디스크 공간에 큰 영향을 미치지 않습니다.

'-a' 플래그를 사용하여 가능한 용량을 분석할 수 있습니다: './f5ar -a [검색 폴더] [Perl 호환 정규식]'. 패킹은 './f5ar -p [검색 폴더] [Perl 호환 정규식] [패킹 파일] [아카이브 이름]' 명령으로 압축을 풀고, './f5ar -u [아카이브 파일] [복구된 파일 이름]으로 압축을 푼다. ]' .

작업 시연

이 방법의 효과를 보여주기 위해 서비스에서 완전 무료로 제공되는 225장의 개 사진 모음을 업로드했습니다. Unsplash 그리고 문서에서 두 번째 권의 45미터에 달하는 큰 PDF를 발견했습니다. 프로그래밍 기술 크누타.

순서는 매우 간단합니다.

$ du -sh knuth.pdf dogs/
44M knuth.pdf
633M dogs/

$ ./f5ar -p dogs/ .*jpg knuth.pdf dogs.f5ar
Reading compressing file... ok
Initializing the archive... ok
Analysing library capacity... done in 17.0s
Detected somewhat guaranteed capacity of 48439359 bytes
Detected possible capacity of upto 102618787 bytes
Compressing... done in 39.4s
Saving the archive... ok

$ ./f5ar -u dogs/dogs.f5ar knuth_unpacked.pdf
Initializing the archive... ok
Reading the archive file... ok
Filling the archive with files... done in 1.4s
Decompressing... done in 21.0s
Writing extracted data... ok

$ sha1sum knuth.pdf knuth_unpacked.pdf
5bd1f496d2e45e382f33959eae5ab15da12cd666 knuth.pdf
5bd1f496d2e45e382f33959eae5ab15da12cd666 knuth_unpacked.pdf

$ du -sh dogs/
551M dogs/

팬들을 위한 스크린샷

압축을 푼 파일은 계속해서 읽을 수 있고 읽어야 합니다.

보시다시피, 원래 633 + 36 == 669MB의 하드 드라이브 데이터에서 우리는 더 즐거운 551에 이르렀습니다. 이러한 근본적인 차이는 계수 값의 감소로 설명됩니다. 후속 무손실 압축: 하나씩 줄이면 최종 파일에서 몇 바이트를 쉽게 잘라낼 수 있습니다. 그러나 이는 비록 극히 작은 규모이기는 하지만 참아야 할 데이터 손실입니다.

다행히도 눈에는 전혀 보이지 않습니다. 스포일러 아래에서(habrastorage는 대용량 파일을 처리할 수 없기 때문에) 독자는 원본에서 변경된 구성 요소의 값을 빼서 얻은 차이와 강도를 눈으로 평가할 수 있습니다. 원래의, 내부 정보와 함께, 차 (색상이 흐릴수록 블록의 차이가 작아집니다).

대신 결론

이러한 모든 어려움을 고려하면 하드 드라이브를 구입하거나 모든 것을 클라우드에 업로드하는 것이 문제에 대한 훨씬 간단한 해결책처럼 보일 수 있습니다. 하지만 우리가 지금 이렇게 멋진 시대에 살고 있다고 해도 내일 여전히 온라인에 접속하여 모든 추가 데이터를 어딘가에 업로드할 수 있다는 보장은 없습니다. 아니면 상점에 가서 천 테라바이트 하드 드라이브를 추가로 구입하세요. 하지만 언제든지 기존 주택을 사용할 수 있습니다.

-> GitHub의

출처 : habr.com