# JPEG, PNG, WEBP 이미지 압축 포멧관련 테스트.

흔히 들어본 이미지 압축 포멧은 다음과 같다.

JPEG
Joint Photograph Experts Group의 약자로, 그림 파일 형식의 하나.

정지 화상을 위해서 만들어진 손실 압축, 무손실 압축(JPEG 9.1부터) 방법 표준이다. 이 표준은 ISO와 ITU-T에서 제정하였다.(ISO 10918-1, 한국어 설명)

JPEG를 사용하는 파일 형식들도 보통 JPEG 이미지라 불리며, .jpg, .jpeg, .jpe 등의 확장자를 사용한다.

JPEG 표준은 이미지가 어떻게 연속된 바이트로 바뀌는 지만을 규정한다. 독립 JPEG 그룹(Independent JPEG Group; IJG)에서 만든 JPEG의 확장인 JFIF(JPEG File Interchange Format)는 JPEG 스트림을 저장과 전송에 적합한 형태로 담는 이미지 파일 형식이다. 디지털 카메라의 사진 저장 방식으로는 다른 확장인 EXIF JPEG 형식이 더 자주 사용된다. 일반적으로 JPEG 파일이라고 할 때는 JFIF 형식이거나 EXIF JPEG 형식을 가리키지만, JNG와 같은 JPEG 기반의 다른 파일 형식도 있다.

