새벽에 잠이 깼는데 잠이 안와서 그냥 끄적여봄
* ANIMATION GIF
대부분의 이미지 파일은 단순히 이미지 한장이지만, ANIM GIF 는 여러장의 이미지를 순차적으로 보여주기 때문에 동영상과 그다지 다를바가 없다. 동영상 플레이어를 만드는거면 몰라도 이미지 뷰어에서 ANIM GIF 를 보여줄라면 처음부터 설계를 잘 해야 한다.
ANIM GIF 가 몇장 안되면 별 상관없지만, 이 파일이 커지기 시작하면 메모리 문제가 발생하기 시작한다. ANIM GIF 은 포맷에서 변화값만을 저장하는것이 가능하기 때문에 꽤나 적은 파일 크기로 많은 프레임의 동영상을 만드는게 가능하다. 대부분의 경우는 큰 문제가 없지만, 한 20분 짜리 ANIM GIF 파일을 만들어 버린다면 프레임 전체를 디코딩해서 메모리에 올렸다가 보여주는 방식은 꽤나 곤란한 처지가 되어 버린다.
MNG 나 APNG 와 같은 파일도 동영상을 지원하지만 지원하는 프로그램이 거의 없고 파일도 거의 없으므로 패스. TIFF 파일은 동영상은 아니지만 하나의 이미지에 여러장의 이미지를 저장하는것이 가능하다.
* 초 대형 이미지 파일 로드시 문제
10000x10000 짜리 jpg 파일이 있다고 치자. 이걸 메모리로 디코딩을 하면 (32bpp 라고 가정)
10000*10000*4/1024/1024 = 381MB
가 된다. 즉 한번에 400MB 가까이 malloc 을 호출후 디코딩을 하게 되는 것이다. 만약 시스템의 물리적 메모리가 이보다 적게 되면 하드 스와핑을 하게 되면서 시스템은 먹통에 가까운 상태가 된다.
이걸 제대로 처리하려면 몇가지 처리를 해야 하는데
1. 만약 화면에 축소해서 보여준다면 저 크기 그대로 디코딩을 할 필요는 없다. 1600x1200 으로 보여준다면 디코딩을 하면서 동시에 리사이징을 수행할수도 있다. - 쉽지는 않다.
2. 화면에 축소 없이 1:1 그대로 보여준다면 화면에 보이는 부분만 디코딩을 해서 보여준다. 이미지를 가로x세로 적당이 블럭으로 쪼개서 화면에 보여주려는 블럭이 없을때 해당 블럭만 그때 그때 디코딩을 해서 보여준다. - 역시 쉽지 않다.
제일 힘든건, 99.9%의 이미지는 여기에 해당되지 않기 때문에 고생은 고생대로 해서 지원을 해도 사용자 입장에서는 그닥 차이가 없고, 개발자 입장에서는 유지보수가 힘든 고난이도 코드만 만들게 된다는것.
===
예전에 CPU가 느릴때 많이 쓰던 acdsee 같은 프로그램은 이미지 파일을 다 디코딩 + 리사이징 까지 해서 보여주면 몇초의 시간이 걸리게 되니까 이미지를 디코딩 하면서 화면에 바로 뿌려주는 방식을 사용해서 프로그램의 체감 속도를 몇배로 늘려주었다. 하지만 요즘은 이런 방식의 이미지 뷰어를 보기 힘들다. 대부분의 jpg 파일은 0.1 초 이하에 디코딩이 가능하기 때문이다. 문제는 컴퓨터가 빨라지면서 이미지 파일도 점점 고해상도 파일이 나타나기 시작했다는것. 더군다나 새로운 이미지 포맷 (jpeg2000, jpeg xr, webp) 은 jpg 보다 압축율이 좋지만 cpu 디코딩 시간은 몇배가 더 든다.
결국 예전의 acdsee 처럼 이미지 뷰어가 좀더 복잡한 쓰레딩 처리를 해야될 시기이기도 하다.
