CAMERA2012.11.07 10:05

 

Apple | Canon EOS 5D Mark II | Pattern | 1/500sec | F/2.8 | +0.33 EV | 200.0mm | ISO-100 | Off Compulsory

 

다른 포스팅들 하느라 메인스트림에 해당하는 이 포스팅의 연재가 좀 늦었네요.

사실 뭔가가 머리속에 번쩍 하고 떠올라야 일필휘지로 글을 써 내려가는 습성이 있는지라 ...떠오른거 먼저 쓰다보니 자연스레 이리 됩니다.

부디 이해해주시길 바라며,

오늘은 디지털사진의 "저장 방식"을 올바르게 이해해야 제대로 저장하고 되돌아보며

목적에 맞는 최선의 화질을 선택할 수 있다는 명제를 가지고 왜 우리가 비트맵을 알아야 하는지 그 당위성에 대해 논해보도록 하겠습니다.

 

현재 우리 사진찍는 사람들의 절대 다수는 JPG라는 파일형식을 씁니다. 그리고 이것이 거의 모든 문제점의 출발점이 됩니다.

왜냐면 JPG는 태생적으로 "손실압축"이라는 한계를 지니고 있기 때문이예요. 우리가 비트맵을 이해하고 비손실압축을 선택하지 않는 이상은

JPG로 저장을 거듭할 수록..사진은 손상됩니다. 아니 그 이전에 JPG로 최초에 저장할때도 JPG라는 비트맵이미지 저장방식을 이해하지 못하면

처음부터 손상될대로 된 사진을 보존하게 될 수 밖에 없습니다.

 

제가 예를 들길 좋아하는거 다들 아시죠? 지금부터 또 그 예를 하나 들어보겠습니다.

가장 대표적인게 MP3라는 음원압축방식입니다. 현재 우리는 대부분 음악을 들을 때 MP3라는 압축파일형식을 사용합니다.

원래 오디오 데이터 역시 사진 데이터 빰칠만큼 용량이 대단히 큽니다. 얼마나 크냐면 5분짜리 곡 하나를 그냥 녹음하면 50메가가 넘어갈 정도예요.

노래 하나에 50메가면 도저히 많은 곡들을 저장한다는건 불가능하죠. 사실 윈도우 3.1이나 윈도우 95 초기까지만 해도 이것이 현실이었고

이때문에 디지털로 음악을 듣는 사람을 찾아보기 힘들었었습니다.

그런데 거기서 MP2, MP3라는게 등장합니다.

MP3의 대단한 점은 대단히 효율적인 손실압축을 했다는 거예요. 예를 들면 CD나 레코드판의 경우에는 인간이 들을 수 있는 가청영역외의 소리까지도

보존하고 있다가 재생합니다. 이 소리는 거의 들리지 않지만 차지하는 용량은 가청영역의 소리와 다를 바 없습니다.

MP3는 바로 그 비가청영역의 소리를 거의 버리다시피 하며 파일을 압축해 저장하는 손실파일형식이예요.

그덕에 용량이 무려 1/10으로 줄어들면서도 가청영역의 음질은 거의 손실이 없다시피 한 기적을 이뤄냅니다.

뭐 MP3를 최초에 인코딩하는 사람의 역량이 형편없다면 음질저하가 꽤 눈에 띌 수도 있습니다.

반면 역량이 높다면 용량은 더 많이 줄이고 음질저하는 더 적게 할수있죠.

문제는 압축이라는 점이었죠.

우리가 MP3를 들을때는 우리가 인식하지 못하는 사이에 파일의 압축을 푸는 과정이 선행됩니다.

5메가짜리 파일의 압축을 풀어 버퍼에 이동시키고, 버퍼속의 데이터로 음악을 재생한 후 버퍼를 비우는 것입니다.

당연히 그냥 음원을 틀때랑은 PC나 플레이어에 가해지는 부담이 훨씬 큽니다.

이게 지금 시간이 흘러 PC의 기본사양과 스펙, 연산속도가 대단히 올라가 그냥 막듣는것처럼 보이는 것일 뿐,

386이나 486 초기시절만 해도 MP3를 재생하는데 그 큰 PC의 거의 모든 리소스를 필요로 했을 정도예요.

MP3틀고 멀티태스킹하면 음악이 막 끊길정도였습니다. 기억하시는 분들은 많지 않으시겠지만요.....대신 우리는 저용량이라는 달콤한 열매를 손에 쥐었습니다.

연산에 걸리는 부담과 음질저하라는 댓가를 지불하고 말이죠.

 

다시 본론으로 돌아와 JPG에 대한 이야기를 계속해보죠.

제가 JPG이야기 하다가 MP3이야기로 갔다 온 이유는, JPG의 본질이 이와 거의 완벽하게 동일하기 때문입니다.

 

