방사성 폐기장

 오늘 압축 대회에 있는 툴^[각주:1]을 보고 다녔는데, compress/decompress을 하는 속도가 빠르면서 압축률이 높은 툴을 찾아서 여기에 적는다.

 이 툴의 특징은 메모리가 많이 가지고 있다는 것. 압축 방식이 CM이라는 점이다.

 속도가 nanozip과 비슷하거나 조금 더 빠른 걸로 적혀 있다.

 실제로 비교해보니 조금 차이가 있다.

 하지만, 메모리가 크게 잡아먹는다.(유사한 효과로 할려면, nanozip보단 적게 먹는다고 적혀 있다. 필자는 실제로 못하기 때문에[필자의 환경은 M 8G이다.] 제대로 실험은 못해봤다.)

 실제로 해보니 약, 6G를 먹는다.

 단, 효율은 0.75만큼으로, 용량이 약 0.74~5 가량 줄었다.

 mcm83을 사용할 경우, 700Mb -> 500Mb가 되는걸 확인 했다.(이때, 자동으로 M 6G가량 먹었다.) 속도는 -m11로 잡았다.(mid 11이라는 뜻으로, m은 속도가 중간으로 맞춰서 처리한다는 뜻이라고 적혀 있다.)

 Nanozip은 512Mb로 했을시, 700Mb -> 550Mb가 된다.(이때, M 512M이다. 그 이상을 사용할려고하면, 오류에 의해서 작동이 안된다.)

 compress속도와 decompress속도는 nanozip과 유사했다.

 압축은 메모리를 많이 쓸 수록 효과적으로 나올 가능성이 높다.(drt|lpag9m은 윈도우 방어 장치에 의해서 실행이 되지 않았다. 바이러스가 발견했다고...)

 그래서, MCM은 메모리가 큰 컴퓨터에 압축할 경우, 효율적으로 압축이 되는걸 알 수 있었다.

 nanozip은 compress할때, decompress할때, 동일한 메모리가 사용이 된다.

 자기 컴퓨터가 메모리가 크다. 라고 할 경우 MCM에 맞을지도 모르겠다.

 단, 그냥 편하게 쓰고 싶으면, zip이 가장 낫다.

 필자는 용량 최대한 줄여서 저장하고자 하기 때문에, 하는 것일 뿐이다.

 CD의 수명, DVD의 수명, 하드 디스크의 수명등등 다양한 저장 매체의 수명과 용량에 대해서 찾아보는 도중에 paper(종이)로 저장하는 매체를 찾았다.^[각주:1]

 종이로 저장하는 매체는 종류가 많았는데, 대표적인게 QR 코드이다.

 QR코드 말고도 찾아보면, 천공카드(OMR 카드라고 하는것)과 Maxicode, DataMetrix, Aztec code, 컬러로 만든 바코드 등등이 있다.

 이번에 사용하고자하는 것은 paperbak이라는 툴이다.

 이 툴은 A4지를 가지고 500Kbyte까지 저장할 수 있다고 한다.(600dpi일 경우에, 900dpi 스캐너의 기능을 이용하면, 더 많이 저장할 수 있다는 듯이 적혀 있는 것 같다.)

 이 것의 특징은 프린터할 것의 3배의 dpi의 분할능이 되는 스캔기가 있어야된다.

 예을 들어서 200dpi로 맞춰서 출력한 인쇄물은 600dpi이상의 분해능이 가능한 스캔기야지만 문제 없이 읽어 낸다.

 그 이하의 분해능의 스캔기는 소용이 없다.

실행 시키면, 다음과 같이 나오는데, 여기서 print을 사용할 경우엔, 파일을 선택하게되고, 그 파일의 결과를 dot형태로 저장하여 출력하게 된다.

 출력된 결과물은 스캔을 통하면, 프로그램이 출력되는 형태이다.

 단, 파일명이 크면 안된다.(약 13자 이상의 파일은 인식이 안된다. exe같은 확장자가 3자인 파일일 경우엔 10자 이하의 파일을 사용해야 제대로된 파일이 나오게 된다.)

 File -> Save to bitmap을 사용할 경우엔, Bitmap 파일로 출력하게 되고, 이 파일을 이용해서 임시적으로 출력물은 예상할 수 있게 된다.

 그리고 Bitmap으로 되어있는 데이터는 무조건, 100% 인식이 돼기 때문에, 쓸만한 방식이라고 생각한다. 500kbyte을 30Mbyte로 표현한다는게 의문이긴 하지만...

 Option에 보면, dpi을 설정하는겠는데, 이것은 출력 인쇄물의 dpi이다.

 인쇄물의 3배의 dpi 분해능이 가진 스캐너야되며, 현재 600dpi 스캐너 밖에 없으므로 dpi는 200dpi로 맞췄다.

 Page setup을 이용하면, 출력되는 인쇄물의 설정이 나오게 된다.

 제일 작게하면, 전체 A4에 최대한 들어가니, 용량이 크면, 설정하는게 좋다고 생각한다.

 프린터할때도, 인쇄가 잘 되어야지만, 제대로된 인식률을 보여주니, 주의가 요해진다.