-- 나무위키 中 ( link : https://namu.wiki/w/JPEG )

PNG
Portable Network Graphics의 약자로 그림 파일형식 중 하나이다.

PNG는 무손실 압축 포맷을 채택하였으며, 256색에 한정되던 GIF의 한계를 극복하여 32비트 트루컬러(알파채널, RGB에 각 8비트 지원)를 표현할 수 있게 되었다. 다만 네이티브 PNG는 GIF에서 제공하던 애니메이션 기능은 제공하지 못한다.

-- 나무위키 中 ( link : https://namu.wiki/w/PNG )

...

구글에서 개발한 이미지 포멧인 WEBP의 경우 아래와 같다.

WebP is a modern image format that provides superior lossless andlossy compression for images on the web. Using WebP, webmasters and webdevelopers can create smaller, richer images that make the web faster.
WebP lossless images are 26% smaller in size compared to PNGs. WebPlossy images are 25-34% smaller than comparable JPEG images at equivalentSSIM quality index.
Lossless WebP supports transparency (also known as alpha channel) at acost of just 22% additional bytes. For cases when lossy RGB compressionis acceptable, lossy WebP also supports transparency, typically providing3× smaller file sizes compared to PNG.

(link : https://developers.google.com/speed/webp/ )

무손실 PNG에 비해 26% 크기가 작으며, 손실 JPEG에 비해 25~34%가 작다!! 라는게 핵심이다.
웹상에서는 수많은 이미지가 있고 이는 결국 네트워크 트래픽으로 이어진다. 결국 비용이 많이 발생한다. 따라서 WEBP 포멧을
사용하면 이런저런 비용을 줄일 수 있고, 사용자 측면에서도 웹 페이지가 빠르게 보여지니 좋은거다.. 라는 거겠지.

일단 간단하게 테스트를 해보았다.
평소에 루리웹 월페이퍼 게시판에서 이미지를 다운하는데 이를 이용했다.
( ※ JPEG 손실, PNG 무손실, WEBP는 손실 )

다운받은 해당 게시글에 포함된 이미지는 82개이고 각기 다른 포멧으로 다운받아 압축했다.

JPEG는 약100mb / PNG는 180mb / WEBP는 52mb 정도가 나왔다.

이번에는 이미지 파일 1개로만 비교해보면 위 그림과 같다.

확실히 WEBP의 파일사이즈가 작다.

# 안드로이드(Android OS) 내장메모리(internal memory) 복구 가이드라인 ( windows 기준 )

테스트 환경 : Windows 10 ( 64bit )

전체적인 가이드는 다음과 같다.

1. 복구하고자 하는 스마트폰은 반드시 루팅한다. ( Super su )

2. ADB를 이용, 안드로이드에 마운트된 user data 또는 내장메모리 그 자체를 이미지로 만들어서 로컬 컴퓨터에 저장.
  (ADB 설치방법은 구글링으로 검색하자.)

3. 2번에서 만들어진 이미지를 이용해 vhd 파일로 바꾼다.

4. vhd파일을 가상디스크로 읽어들여 해당 디스크에 대해 복구프로그램을 돌려준다.


루팅의 경우에는 스마트폰마다 방법이 다르므로 구글링을 통해 찾는게 수월하다. 그러면, 2번~4번까지의 방법을 알아보자.

2번의 경우
 (0) adb 및 netcat 이용시에는 cmd 프로그램을 활용한다. cygwin에서 제공하는 기본 terminal을 이용하지 않는 이유는
     netcat을 통해 파일 전송시에 그 속도가 현저하게 뒤떨어진다.
 (1) 스마트폰 연결 후, cmd창을 open
 (2) adb start-server
 (3) adb forward tcp:9999 tcp:9999 ( port번호는 원하는걸로 )
 (4) adb su -c /system/xbin/busybox nc -l -p 9999 -e /system/xbin/busybox dd if=/dev/block/mmcblk0
     - 내가 쓰는 스마트폰 기준으로 내장메모리는 mmcblk0 이란 이름으로 mount되어 있다.
 (5) 스마트폰내에 내장메모리를 로컬 컴퓨터로 전송하는 방법은 netcat, cygwin을 이용한다.
     cygwin을 설치 후( 설치 시 dependency 목록중에 progress var(=pv) util, debug를 추가)
     bin 폴더에 netcat 파일을 넣어준다. 그 다음, 데이터 전송 유틸러리인 netcat를 이용해 로컬 컴퓨터로
     전송한다.
     ex) nc 127.0.0.1 9999 | pv -i 0.5 > testDumpfile.raw
     p.s. netcat 명령어는 구글링으로 검색해서 알아보자!!

  ( 위 그림과 같이 파일이 전송되어 진다. )

2번 순서가 끝나면, 바로 VHD tool을 이용해 raw 파일을 가상화 디스크 파일로 변경해야 한다.
( 변경 후, 확장자명을 .vhd로 변경해주자. )
vhdtool 에 대한 이용법은 구글링을 통해 찾기 쉽다.

VhdTool.exe /create <FileName> <Size> [/quiet]VhdTool.exe /convert <FileName> [/quiet]VhdTool.exe /extend <FileName> <NewSize> [/quiet]VhdTool.exe /repair <BaseVhdFileName> <FirstSnapshotAVhdFileName> [/quiet]

위와 같이 간단한 명령어 체계를 가지고 있다.

vhd 파일로 변경이 끝나면, 이제 widnwos 컴퓨터 관리 앱을 통해 해당 vhd파일을 등록시켜준다. 이 또한 간단하게 검색을..

여기까지 완료되었다면, 복구 프로그램을 구해서 해당 디스크를 복구시켜보자. -끝-

# CyclicRotation ( 현재 방법 구상중..)

역시나 코딜리티 레슨에 있는 문제.

주어진 배열이 3, 4, 5, 8 이라고 해보자. 이를 1번 회전 시키면 8, 3, 4, 5가 된다. 이는 오른쪽으로 1번 쉬프트 시킨 것 과 동일함.

따라서, 1번 회전은 곧 1번 오른쪽 시프트와 같다. ( 배열 인덱스를 넘어가는건 다시 처음 인덱스로 돌아온다. 위 예를 보면..)

라는 식의 문제이다. K번 회전했을 때 배열의 상태를 return 하는 함수를 주어주고 이를 구현하는건데, 우선 간단하게 생각해보면

오른쪽 쉬프트 동작을 K번 반복하면 된다. 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

// this solution is BruteForce. vector<int> solution(vector<int> &A, int K){ if(K==0) return A; vector<int> tmpArr; tmpArr.resize(A.size()); for(int rShift = 0; rShift < K; rShift++){ for(unsigned int idx = 0; idx < A.size(); idx++){ if(idx == A.size()-1) tmpArr[0] = A[idx]; else tmpArr[idx + 1] = A[idx]; } A.assign(tmpArr.begin(), tmpArr.end()); } return tmpArr; }

일단 이 방법은 bruteForce나 다름없다. 임의의 공간이 필요하며, K * 원소 갯수만큼 반복해야 하며 또한 쉬프트 동작 1번마다 공간에 대한 재할당이 일어난다.

동작은 하지만 굉장히 비효율적인 구조다. 

# 모모 앱 플레이어 실행 후 94%에서 멈추는 현상 / 게임 앱 실행시 프레임 저하 해결방안

사용하던 컴퓨터에서 발생했던 상황은 아래와 같다.

안드로이드 에뮬레이터인 '모모 앱 플레이어'

1. 실행때마다 진행 상태 94%에서 멈춘다.
2. 실행이 되더라도, 게임을 다운받아 설치 후 실행하면 프레임이 굉장히 떨어진다. (멈추거나, 매우 느림.)

재밌는건 Windows 7 64bit 환경에서는 해당 문제가 발생한적이 없었다.

Windows10 64bit로 최근에 업그레이드를 하면서 위와 같은 문제가 발생했다.

일단 구글링을 해보니, 백신 프로그램 Avast의 가상화 기술 사용 옵션과 충돌 하거나 windows 고유 기능인 방화벽 때문이라는 소문만 무성할뿐...
(모모 앱 플레이어 제작사에서도 특별한 대안이 없다.)

일단, Win7에서는 문제가 없었던게 왜 Win10으로 업그레이드를 하니 생기는걸까??...

-> windows7 을 사용했던 시절에도 컴퓨터에는 Avast가 설치되어 있었고, 따로 옵션을 건드린적이 없다.
-> win7이나 win10을 쓰는 지금도 Avast가 설치되었다는것과 같은 버전의 MOMO_APP_PLAYER을 사용했다는 점.
-> 따라서, 우선 해볼만한 방법은 설치된 Avast의 가상화 기술 사용 옵션을 해제하는 것.
   (CPU에서 지원하는 가상화 기술이 여러 프로그램에서 사용하다 충돌을 일으키지 않을까 하는 생각에서..)

위 그림처럼, 가상화 사용 옵션을 해제해주고..


그다음에, CyberCapture 옵션도 해제해준다. ( 옵션->일반 )
이 옵션을 해제안하고 모모앱을 플레이해보니 프레임 드랍이 생기더라...쩝.

결과는..

다행스럽게도 해결되었다.


p.s. 아바스트 백신 프로그램을 이용중이라면, 모모앱 플레이어 같은 안드로이드 에뮬레이터 실행시에
adb.exe 파일을 위험파일로 인지하는 경우가 있는데 이럴때는 예외생성으로 허용해줘야한다. adb는
anroid debug bridge의 준말로, 안드로이드 디버깅에 쓰이는 프로그램이다.
(-> https://developer.android.com/studio/command-line/adb.html )

p.s.2 모모 앱 플레이어가 중국에서 개발한걸로 알고있는데, 한국에서 유통하고 있던걸 폐지한걸로 알고있다.
구글에서 검색해서 웹사이트 접속해보니 폐지됬더라.. 쩝.