본래 이미지파일의 용량이란 제가 이전 포스팅에서 말씀 드린 바와 같이..대단히 큽니다.

PC가 저사양이었던 시절, HDD라는게 용량이 20메가쯤 되고 플로피디스크 한장에 1.44메가 겨우 들어가던 바로 그시절을 돌이켜보세요.

사진 한장에 10메가가 넘어간다는 것 자체가 있을 수가 없는 일이었습니다. 사실 이당시엔 스캐너를 제외하곤 CCD/CMOS기술 자체가 확립안되었었죠.

그래서 대부분의 그래픽파일이 PC에서 직접 그리고 만들어낸 저용량의 파일들이었습니다.

이당시의 대세가 GIF파일이었죠. 

GIF파일은 어떻게 이때 대세가 될 수 있었는가 하면...비결은 "색"에 있었습니다.

당시의 VGA...아니, 당시엔 VGA라는것 조차 없거나 초고가의 사치품이었어요.

XGA..CGA..허큘리스..이런게 그래픽카드 역할을 했고 모니터 역시 지금의 휘황찬란한 모니터가 아니라

대부분 그린 단색 모니터 아니면 원시적 CRT모니터였던 시절입니다. 자연색, 트루컬러의 개념조차 안잡혀있던 시절로 거슬러 올라가야

왜 비트맵 이미지가 이렇게 변했고 이러이러 한가를 통찰해볼 수 있기때문에 꽤 많이 거슬러 올라가게 되네요.

이러한 상황에서 컴퓨터 그래픽스 이미지에는 많은 색을 필요로 하지 않았습니다.

껏해야 16색, 256색이면 넉넉했으니까요. 그때문에 GIF를 위시한 몇몇 원시적 그래픽 파일이 대세가 됩니다.

개중 가장 대세였던 GIF파일의 특성은, 파일에 색파레트가 딸려있었다는 겁니다.

어떤 이미지가 있을 때, 그 이미지에 가장 많이 사용되고 그 색만 있으면 그 이미지를 대충 재현할 수 있겠다 싶은 컬러 256개만 등록시켜놓고

한 파일안에 같이 저장한 다음, 그 색만 사용해서 이미지를 재구성하는것이 GIF입니다.

XYRGB가 아니라 XYC의 개념으로 보시면 되요. 좌표는 존재하지만 색에 할당된 총 비트수는 매우 낮은...

따라서 대단히 저용량에 얼핏 매우 훌륭한 이미지의 재생이 가능했습니다. 당연히 대세가 되었죠.

 

하지만 약간의 시간이 흐르고 광집적소자, 다시말해 빛을 전기신호로 바꾸어 이미지를 디지털라이즈 하는 기술이

스캐너라는 형식으로 상용화 되기 시작하면서부터 GIF는 단숨에 그 파일포맷의 한계에 부딪힙니다.

왜 그러냐구요? 실제 예를 보시면 아주 간단히 이해하실 겁니다.

 

 

Canon | Canon EOS 5D | Pattern | 1/200sec | F/8.0 | 0.00 EV | 24.0mm | ISO-200 | Off Compulsory

예를 들어 이런 사진을 필름카메라로 촬영하고서 디지털 이미지로 바꾸기 위해 스캐너로 스캔했다 칩시다.

스캔한 파일을 GIF로 저장하면 이런 꼴이 됩니다.

 

어때요?

 

네? 잘 모르시겠다구요?? 뭐가 다른지?

예. 그것이 GIF의 대단한 점입니다. 그렇기때문에 아직까지도 명맥이 끊기지 않고 유지되면서 사용되는 겁니다.

하지만 조금만 더 눈이 높아진다면 이 차이는 단숨에 보입니다.

보다 편한 이해를 위해 확대...를 해볼께요.

 

 

이것이 원본JPG를 확대한 것이고

 

 

이것이 GIF이미지를 확대한 것입니다.

 

이제는 눈이 높지 않으신 분들이라 할지라도 한눈에 "아하~~!!" 하실겁니다. 무엇이 다른지. 왜 다른지. 어떻게 다른지가 말이죠.

이게 지금 모니터 화면상이니 그나마 아까처럼 그냥 보면 티가 덜나는겁니다. 인화라도 해보면 이 차이는 극명하게 드러나요.

모처럼 찍은 사진을 힘들게 스캔해서 GIF로 저장했더니 이모냥 이꼴이더라.....인화해봤더니 완전 꽝이더라.....이런 상황이 벌어진겁니다.

 

당연히 모든 사람들이 새로운 이미지 포맷에 눈을 돌리게 되는데

아주 훌륭한 대타가 거기엔 이미 존재했던 겁니다. 바로 JPG라는....

 