내가 최초로 했던 컴퓨터 게임...

 삼국지 CD을 정리하면서 나온 것으로

 정리하면서 얻은 겁니다.

 DOS용입니다.

 더 자세한건 DOS을 깔아서 써보도록 하겠습니다.

EXTREME.7z.001

EXTREME.7z.002

 이 글에 있는 파일은 교학사가 4월 달에 문제집을 사면 주던 CD에 영상 플레이어 장치를 압축시켜서 가지고 온거다.

 기본적으로 플래시 기반의 작동기(플래시 EXE파일)로 되어있고, CD는 그 장치를 AutoRun으로 작동시킨다.

 개발자 내용이 있지만, 현재 적혀진 주소는 다른 사이트로 변해져있는 것 같으니 그냥 올린다.

 단, 그때 들어가 있는 영상은 없다.

 CD을 전부 다 정리하고 버려야 되기에 정리 할 겸. 추억거리 읆을 겸 겸사겸사 올린다.(DVD로 옮겼으므로, 데이터 완전 파기는 아님...)

교학사 4월호.7z.001

교학사 4월호.7z.002

교학사 5-6월호.7z

 시그마 설정하는 것이다.

 압축에 들어가 있는것은

 시그마 TV Ⅱ 프로그램

 리모콘 프로그램

 시그마 TV Ⅱ 드라이버( VXD/WDM )

 DirectX 8.0a / 8.1

SIGMATVⅡ(ver 3.20).7z.001

SIGMATVⅡ(ver 3.20).7z.002

SIGMATVⅡ(ver 3.20).7z.003

SIGMATVⅡ(ver 3.20).7z.004

SIGMATVⅡ(ver 3.20).7z.005

SIGMATVⅡ(ver 3.20).7z.006

SIGMATVⅡ(ver 3.20).7z.007

SIGMATVⅡ(ver 3.20).7z.008

 요즘 Google에서 Open Source로 공개한, Brotli라는게 있다.

 이게 압축율이 좋다고 한다.

 좁플라이보다 개량되서 20% 향상되었다고 한다.^[각주:1]

 그래서 구글링을 해서 exe파일로 구해봤다.^[각주:2]

 현재, 테스트 해본 결과

 mp4파일(원본) : 297624674kbyte = 100%

 zip[반디집] : 266413245 = 89.51%

 zipx[반디집] : 41239013 = 13.85%

 brotli : 40981074 = 13.76%

 paq8o10t [8] : 40088746 = 13.47%

 이렇게 압축파일의 효율적으로 처리되는걸 알 수 있다.

 압축 속도는 zipx(LZMA) 보다 느리나, 압축율과 압축 해제속도는 상대적으로 비슷하거나 높음을 알 수 있다.

 하지만, 역시 PAQ알고리즘보단, 낮다.

 단, 속도를 비교해보니, PAQ가 시간이 엄청오래 걸리고 메모리를 많이 먹는 것 비해.

 이정도(약 1Mb차이)면, 괜찮은 것 같다.

 --2015.10.07--

 확인해보니 아직 brotli는 문제점이 있는 것 같다.

 반디집의 zipx을 이용하는 것과 brotli을 이용하는걸 비교해보니, zipx가 오히려 더 이득적인게 있다.

 그냥, 반디집의 zipx을 이용하는게 더 이득이다.(속도로나 압축률로 보나...)

Brotli.exe

 base64는 파일의 구성을 256가지가 아닌 64가지로 표현하는 방법이다.

 그래서 파일의 내용은 그대로 남아있다는 특징을 가진다.

 Decoder만 존재한다면, 해당 파일을 어떻게든 얻을 수 있다는 뜻이다.(깨져있을 수 있다는 점은 제외)

 예을 들어서 이미지 파일을 표현하고자 한다고 하자.

 보통 html로 이미지를 불러온다면, 다음같은 소스를 사용한다.

 <img src="이미지 파일 경로" />

 여기서 src을 '이미지 파일 경로'로 처리하는게 아니라.

 base64로 얻어진 파일 경로를 사용한다.(Data URI)

 그렇게하면, 서버에 파일데이터를 데이터베이스 문서파일로 넣을 수 있게 된다.

 예제:

 이미지파일을 base64로 변경시킨 값.

 base 64:

 이렇게 되어있을걸 그대로 html에 사용하면, 안된다.

 앞에 어떤 데이터인지 제대로 명시해주어야된다.

 현재 Tistory 로고는 gif구조이다.

 그래서 data:image/gif;을 앞에 붙여줘야된다.

 그리고, base64로 구성된것이다. 라고 알려 줘야된다.

 처음 부분은 이렇게 된다.

 data:image/gif;base64,R0lGODlhYAATAPcAAAAAA...

 적용하면, 다음과 같다.

 이걸 응용하여, 데이터를 주고 받거나 다운 받을 수도 있다.

 예제

 이렇게하여 데이터를 인터넷에서 다운로드, 저장, 공유를 할 수 있게 된다.

 단, 안전성에서 완벽하다. 라고 할 수는 없을 것이다.(전송 중 1bit가 오류났을 경우, 정정할 수 없으며, 오류를 탐지할 수도 없다.)

 이것만 제외하면, 파일을 글로 저장하여 쓸 수 있게 된다.

 인쇄물을 읽어서 컴퓨터에게 전송 할 수 있는 기술이 있다면, base64로 만든 인쇄물을 이용해서 보관 할 수도 있을 것이다.(그럴 필요성은 없겠지만...)

 base64란, 컴퓨터가 표현하고 있는 문자 방식(1byte로 표현할 수 있는 최댓값)은 256가지이다.

 하지만, 이런 경우를 생각해보자.

 문서(문자열로만 구성된 파일)을 보내는데, 대상이 문서로 표현할 수 없는 데이터로 이루어 져있다면, 어떻게 보낼 것인가?

 여기서 모든 플랫폼에 서로 대응하는 형태를 가져야될 것이다.

 이것을 64가지(숫자, 알파벳 대/소문자, 기타 기호 몇개)로 표현하는 방식이다.

 이 방식의 문제점은 용량의 증가가 존재한다는 문제가 있다.(약 33%가량이 증가한다고 한다.)

 이 방식은 메일 및 기타 방식에 사용되며, 암호와는 전혀 관계가 없다.

 그냥 인코딩하는 것이다. 암호는 알고리즘과 키가 밝혀졌을때, 최대한 그 암호 문서를 늦게 풀어내는 것이 목적이다.(공개키) 하지만, Base64는 남에게 숨길려고 드는 목적을 가지고 있지 않다.

 심지어, Base64는 키라는 존재도, 특정한 존재에게만 열리도록 목적을 가지고 있지 않다.

 1. Base64는 암호용 알고리즘이 아니다.

 그렇다고 Base64가 암축용으로 만들어진 것도 아니다. 오히려 용량이 늘었으면 늘었지(256가지로 표현된 데이터를 64가지로 표현하기 때문에 늘어날 수 밖에 없다.) 줄어들 경우는 없다.

 2. Base64는 압축용 알고리즘이 아니다.

 그렇다면, 왜 Base64가 존재하는가?

 그것은 쉽게 이렇게 들수 있다.

 파일은 올릴 수 없고, 게시판에 이미지 파일을 올려야 될 경우에.

 Base64을 이용하면, 쉽게 사용이 가능하다.

 다음과 같은 효과를 얻을 수 있으며, 음악, 사진, 동영상, 파일등 모두다 가능하다.

 그 외에도 메일(MIME)에도 사용이 가능하다.

이 책에서 설명하는 대로 찾아서 설치는 되지만, 차이가 많이 난다.

Intel에서는 INDE라는 녀석이 되어있고(책에선 Intel SDK for OpenCL Application이다.)

CUDA도 조금 다르다.

하지만, 애플, AMD, NVIDIA, intel등을 한번에 정의해서 적어 둔것이기 때문에 쓸만 할 것 같다.