당시 JPG는 대단히 훌륭하게 자기 역할을 수행할 수 있었습니다. 보급화되기 시작한 VGA와 괜찮은 품질의 CRT모니터,

그리고 이제 막 각 제조사들이 앞다투어 입에 올리기 시작한 24비트 트루컬러(R8+G8+B8=24, 각 8비트는 환산하면 256, 다시말해 이전에 말한 1677만색) 광고와 더불어서 말이죠.

 

문제가 하나 있었다면 그건 당시의 느린 PC사양이었습니다.

아까 예를 들고 말씀드린 바와 같이...JPG는 근본적으로 "손실압축"파일 포맷입니다. 다시말해 그 자체로서는 결코 그냥 볼 수 없고,

보기 위해서는 ZIP파일이나 RAR파일, ARJ파일(....말하고 보니 이거 엄청 오래간만..)처럼 압축을 푸는 과정이 선행되어야만 했던거죠.

그래서 JPG파일 하나 열어보려면 짧게는 수초에서 길게는 수십초를 기다려야 했습니다.

ZIP파일 압축 하나 푸는데 짧게는 수초에서 길게는 수십초 기다리는 것과 마찬가지 이치에서요.

하지만 IT산업은 정말로 빠른 속도로 발전되었고, 점차 그 압축을 푸는 속도는 광속에 가까우리만치 빨라지게 됩니다.

얼마나 빨라지냐면 현재에 와선 JPG파일이 ZIP파일과 같은 압축파일이란 사실조차 모르시는 분들이 태반이 될정도로 빨라집죠.(.......)

 

그렇기때문에 JPG가 대세로 떠오르게 되며, 많은 카메라 제조사들이 JPG를 기본포맷으로 삼을 정도에 이르릅니다.

화질이 뛰어난 TIF포맷은 원초부터 존재해왔으나 비손실압축/아니면 아예 비압축파일 이다보니 용량이 너무나 정직하게 컸고

그 특성상 전문가급이 아니면 이 형식의 존재조차 모를정도였고 말이죠. (지금도 여전히 존재조차 모르시는 분들 비일비재합니다...)

BMP라는 윈도우 기본 이미지 파일 포맷도 있긴했지만 RLE압축프로토콜의 등장이전에는 이놈도 무조건 비압축 포맷이었기 때문에

대세로서 등극하는데는 실패합니다. 기껏해야 윈도우 배경 바탕화면 만들때나 쓰는 포맷으로 전락하죠.

당연하다면 당연한 일입니다. 1024x768크기의 8비트컬러 이미지가 있다면 jpg는 300k면 떡을 치는데 BMP나 TIF는 정직하게 하나당 꼭 꼭 2.24메가 먹었으니

비전문가라면 뭘 쓸지 자명한 이치 아니겠습니까?

 

하지만 처음에 말씀드린 대로 JPG에는 "손실압축"이라는 태생적 한계가 있었고,

이는 디지털 이미지에 있어 비트맵을 제대로 공부하지 않은 사진사분들에게 치명적인 문제를 선사하게 됩니다.

바로 "압축율"과 이로 인한 "이미지의 손상"이죠.

 

글이 너무나 길어지는 듯 하고 저도 지금 시간이 없어서 이 다음은 다섯번째 포스팅에서 계속 이어가도록 하겠습니다.

머리속에 떠오르는 대로 일필휘지로 갈겨쓰고 있는거라 많은 오류가 존재할 수 있으니 이점 유의해주시고

제 글에서 오류를 발견하신 고수분들께서는 제가 글을 바로잡을 수 있도록 도움말씀 꼭 주시면 감사하겠습니다~

 

 

Posted by 오럴그래퍼 선배/마루토스

댓글을 달아 주세요

  1. jpg, gif에서 데이터 손실이 엄청나군요. 인화할 사진이라면 뽑고나서 후회하기전에 잘 봐둬야 겠습니다!

    2012.11.07 10:11 신고 [ ADDR : EDIT/ DEL : REPLY ]
  2. 24비트 트루컬러 VGA들이 쏟아지기 시작한게 93~4년도로 기억되는데요, 당시 VGA 카드를 사면 각종 드라이버가 담긴 5.25인치 플로피 디스크가 10장 정도 딸려왔던 기억이 납니다.
    그 플로피 중에는 과일 정물 사진 한 장 떨렁 담긴게 있었는데요, 그거 열어보면서 오오~~~이게 트루컬러의 세계인가!!! 감탄했던 기억이 나네요. 이미지 파일 하나 불러오는데 30초 가까이 걸렸음에도 꽤나 큰 충격이었던...@,.@;;;

    2012.11.07 11:03 신고 [ ADDR : EDIT/ DEL : REPLY ]
  3. 미음

    으악, 뭔가 전개가 흥미진진하네요 ㅋㅋ

    잘 보았습니다 ^^ㅋㅋ

    2012.11.07 11:24 신고 [ ADDR : EDIT/ DEL : REPLY ]
  4. 본격 화일포맷의 역사!!
    유익합니다만 메인스트림이라는 단어를 쓰시니
    맨 위 사진은 제트스트림 어택으로 보입니다. -_-;;

    2012.11.07 12:13 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 여..여기서 이런 덕심을 발휘하시다니; 과연 남다르십니다;;

      다음에는 그렌 라간 합체를 보여드립죠;;

      2012.11.07 13:06 신고 [ ADDR : EDIT/ DEL ]
    • 여튼 소소한 역사...의 재미라는게 또 있더라구요.
      무엇이 왜 만들어졌고, 어떤 이유로 선택받아 역사에 남거나 혹은 선택받지 못해 역사에서 사라지거나 하는..
      그런 자잘함의 역사들을 알아가는것 역시
      또 다른 재미의 하나가 아닐까 싶습니다.

      .....게임의 역사 쓰라면 아마 신나서 쓸거같네요 저;;

      2012.11.07 13:33 신고 [ ADDR : EDIT/ DEL ]
  5. 체계적이고 이해하기 쉬운 설명 감사합니다~!!^^
    역시 뭐든 제대로 알아야 한다는 생각이 드네요 ㅎㅎ
    훌륭한 연재 내용들 계속 잘 공부하겠습니다.

    2012.11.07 17:03 신고 [ ADDR : EDIT/ DEL : REPLY ]
  6. cha

    항상 잘 읽고 있습니다. 그런데 문맥에 따라 "손실"이 핵심인지, "압축"이 핵심인지가 다른데 이걸 퉁쳐서 "손실압축"이라고 따옴표를 해놓으니 읽는데 애매한 점이 있습니다. 따옴표좀 다시 쳐주세요 ㅎㅎ

    2012.11.07 20:05 신고 [ ADDR : EDIT/ DEL : REPLY ]
  7. 사진 저장 화일에 대한 이해를 아주 쉽게 할수 있게되었네요.
    덕분에 잘 읽고 갑니다.

    2012.11.08 08:41 신고 [ ADDR : EDIT/ DEL : REPLY ]
  8. 세르피코

    마루토스님 아니었다면 비록 취미이지만 사진생활이 별로 즐겁지 않았을거 같아요.
    올때마다 새로운 것들을 알아가는 즐거움과 많은 가르침 항상 감사합니다.

    2012.11.08 10:08 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 음..저는 그렇게 생각해요.

      제 블로그에 오시고, 오셔서 보시고,
      보시고 뭔가를 얻으시는 분들은

      저와 제 블로그가 없었더라도 결국 그 뭔가를 얻어내실법한 분들이라고요..

      저는 아주 조금 거들 뿐....;

      2012.11.08 17:12 신고 [ ADDR : EDIT/ DEL ]
  9. 섭이

    역시 피시보관은 jpg 인화용은 RAW 라는걸 한번 더 인식시켜주시네요. 좋은글 잘 봤습니다.

    2012.11.09 09:59 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 사실은 전 JPG조차 보관하지 않습니다.
      RAW만 보관하고 있다가, 필요가 생기면 그 목적에 맞춘 최적의 JPG를 매번 새로 만들어내요.

      어찌보면 귀찮아보일지 모르지만 이것이 최선이라고 저 자신은 확신을 가지고 행하고있습니다.

      2012.11.09 10:06 신고 [ ADDR : EDIT/ DEL ]
  10. 정말 좋은 지적이십니다!! 프로젝트를 진행할 때 이미지를 따면 해상도나 비트맵에 상관없이 이미지를 제공하고서는 '이렇게 해주세요'하는 경우도 더러있었던지라 ㄱ-.... 손실률이 적은 PNG가 기본 포맷으로 안쓰이고 왜 JPG가 쓰이는지에 대한 비교도 있었다면 어떨까하는 약간의 아쉬움이 있긴한데, 머리 속에 떠오르는데로 쓰셨다면서 초보분들이 이해하기 쉽도록 잡아주신 것 같습니다.

    2012.11.09 12:39 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 예전에 그래픽 파일 확장자 정리 한번 하면서 논한적이 있어 그냥 얼렁뚱땅 넘어가긴 했는데
      다음번 글에서는 JPG의 단점과 함께 PNG가 지니는 장점,
      그리고 왜 대세가 되지 못했는가도 다뤄보도록 하겠습니다.

      2012.11.09 13:18 신고 [ ADDR : EDIT/ DEL ]
  11. 언제나

    파일형식에 따른 이미지 손실이 상당함에 대해 잘 배웠습니다. 열심히 공부하겠습니다. 감사합니다.

    2013.06.14 17:23 신고 [ ADDR : EDIT/ DEL : REPLY ]