shopkeeper/korean_wiki_content_only_120125 huggingface dataset:
한편, 명성황후의 암살은 조선 민중들의 분노를 야기하였고, 암살에 관련된 조선인 장교들과 군인들은 피신하거나 은신해 있었다. 이 때에 백범 김구(이 때의 이름은 김창수, 金昌洙)는 의병으로 만주에 있다가 1895년 초 귀국하며 일본인 상인 쓰치다 조스케(土田讓亮)를 일본 낭인으로 오인하며 치하포에서 만나 그를 죽이는 일이 발생하기도 한다. 김구는 이에 대해 뒷날 그가 일본 낭인이거나 왕비 암살에 가담한 자라고 주장하였으나, 오늘날 그는 일본인 상인으로 알려져 있다. 역사문제연구소 연구원 배경식 교수는 "지금까지 확인 가능한 어떤 자료에도 그 일본인이 육군중위라는 기록은 없다"며 "일본 공사관의 보고서와 조선 관리의 보고서, 독립신문의 사건 보도는 한결같이 그를 '상인(商人)'으로 적고 있다"고 했다. 그뿐 아니라 배 교수는 백범도 그가 육군 중위가 아니라는 걸 알았을 것이라고 주장했다. 1997년 도진순 창원대학교 교수는 일본의 자료로부터 그가 계림장업단의 상인이며 민간인이었다고 밝혔다.
암살의 배후.
일본 낭인.
일본 자객들은 치밀하게 계획을 짜고 한성으로 잠입, 명성황후의 암살을 주도하였다. 이 과정에서 조선인 병사들을 훈련하여 표면적으로 앞세웠다. 또한 명성황후의 암살 배후로 일본 공사 이노우에 가오루 등이 지목되었다. 2006년에는 최문형 한양대 명예교수가 일본 헌정자료실에서 찾아낸 야마가타 아리토모 (山縣有朋) 육군대장과 무쓰 무네미쓰 (陸奧宗光) 외상 사이의 편지를 통해 일본 정부의 개입설이 제기되기도 하였다. 명성황후의 암살 과정에서 조선인 병사들이 길안내를 했고, 일본군이 양성한 훈련대의 제1대대장 이두황, 제2대대장 우범선, 제3대대장 이진호(李軫鎬) 등이 일본 낭인에 협력했다. 그 밖에 전 군부협판 이주회 등도 포섭하였다. 이 중 우범선이 1903년 고영근에게 죽음을 당했다.
조선인 협력자들.
명성황후 암살의 국내 고위급 협력자로 유길준과 흥선대원군이 지목되었다. 윤치호는 그의 일기에서 그를 암살한 일본 낭인들의 지휘자 중 한사람으로 유길준을 지목하였다. 명성황후가 암살당할 무렵 윤치호는 유길준과 일본인 이시즈카가 사건의 전말을 은폐하기 위해 자신을 그날의 저녁 식사에 자신을 초대했다는 것이다. 유길준은 대원군이 명성황후 암살의 조선 측 주동자라고 지목하였다. 1894년 가을 명성황후가 개화당을 제거하려는 계획을 꾸몄다가 대원군의 첩보망에 발각되었고, '대원군은 일본 공사 오카모토와 협의 끝에 일본인들로부터 약간의 도움을 얻어 그녀를 죽이기로 결정하였다.'는 것이다.
유길준은 흥선대원군을 명성황후 암살의 조선인 거물 협력자로 지목했다. 미국인 교수 에드워드 모스에게 보내는 편지에서 유길준은 명성황후 암살은 실행되었지만 대원군이 명성황후 암살 문제를 일본공사와 협의하고 일본측에 약간의 도움을 요청한 것은 큰 실수였다고 지적하였다. 그러나 유길준은 '도움을 얻기 위해서는 달리 방법이 없었다.'는 의견도 덧붙였다. 사학자이며 대한민국 임시정부의 2대 대통령인 박은식도 흥선대원군을 명성황후 암살의 배후로 지목하였다. 박은식은 춘추전국시대에 조돈(趙盾)이 왕을 암살한 것을 비유하여 이와 다를바 없다고 평가하였으며 감정이 사람의 양심을 가린다며 비판하였다.
한 소설가는 〈에조 보고서〉를 근거로, 일본 군인들은 황후를 강간했다는 주장을 했지만 작가의 주장대로 에조는 현장을 목격한 시해범이 아닌 고문이며 근현대 문헌 최고권위자중 하나인 서지학자 김종옥, 서울대 신용하 교수등 전문가들은 해당 작가의 주장에 대해서 상식에 위배되는 거짓낭설이라 일축했다. 이러한 주장은 물론 &lt;에조 보고서&gt;자체가 실제 목격자의 진술이 담겨있는 가장 신빙성있는 자료로 평가받는 &lt;베베르 보고서&gt;를 비롯한 다양한 증언들과 완전하게 위배된다. 여기서 쓰인 '나체"국부'라는 단어도 논란이 있는데 &lt;에조 보고서&gt;를 신뢰한다고 가정해도 히로시마에서 시해범들이 증언한 '민비의 얼굴을 알 수 없어 중년여성의 신원을 식별하기 위해 가슴을 확인한 행위'를 지칭했을 개연성이 크다.
한 내용은 “러시아 외교부 장관 로바노프가 자신의 정보에 따르면 죽었다고 이야기되는 한국의 왕비가 아직 살아 있다고 나에게 말했다. 서울 주재 러시아 공사(베베르)는 왕비가 러시아 공사관으로 피신할 수 있는지를 한 명의 한국인으로부터 아주 비밀리에 요청받았다고 한다. 로바노프는 일본군이 한국에 오래 머무르고 있다고 말했다. 중국이 한국에서 철군한 것처럼 일본군도 더 이상 한국에 주둔할 근거가 없다고 했다”였다.
한편 서울 주재 영국 총영사 월터 힐리어가 을미사변 직후 작성한 문서에서 1895년 10월 9일 베이징 주재 영국 공사 니콜라스 오커너에게 “일본인들이 서너 명의 궁녀를 죽였다. 그리고 왕비는 사라졌는데 탈출한 것으로 보인다”고 보고했다. 이어 10월 22일에는 오커너에게 베베르가 자신을 방문해 왕비의 생존 가능성을 이야기했다는 보고서를 보냈다.
1895년 10월 8일 새벽 경복궁 건청궁에서 살해당했다는 게 한국 역사학계의 정설이나 정상수 교수는 "독일과 영국 등 당시 조선과 관계를 맺던 나라들의 외교문서이기 때문에 신빙성이 높다. 명성황후의 시해를 당연시할 게 아니라 새로운 사료 발굴로 진실을 찾아야 한다."라고 주장했다.
한편 이에 대한 역사학자의 여러 반응으로, 전우용 서울대학교 국사학과 교수는 "이번 문서는 일본이 사건을 무마하기 위해 퍼뜨린 역선전이 포함됐을 가능성이 있다."며 "외교가 풍문에 관한 새 자료 정도로 봐야 한다."라고 진단했다. 이태진 국사편찬위원장은 이에 대해 “명성황후 생존은 을미사변 뒤에 일어난 여러 사실을 보면 있기가 힘든 상황”이라고 말했다. 또한 “독일 외교문서가 신뢰성이 높다는 것은 수긍하지만, 라돌린 문서가 아관파천 즈음에 나온걸 보면 러시아 공사관 대피를 원한 사람이 왕비가 아니라 왕의 오기일 가능성도 있다.”며 사실이 아닐 가능성을 제시했다.
평가 비판.
그의 벗 윤치호가 명성황후를 살해한 범인이라고 지목했던 유길준은 명성황후를 ‘세계에서 가장 나쁜 여성’이라고 혹평하였다. 암살 직후 유길준이 미국인 은사 모스에게 보낸 날짜 미상의 편지에서 유길준은 명성황후를 잉글랜드의 메리 1세 여왕, 프랑스의 마리 앙투아네트보다도 더 악하다고 비판하였으며, 비판 사유로 당시 백성들 사이에서는 국왕은 일개 인형이고 왕비는 그 인형을 갖고 노는 사람이라는 시중의 소문을 근거로 제시하였다. 유길준은 명성황후를 개화당 살해의 배후로 보았다. 모스에게 보내는 편지 본문에서 유길준은 명성황후가 도움을 청하기 위해 러시아 공사와 비밀 접촉하고, 1894년 가을 개화당 모두를 살해하려는 계획을 꾸미다가 국왕의 아버지인 대원군에게 발각되었다고 하였다. 황현의 《매천야록》에 따르면, 명성황후의 사치와 민씨 정권의 매관매직에 대해 매우 부정적으로 서술되어 있다.
서재필은 명성황후가 영민한 두뇌의 소유자라고 평가하였다. 1947년 군정기 때의 한 회고담에서 서재필은 "김옥균의 지략은 역사적인 것이었소. 박영효와 홍영식과 서광범 또한 그에 뒤지지 않는 재사들이었지요. 그래서 세상 사람들은 그들에다 나까지 넣어 다섯 사람의 기지와 계략을 모으면 세상에 못할 일이 없다고까지 일컬었습니다. 그런데도 그 다섯 사람이 함께 민비 앞에 나가면 으레 민비에게 기선을 잡혀서 머리를 긁적거리며 물러나오기 마련이었지요. 민비는 실로 당할 길 없는 지략과 재략을 지닌 걸물이었소."라며 그녀가 사태 분석에 기민했다 고 평하였다.
후대의 평가.
명성황후에 대한 역사학계의 평가는 친일 급진 개화파와 수구적 척사파, 일본 관변 측으로부터 모두 좋지 않은 평을 얻었다. 반면에 그러한 좋지 않은 평가는 명성황후의 정책 노선이 그만큼 보수와 진보 사이에서 균형을 이루었다는 반증이라는 주장도 있다. 한편 척족정치의 악순환을 거듭케 했다는 비판도 있다.
또한 명성황후와 척족 세력은 중인 중심의 개화파와는 달리 전통과 서양 문명을 절충하려는 동도서기(東道西器)의 정책 노선을 띠었다. 이 때문에 급진개화파의 입장에서 사대당 또는 수구당으로 평가를 받기도 한다. 반면에 고종의 입장에서는 근왕파로서 고종이 시도한 광무개혁의 지지세력이었고, 을미사변 이후에는 반일의병운동을 배후에서 지원하였으며, 대한제국 성립에도 큰 역할을 하였다. 그러나 대원군에 의해 척결된 세도정치를 다시 불러들였다는 비판과 외세를 이용하려 하여 국내에 일본의 침입을 촉진시켰다는 부정적인 시각도 존재한다. 심지어 일부 극단적 평론가는 비슷한 시기 청제국을 쇠퇴시킨 서태후와 동급을 취급하기도 한다. 보통 그들은 서태후와 명성황후를 19세기 동양의 최악의 황후라고 비판한다.
유학자 황현은 고종과 명성황후가 국고를 탕진했다는 점을 지적, 비판했다. 그리고 황현 자신의 저서 매천야록의 곳곳에서도 이를 언급하였다. 고종과 명성황후는 원자가 태어나자 궁중에서는 원자가 잘 되길 빈다는 핑계로 제사를 8도 강산에 두루 돌아다니며 지냈다. 이렇게 탕진하는 하루 비용이 천금이나 되어 내수사가 소장한 것으로는 비용 지출을 감당할 수가 없었다. 마침내 호조나 선혜청에서 소장한 공금을 빌려서 사용했지만 그것이 위반이라고 말하는 사람도 전혀 없었다. 1년이 채 못돼 대원군이 비축해 놓은 재물을 모두 탕진했다. 그래서 매관이나 매과까지 기승을 부렸다고 한다. 내수사에서 관리하는 왕실 재산으로도 모자라 국고의 예산까지 사용했다는 것이 비판의 내용이다.
외척으로 편중된 권력.
1874년 11월 흥선대원군을 축출한 뒤 황후는 민씨 일족을 대거 등용하여 조정에 진출시켰다. 이 중 민겸호는 선혜청에 있으면서 군인들의 급료를 착복하고 모래를 섞어서 주어 임오군란의 원인을 제공하기도 했다.
문정공 송준길은 우복 정경세의 사위이며 민유중은 송준길의 사위이다. 명성황후는 송준길 집안에 대해서는 가까운 외가의 의를 지켰고, 정씨 집안을 추대해서 역시 외척같이 각별히 생각해 왔다. 명성황후는 정경세를 부르기를 우복 할아버지라고 하였다. 그래서 송씨, 정씨 두 집안의 후손들은 크게 고종의 총애를 받아 과거에 급제해서 벼슬을 하는 사람이 부지기수로 많았다. 이때 고종과 흥선대원군은 친골육지간이지만 사이가 나빠져, 아버지 대원군을 혐오했던 것 같았다. 이때 사람들은 이렇게 말하며 비아냥거렸다. "내전(왕비)는 돈목을 감소시키고 대전(임금)은 돈목을 증가시키면 좋겠다."는 것이다.
외국의 평가.
명성황후에 대해 일본인을 제외한 외국인들은 대체적으로 좋게 평가했다. 이를테면 정치적 이해관계에 예민하지 않은 민간인의 기록이 그러하다. 그들은 한결같이 명성황후가 영리한 판단력과 뛰어난 외교력을 지닌 교양 있는 여성임을 전해준다.
한편, 일본의 화가들이 그린 명성황후의 삽화는 모두 그 모습이 뚱뚱하고 심술궂게 그려져 있다. 또한 일본 외교관들은 그녀를 암여우()라고 불렀다.
나가사키현()은 일본 규슈 지방의 서쪽 끝에 있는 현이다. 고토 열도(), 쓰시마섬(), 이키섬()을 포함한다. 현청 소재지는 나가사키시이다.
동쪽으로 사가현과 접하고 있으며 나머지 주변은 모두 바다로 둘러싸여 있다. 크고 작은 섬들이 많으며 그 수는 971개로 전국 도도부현 가운데 가장 많으며, 도서부의 면적이 전 면적의 40%가량 된다. 해안선의 길이는 4,137km로 47개 도도부현 중 1위이다. 2위인 홋카이도는 2,978km로 나가사키현과 큰 차이가 난다.
면적이 홋카이도의 20분의 1에 불과한 나가사키의 해안선이 이렇게 긴 이유는 크고 작은 섬들이 상당히 많은 것과 리아스식 해안으로 인해 해안선이 복잡하게 구성되어 있기 때문이다. 이런 지형적 특징으로 인해 나가사키에는 83개에 이르는 항만이 소재한다. 나가사키현 내의 모든 지역은 해안선으로부터 15km 이내에 위치하고 있다.
남서쪽에서 난류인 쓰시마 해류()가 흘러오기 때문에 기후는 온난하고 기온차도 적다. 겨울에는 동중국해에 접한 지역을 중심으로 흐린 경우가 많다. 또 그 영향으로 눈이 많이 오는 편이다. 그러나 현 최북단의 쓰시마섬에서는 한반도가 바로 윗쪽에 있기 때문에 바다에서 발생한 눈구름이 한반도에 의해 차단되어 눈구름이 발달하지 못하여 눈이 상대적으로 적게 내린다.
생물학적으로는 해안에서 볼 수 있는 용나무 등의 아열대성 식물은 나가사키현의 온난한 기후를 반영하고 있다. 그 밖에도 대륙과 가깝기 때문에 쓰시마 산고양이()나 짱뚱어 등의 대륙계 생물종이 많고 각지의 낙도에서 수많은 아종, 변종이 확인된다.
시마바라 반도()는 활화산 지대이기 때문에 온천이 많다. 1990년~1995년의 운젠타케()의 분화는 시마바라시()와 후카에정()을 중심으로 큰 피해를 가져왔다. 동중국해에 접하기 때문에 태풍 상륙이 잦은 편이다.
옛날에는 히젠국(, 사가현과 이키·쓰시마를 제외한 나가사키현 전역), 쓰시마국(), 이키국()으로 나뉘어 있었지만 히젠의 중심지는 사가현 사가시()에 있었다. 17세기 에도 막부에 의한 해금령이 발표되면서 일본과 여타 국가와의 교섭이나 상업 활동은 나가사키현 일대에서만 허용되었다. 조선, 중국, 네덜란드와의 교역만이 허용되었다.
1637년 농민들과 천주교도들에 의해 시마바라의 난이 일어나기도 했다. 오늘날에도 나가사키현의 천주교 신자 비율은 다른 지역에 비해 훨씬 높다. 제2차 세계 대전 말기였던 1945년 8월 9일 오전 11시 2분 미국 공군 B-29 폭격기에 의해 우라카미 성당 상공에 원자폭탄이 투하되어 히로시마에 이어 두 번째 원자폭탄 투하지(혹은 피해지)가 되었다.
현청 소재지 나가사키시는 역사를 자랑하는 항만 도시로 관광객이 많다. 제2차 세계 대전 당시 일본 해군 전함 무사시를 건조한 조선업 도시이기도 하다. 사세보시는 옛날부터 군항이 있었으며 오늘날에도 해상자위대와 미군 제7함대의 기지가 있다. 남부에는 중세 유럽 도시를 본따 만든 하우스텐보스가 있어서 한국이나 대만에서 오는 관광객도 많다. 그 외 지역은 탄광, 저인망 어업 등이 번창하였으나 1970년대 이후 경쟁력을 잃어 쇠락하였다. 덧붙여 이키·쓰시마 지구는 행정 구역은 나가사키현이지만 후쿠오카와의 왕래가 더 편한 탓에 경제권은 후쿠오카에 속한다. 금융 기관으로는 후쿠오카 파이낸셜 그룹 계열의 은행사인 주하치 은행과 신와 은행이 거점 은행 역할을 하고 있다. 한국으로 따지자면 광주은행과 거의 비슷하다.
나가사키현의 남녀 성비는 87.3으로, 여자가 더 많다.
2000년 초에 AOL의 자회사인 널소프트의 저스틴 프랑켈(Justin Frankel)과 톰 페퍼(Tom Pepper)가 첫 번째 프로그램을 개발했다. 그 해 3월 14일 Nullsoft에서 파일을 내려받을 수 있었으며, Slashdot에 소개된 첫 날 수 천명이 프로그램을 내려 받았다. Nullsoft의 모회사인 아메리카 온라인(AOL)이 당시 음악/미디어 쪽의 거인인 타임 워너와 합병하려던 차였기 때문에 배포된 다음날 내려 받기는 중지된다.
하지만 이미 비밀은 누출되어 버린 뒤였다. Nullsoft가 올렸다가 지운 그 코드를 해커들이 낚아채서 이를 바탕으로 자신들만의 새로운 소프트웨어로 만들었다. 그 결과 불과 몇 주일 만에 웹 상에는 여러 종의 상호호환적인 누텔라 유사품이 등장한다.
누텔라는 냅스터와 달리 중앙에서 개입하는 부분이 전혀 없다. 2001년초 냅스터의 법정 공방으로 P2P 네트워크가 유명세를 타게 되고 누텔라는 많은 사용자를 확보하게 된다. 하지만 초기 프로토콜의 확장성 문제 (사용자가 많아질수록 다운로드가 어려워지는 문제)가 드러나게 된다. 개발자들이 확장성 문제를 극복하는 새로운 누텔라를 개발하며, 새로운 피어간 경로 설정 기법인 "ultrapeers" 개념을 제시한다.
"누텔라"는 특정한 프로젝트나 프로그램의 이름뿐만 아니라, 여러 클라이언트들에게 사용되는 일반적인 프로토콜의 의미를 갖기도 한다. 곳곳에서 새로운 클라이언트와 프로토콜들이 개발되고 있으므로, "누텔라"가 미래의 P2P 표준이 될 것이라는 장담은 할 수 없다.
Frankel과 Pepper는 누텔라를 개발하는 동안 Nutella(spread의 한 종류)를 많이 먹었고 소스를 GNU GPL 라이선스 하에 배포해서 "Gnutella"라는 이름이 탄생했다. 누텔라는 GNU 프로젝트와 연관이 없다.
동작 방식.
누텔라 네트워크에 참여하는 것은 어렵지 않다. 누텔라 소프트웨어 패키지 중 하나를 웹을 통해 다운로드한 다음 프로그램을 설치한 뒤, 누텔라 네트워크 상의 적어도 하나의 다른 노드를 찾아 연결하면 된다.
새로 누텔라 네트워크에 접속하고자 하는 노드 A와 기존에 누텔라에 접속해 있던 노드 B가 존재한다고 하자. 노드 A가 노드 B와의 연결을 완료하면 노드 B는 누텔라에 연결된 노드들의 주소를 노드 A에게 전송한다. 노드 A는 일정 수준 이상의 노드들(사용자가 상한선 결정)과 연결될 때까지 수동으로 설정한 주소와 다른 노드들이 전송해 준 노드들의 목록을 이웃으로 추가해 나간다. 연결을 시도해서 연결이 정상적으로 이루어진 노드만을 이웃으로 인정한다.
파일을 찾기 위해서 키워드를 치면, 그 요청은 자신과 가장 가까운 이웃 노드로 보내진다. 이 메시지를 받은 컴퓨터는 먼저 자신의 하드 디스크 드라이브를 뒤진 다음 맞는 것이 있으면 그 사실을 노드 A에게 알려주고 요청을 또 다른 노드로 다시 전송한다. 이걸 받은 노드는 또 똑같은 과정을 반복한다. 그 결과, 단 한 번의 요청이 순식간에 수천 대의 컴퓨터로 퍼져나갈 수 있다.
노드 A가 요청한 파일을 가지고 있는 노드는 노드 A와 직접 통신하여 전송여부를 결정한다. 만일 요청한 파일이 여러 노드에 동시에 존재한다면 노드 A는 분할 다운로드를 수행하여 다운로드 속도를 높인다. 한 번 이웃으로 등록된 노드들은 프로그램 종료후 다음에 다시 사용할 수 있다.
누텔라는 프로토콜이다. 누텔라 0.4 버전은 다섯가지의 패킷 유형을 제공한다.
현재 누텔라 프로토콜의 개발은 (Gnutella Developer Forum)에서 주도하며, 소프트웨어 벤더와 GDF의 개발자들에 의해 프로토콜의 개선이 이루어지고 있다. 개선 내용은 지능적인 질의 경로 설정, SHA checksums, 여러 노드로부터 동시에 내려받기(swarming)등이 있다.
현재 누텔라 프로토콜 개발 웹사이트에서는 누텔라 0.6 스펙을 마지막으로 프로토콜을 완성하려고 하고 있다. 0.4 버전은 오래된 프로토콜이지만 아직도 사용되고 있으며, 이를 막을 방법은 없다.
2003년 1월, 는 검색을 위해 TCP가 아닌 UDP를 사용하는 누텔라2 프로토콜을 발표했다. 누텔라 2는 패킷 포맷에 XML 기법을 적용하고 많은 확장 기능들을 포함한다. 하지만 누텔라2를 지원하는 다른 클라이언트는 Gnucleus뿐이며 누텔라 개발자들은 GDF의 승인을 받지 않은 누텔라 2를 인정하지 않는다.
포터블 네트워크 그래픽스(Portable Network Graphics; PNG, )는 손실 없는 데이터 압축을 지원하는 래스터 그래픽스 파일 형식이다. PNG는 GIF의 개선된, 특허 없는 대체 형식으로 개발되었다.
PNG는 팔레트 기반 이미지(RGB 24비트 또는 RGBA 32비트 색상의 팔레트 포함), 회색조 이미지(투명도용 알파 채널 유무에 관계없이), 그리고 풀 컬러 비팔레트 기반 RGB 또는 RGBA 이미지를 지원한다. PNG 워킹 그룹은 전문가 수준의 인쇄용 그래픽이 아닌 인터넷에서 이미지를 전송하기 위한 형식으로 PNG를 설계했기 때문에, CMYK와 같은 비-RGB 색 공간은 지원되지 않는다. PNG 파일은 기본 화소 및 텍스트 주석, 무결성 검사와 같은 기타 정보를 RFC 2083에 문서화된 청크의 확장 가능한 구조로 인코딩한 단일 이미지를 포함한다.
PNG 파일은 ".png" 파일 확장자와 "image/png" MIME 미디어 타입을 갖는다.
PNG는 1997년 3월 정보 RFC 2083으로, 2004년에는 ISO/IEC 15948 표준으로 발표되었다.
역사 및 개발.
PNG 형식 생성 동기는 1994년 12월 28일 GIF 형식 구현에 유니시스의 GIF에 사용된 Lempel-Ziv-Welch(LZW) 데이터 압축 알고리즘 특허로 인해 로열티를 지불해야 한다는 발표였다. 이로 인해 유즈넷 사용자들로부터 비난이 쇄도했다. 그 중 한 명인 토마스 부텔은 1995년 1월 4일 유즈넷 뉴스그룹 "comp.graphics"에 GIF의 무료 대안에 대한 계획을 세우는 선행 토론 스레드를 게시했다. 해당 스레드의 다른 사용자들은 나중에 최종 파일 형식의 일부가 될 많은 제안을 내놓았다. 인기 있는 JPEG 뷰어 QPEG의 저자 올리버 프롬은 PING이라는 이름을 제안했으며, 이는 결국 PNG가 되었고, 이는 PING is not GIF를 의미하는 재귀 약자이다. 그리고 .png 확장자도 제안했다. 나중에 구현된 다른 제안으로는 디플레이트 압축 알고리즘과 24비트 컬러 지원이 포함되었는데, GIF에서 후자가 없었던 것도 팀이 자체 파일 형식을 만들도록 동기를 부여했다. 이 그룹은 PNG 개발 그룹으로 알려지게 되었고, 논의가 빠르게 확장되면서 나중에는 컴퓨서브 포럼과 관련된 메일링 리스트를 사용했다.
PNG의 전체 사양은 1996년 10월 1일 월드 와이드 웹 컨소시엄 (W3C)의 승인 하에 발표되었고, 이후 1997년 1월 15일 RFC 2083으로 발표되었다. 이 사양은 1998년 12월 31일 버전 1.1으로 개정되었고, 감마 보정 및 색 보정에 대한 기술적 문제를 다루었다. 1999년 8월 11일 출시된 버전 1.2는 iTXt 청크를 사양의 유일한 변경 사항으로 추가했으며, 1.2의 재포맷된 버전은 2003년 11월 10일 W3C 표준의 두 번째 에디션으로, 2004년 3월 3일 국제 표준(ISO/IEC 15948:2004)으로 출시되었다.
GIF는 컴퓨터 애니메이션을 허용하지만, PNG는 처음에 단일 이미지 형식으로 결정되었다. 2001년에 PNG 개발자들은 애니메이션을 지원하는 멀티플 이미지 네트워크 그래픽스(MNG) 형식을 발표했다. MNG는 중간 정도의 애플리케이션 지원을 받았지만, 주류 웹 브라우저에서는 충분하지 않았고 웹 사이트 디자이너나 게시자들 사이에서는 전혀 사용되지 않았다. 2008년에 일부 모질라 개발자들은 비슷한 목표를 가진 APNG 형식을 발표했다. APNG는 게코 및 프레스토 기반 웹 브라우저에서 기본적으로 지원되는 형식이며, 소니의 플레이스테이션 포터블 시스템에서 썸네일로도 일반적으로 사용된다(일반 PNG 파일 확장자 사용). 2017년, 크로미엄 기반 브라우저가 APNG 지원을 채택했다. 2020년 1월, 마이크로소프트 엣지가 크로미엄 기반이 되면서 APNG 지원을 상속받았다. 이로써 모든 주요 브라우저가 이제 APNG를 지원한다.
PNG 워킹 그룹은 2021년 9월 14일부터 W3C의 승인을 받아 PNG 사양을 유지하고 개발하는 임무를 맡게 되었다. APNG, 높은 동적 범위(HDR) 및 Exif 데이터에 대한 적절한 지원을 추가한 PNG 사양의 세 번째 에디션은 2022년 10월 25일에 첫 번째 공개 작업 초안으로 그리고 2025년 6월 24일에 최종적으로 W3C 권고안으로 발표되었다.
PNG 워킹 그룹.
원래 PNG 사양은 컴퓨터 그래픽스 전문가 및 애호가로 구성된 임시 그룹이 작성했다. 형식에 대한 논의와 결정은 이메일로 진행되었다. RFC 2083에 나열된 원래 저자는 다음과 같다.
파일 헤더.
PNG 파일은 8바이트 시그니처로 시작한다. (오른쪽의 헥사 편집기 이미지 참조):
파일 내의 "청크".
헤더 다음에는 이미지에 대한 특정 정보를 전달하는 일련의 청크가 온다. 청크는 필수 또는 보조로 선언되며, 이해하지 못하는 보조 청크를 만난 프로그램은 이를 안전하게 무시할 수 있다. 이러한 청크 기반 저장 계층 구조는 컨테이너 형식 또는 아미가의 교환 파일 형식(IFF)과 개념적으로 유사하며, PNG 형식이 이전 버전과의 호환성을 유지하면서 확장될 수 있도록 설계되었다. 이는 상위 호환성을 제공하며, 동일한 파일 구조(다른 시그니처 및 청크 포함)는 관련 MNG, JNG, 및 APNG 형식에도 사용된다.
청크는 길이(4바이트, 빅 엔디언), 청크 타입/이름(4바이트), 청크 데이터(길이 바이트) 및 CRC(순환 중복 코드/체크섬; 4바이트)로 구성된다. CRC는 청크 타입과 청크 데이터에 대해 계산되지만 길이는 제외한 네트워크 바이트 순서의 CRC-32이다.
청크 타입은 네 글자의 대소문자 구분 ASCII 타입/이름으로 지정된다. FourCC와 비교한다. 이름의 다른 글자들의 대소문자(문자의 숫자 값의 비트 5)는 비트 필드로, 디코더에게 이해하지 못하는 청크의 성격에 대한 일부 정보를 제공한다.
첫 번째 글자의 대소문자는 청크가 필수인지 아닌지를 나타낸다. 첫 번째 글자가 대문자이면 청크는 필수이다. 그렇지 않으면 청크는 보조이다. 필수 청크는 파일을 읽는 데 필요한 정보를 포함한다. 디코더가 인식하지 못하는 필수 청크를 만나면 파일을 읽는 것을 중단하거나 사용자에게 적절한 경고를 제공해야 한다.
두 번째 글자의 대소문자는 청크가 "공개"(사양 또는 특수 목적 공개 청크 레지스트리에 있음)인지 "비공개"(표준화되지 않음)인지를 나타낸다. 대문자는 공개이고 소문자는 비공개이다. 이는 공개 및 비공개 청크 이름이 서로 충돌하지 않도록 보장한다(두 개의 비공개 청크 이름이 충돌할 수 있음).
세 번째 글자는 PNG 사양을 따르기 위해 대문자여야 한다. 이는 미래 확장을 위해 예약되어 있다. 디코더는 소문자 세 번째 글자를 가진 청크를 다른 인식되지 않는 청크와 동일하게 처리해야 한다.
네 번째 글자의 대소문자는 인식하지 못하는 편집기에 의해 청크가 안전하게 복사될 수 있는지 여부를 나타낸다. 소문자이면 파일에 대한 수정 정도에 관계없이 청크를 안전하게 복사할 수 있다. 대문자이면 수정 사항이 필수 청크를 건드리지 않은 경우에만 복사할 수 있다.
필수 청크.
디코더는 PNG 파일을 읽고 렌더링하기 위해 필수 청크를 해석할 수 있어야 한다.
월드 와이드 웹 컨소시엄에 명시된 대로, 비트 깊이는 "샘플당 또는 팔레트 인덱스당 비트 수(픽셀당 아님)"로 정의된다.
codice_2 청크는 컬러 타입 3 (인덱스 컬러)에 필수적이다. 컬러 타입 2와 6 (트루컬러 및 알파가 있는 트루컬러)에는 선택 사항이며, 컬러 타입 0과 4 (회색조 및 알파가 있는 회색조)에는 나타나서는 안 된다.
보조 청크.
PNG 파일에 저장될 수 있는 다른 이미지 속성으로는 감마 값, 배경색, 텍스트 메타데이터 정보가 있다. PNG는 또한 ICC 색상 프로파일을 포함하여 색 관리를 지원한다.
픽셀 형식.
PNG 이미지의 픽셀은 팔레트의 샘플 데이터 인덱스이거나 샘플 데이터 자체일 수 있는 숫자이다. 팔레트는 PLTE 청크에 포함된 별도의 테이블이다. 단일 화소의 샘플 데이터는 1개에서 4개 사이의 숫자 튜플로 구성된다. 픽셀 데이터가 팔레트 인덱스를 나타내든 명시적 샘플 값을 나타내든, 이 숫자들은 채널이라고 불리며 이미지의 모든 숫자는 동일한 형식으로 인코딩된다.
허용되는 형식은 각 숫자를 고정된 비트 수(PNG 사양에서는 비트 깊이라고 함)를 사용하여 부호 없는 정수 값으로 인코딩한다. 이는 일반적으로 각 채널이 아닌 각 픽셀의 총 비트 수를 나타내는 색 깊이와는 다르다. 허용되는 비트 깊이는 표에 각 픽셀에 사용되는 총 비트 수와 함께 요약되어 있다.
채널 수는 이미지가 회색조인지 색상인지, 그리고 알파 채널을 가지고 있는지 여부에 따라 달라진다. PNG는 컬러 타입이라고 불리는 다음과 같은 채널 조합을 허용한다.
색상 유형은 8비트 값으로 지정되지만 하위 3비트만 사용되며, 위에서 나열된 5가지 조합만 허용된다. 따라서 색상 유형이 유효하다면 인접한 표에 요약된 대로 비트 필드로 간주될 수 있다.
인덱스 색상 이미지의 경우, 팔레트는 항상 채널당 8비트(팔레트 항목당 24비트) 깊이로 삼색형 색상을 저장한다. 또한, 팔레트 항목에 대한 8비트 알파 값 목록을 선택적으로 포함할 수 있다. 포함되지 않거나 팔레트보다 짧은 경우, 나머지 팔레트 항목은 완전히 불투명한 것으로 간주된다. 팔레트는 이미지 비트 깊이가 허용하는 것보다 많은 항목을 가질 수 없지만, 더 적을 수 있다(예: 8비트 픽셀을 가진 이미지가 90가지 색상만 사용하는 경우 256가지 색상 모두에 대한 팔레트 항목이 필요하지 않음). 팔레트는 이미지에 존재하는 모든 픽셀 값에 대한 항목을 포함해야 한다.
표준은 인덱스 색상 PNG가 픽셀당 1, 2, 4 또는 8비트를 가질 수 있도록 허용한다. 알파 채널이 없는 회색조 이미지는 픽셀당 1, 2, 4, 8 또는 16비트를 가질 수 있다. 다른 모든 것은 채널당 비트 깊이를 8 또는 16으로 사용한다. 허용되는 조합은 위 표에 나와 있다. 표준은 디코더가 지원되는 모든 색상 형식을 읽을 수 있어야 한다고 요구하지만, 많은 이미지 편집기는 그 중 일부만 생성할 수 있다.
이미지의 투명도.
PNG는 다양한 투명도 옵션을 제공한다. 트루컬러 및 회색조 이미지의 경우 단일 픽셀 값을 투명하게 선언하거나 알파 채널을 추가할 수 있다(부분 투명도 사용 가능). 팔레트 이미지의 경우 팔레트 항목에 알파 값을 추가할 수 있다. 저장되는 이러한 값의 수는 총 팔레트 항목 수보다 적을 수 있으며, 이 경우 나머지 항목은 완전히 불투명한 것으로 간주된다.
이진 투명도를 위한 픽셀 값 스캔은 의도치 않게 픽셀이 투명해지는 것을 방지하기 위해 어떤 색상 감소보다 먼저 수행되어야 한다. 이는 16비트-채널 이미지를 디코딩할 수 있지만(사양 준수를 위해 필요) 채널당 8비트만 출력하는 시스템(최고급 시스템을 제외한 모든 시스템의 표준)에서 가장 큰 문제가 될 수 있다.
알파 저장은 "연관"(미리 곱셈) 또는 "비연관"일 수 있지만, PNG는 이미지에 알파 인코딩이 되어 있지 않음을 의미하는 "비연관"("비미리 곱셈") 알파를 표준화했다. 이는 오버 작업이 RGB 방출에 알파를 곱할 것이며, 방출과 폐색을 적절하게 나타낼 수 없음을 의미한다.
압축.
PNG는 두 단계 압축 과정을 사용한다.
PNG는 LZ77과 허프먼 코딩의 조합을 포함하는 특허가 없는 손실 없는 데이터 압축 알고리즘인 DEFLATE를 사용한다. 관대한 라이선스를 가진 DEFLATE 구현체는 널리 사용 가능하다.
JPEG와 같은 손실 압축 형식과 비교할 때, 평균보다 높은 압축 설정을 선택하면 처리 시간이 지연되지만 파일 크기가 크게 줄어들지는 않는 경우가 많다.
필터링.
DEFLATE를 적용하기 전에 데이터는 예측 방법을 통해 변환된다. 전체 이미지에 대해 단일 필터 방법이 사용되는 반면, 각 이미지 라인에 대해 데이터를 보다 효율적으로 압축할 수 있도록 필터 유형이 선택된다. 스캔라인에 사용되는 필터 유형은 인라인 압축 해제를 가능하게 하기 위해 스캔라인 앞에 추가된다.
현재 PNG 사양에는 하나의 필터 방법(방법 0으로 표시)만 있으며, 따라서 실제로는 각 줄에 어떤 필터 유형을 적용할지 선택하는 것뿐이다. 이 방법의 경우, 필터는 이전 인접 픽셀의 값을 기반으로 각 픽셀의 값을 예측하고, DPCM과 같이 예측된 픽셀 색상 값을 실제 값에서 뺀다. 이 방식으로 필터링된 이미지 줄은 원시 이미지 줄보다 더 압축 가능한 경우가 많다. 특히 위 줄과 유사한 경우, 예측과의 차이가 일반적으로 0 주변에 모여들고 가능한 모든 이미지 값에 퍼지지 않기 때문이다. 이는 DEFLATE가 이미지를 2D 개체로 이해하지 않고 단순히 바이트 스트림으로 보기 때문에 별도의 행을 연결하는 데 특히 중요하다.
필터 메서드 0에는 5가지 필터 유형이 있다. 각 유형은 왼쪽 픽셀(A), 위 픽셀(B), 왼쪽 위 픽셀(C) 또는 이들의 조합에 해당하는 바이트를 기반으로 각 바이트(필터링 전 이미지 데이터의) 값을 예측하고, 예측 값과 실제 값 간의 차이를 인코딩한다. 필터는 픽셀이 아닌 바이트 값에 적용된다. 픽셀 값은 1 또는 2바이트일 수 있거나 바이트당 여러 값일 수 있지만, 바이트 경계를 넘지 않는다. 필터 유형은 다음과 같다.
Paeth 필터는 앨런 W. 패스의 알고리즘을 기반으로 한다.
무손실 JPEG에서 사용되는 DPCM 버전과 1 × 2, 2 × 1 또는 (Paeth 예측기의 경우) 2 × 2 창 및 하르 웨이블릿을 사용하는 이산 웨이블릿 변환과 비교한다.
압축은 라인별로 필터 유형을 적응적으로 선택함으로써 더욱 향상된다. 이러한 개선과 PNG 작성 소프트웨어에서 일반적으로 사용되는 경험적 구현 방법은 리 다니엘 크로커에 의해 만들어졌으며, 그는 형식 생성 중에 많은 이미지에서 이러한 방법을 테스트했다. 필터 선택은 아래에서 논의하는 파일 크기 최적화의 구성 요소이다.
인터레이싱이 사용되는 경우, 인터레이싱의 각 단계는 별도로 필터링되어 각 단계가 수신됨에 따라 이미지가 점진적으로 렌더링될 수 있다. 그러나 인터레이싱은 일반적으로 압축 효율성을 떨어뜨린다.
인터레이싱.
PNG는 선택적인 2차원, 7패스 인터레이싱 스킴인 아담7 알고리즘을 제공한다. 이는 GIF의 1차원, 4패스 스킴보다 더 정교하며, 특히 쌍입방 보간법과 같은 보간 알고리즘이 사용될 경우 전송 초기에 더 선명한 저해상도 이미지를 볼 수 있게 한다.
그러나 7패스 스킴은 단순한 스킴보다 데이터의 압축성을 더 감소시키는 경향이 있다.
핵심 PNG 형식은 애니메이션을 지원하지 않는다. MNG는 PNG 그룹 구성원들이 설계한 PNG 확장으로 애니메이션을 지원한다. MNG는 PNG의 기본 구조와 청크를 공유하지만, 훨씬 더 복잡하며 표준 PNG 디코더와 호환되지 않는 다른 파일 시그니처를 가지고 있다. 이는 대부분의 웹 브라우저와 애플리케이션이 MNG를 지원하지 않거나 지원을 중단했다는 것을 의미한다.
MNG의 복잡성으로 인해 모질라 재단 개발자들이 APNG를 제안하게 되었다. APNG는 PNG를 기반으로 하며, 애니메이션을 지원하고 MNG보다 간단하다. APNG는 APNG를 지원하지 않는 PNG 디코더를 위해 단일 이미지 표시로 폴백 기능을 제공한다. 현재 APNG 형식은 모든 주요 웹 브라우저에서 지원된다. APNG는 Firefox 3.0 이상, Pale Moon (모든 버전), 그리고 Safari 8.0 이상에서 지원된다. 크로미엄 59.0은 APNG 지원을 추가했고, 이어서 구글 크롬도 지원했다. Opera는 10-12.1 버전에서 APNG를 지원했지만, 15버전에서 Blink 렌더링 엔진으로 전환하면서 지원이 중단되었다. 이후 Opera 46에서 재지원되었다(크로미엄 59에서 상속). 마이크로소프트 엣지는 크로미엄 기반 엔진으로 전환한 79.0 버전부터 APNG를 지원하고 있다.
PNG 그룹은 2007년 4월 APNG를 채택하지 않기로 결정했다. ANG, aNIM/mPNG, "PNG in GIF", 그리고 그 하위 집합인 "RGBA in GIF"를 포함한 여러 대안이 논의 중이었다. 그러나 현재는 APNG만이 널리 지원되고 있다.
2025년 6월 PNG 워킹 그룹에서 유지보수하는 PNG 사양의 세 번째 에디션이 출시되면서, APNG는 마침내 확장 기능으로 사양에 포함되었다.
헥사 편집기 방식으로 표시되며, 왼쪽에는 16진수 형식으로 바이트 값이 표시되고, 오른쪽에는 인식되지 않는 제어 문자가 점으로 대체된 ISO/IEC 8859-1 해당 문자가 표시된다. 또한 PNG 시그니처와 개별 청크는 색상으로 표시된다. 인간이 읽을 수 있는 타입 이름(이 예시에서는 PNG, IHDR, IDAT, IEND)으로 인해 쉽게 식별할 수 있다.
PNG를 사용하는 이유:
다른 파일 형식과의 비교.
PNG 이미지는 오래된 브라우저에서 덜 널리 지원된다. 특히 IE6은 PNG를 제한적으로 지원한다.
JPEG.
JPEG (Joint Photographic Experts Group) 형식은 사진 (및 사진과 유사한) 이미지의 경우 PNG보다 더 작은 파일을 생성할 수 있다. JPEG는 일반적으로 부드럽고 대비가 낮은 전환과 어느 정도의 노이즈 또는 유사한 불규칙한 구조가 지배적인 사진 이미지 데이터를 위해 특별히 설계된 손실 인코딩 방식을 사용하기 때문이다. 이러한 이미지에 고품질 JPEG 대신 PNG를 사용하면 파일 크기가 크게 증가하고 품질 향상은 무시할 수준이 된다. 이에 비해, 텍스트, 선화 또는 그래픽(선명한 전환과 넓은 단색 영역이 있는 이미지)을 포함하는 이미지를 저장할 때는 PNG 형식이 JPEG보다 이미지 데이터를 더 많이 압축할 수 있다. 또한 PNG는 무손실인 반면 JPEG는 고대비 영역 주변에 시각적 아티팩트를 생성한다. (이러한 아티팩트는 JPG 압축에 사용되는 설정에 따라 달라지며, 낮은 품질[높은 압축] 설정이 사용될 때 상당히 눈에 띌 수 있다.) 이미지가 선명한 전환과 사진 부분을 모두 포함하는 경우, 두 가지 효과 중에서 선택해야 한다. JPEG는 투명도를 지원하지 않는다.
JPEG의 손실 압축은 또한 세대 손실을 겪는다. 이미지를 저장하기 위해 반복적으로 디코딩하고 재인코딩하면 매번 정보 손실이 발생하여 이미지가 저하된다. PNG는 무손실이므로 편집할 이미지를 저장하는 데 적합하다. PNG는 사진 이미지를 압축할 때 합리적으로 효율적이지만, 사진 이미지를 위해 특별히 설계된 무손실 압축 형식, 예를 들어 무손실 WebP 및 Adobe DNG (디지털 네거티브)도 있다. 그러나 이러한 형식은 널리 지원되지 않거나 독점적이다. 이미지를 무손실로 저장하고 배포용으로만 JPEG 형식으로 변환할 수 있으므로 세대 손실이 발생하지 않는다.
PNG 사양은 디지털 카메라와 같은 소스에서 Exif 이미지 데이터를 포함하는 표준을 명시적으로 포함하지 않지만, PNG에 EXIF 데이터를 포함하는 선호되는 방법은 비필수 보조 청크 레이블인 codice_10를 사용하는 것이다.
초기 웹 브라우저는 PNG 이미지를 지원하지 않았다. JPEG와 GIF가 주요 이미지 형식이었다. JPEG는 GIF의 제한된 색상 깊이 때문에 웹 페이지용 그라데이션이 포함된 이미지를 내보낼 때 일반적으로 사용되었다. 그러나 JPEG 압축은 그라데이션을 약간 흐리게 만든다. PNG 형식은 주어진 비트 깊이에 대해 그라데이션을 가능한 한 정확하게 재현하면서 파일 크기를 작게 유지한다. 웹 브라우저의 형식 지원이 향상되면서 PNG는 작은 그라데이션 이미지에 최적의 선택이 되었다. 최신 브라우저에서는 CSS를 사용하여 그라데이션을 생성할 수 있으므로 그라데이션을 표시하기 위해 이미지가 전혀 필요하지 않다.
JPEG-LS.
JPEG-LS는 Joint Photographic Experts Group의 이미지 형식이지만, 위에서 논의된 다른 손실 JPEG 형식보다 훨씬 덜 알려져 있고 지원된다. 이는 PNG와 직접 비교할 수 있으며, 표준 테스트 이미지 세트를 가지고 있다. JPEG-LS는 워털루 레퍼토리 컬러세트(JPEG-LS 적합성 테스트 세트와 관련 없는 표준 테스트 이미지 세트)에서 일반적으로 PNG보다 10-15% 더 나은 성능을 보이지만, 일부 이미지에서는 PNG가 50-75% 더 우수한 성능을 보인다. 따라서 이 두 형식이 모두 옵션이고 파일 크기가 중요한 기준이라면 이미지에 따라 둘 다 고려해야 한다.
JPEG XL은 PNG와 같은 비손실 형식을 대체하기 위해 개발된 또 다른, 훨씬 개선된, 비손실 또는 손실 형식으로, 안타깝게도 지원이 훨씬 적다. JPEG XL은 JPEG보다 50% 이상 작으며, 비손실일 때도 이렇게 작을 수 있으므로 PNG보다도 더 작다. 또한 높은 동적 범위, 넓은 색 영역, 그리고 큰 색 깊이를 지원한다. JPEG XL은 또한 디코딩 효율성이 매우 뛰어나며, 대체하려는 형식에서 부드러운 전환을 제공하고, JPEG에서 손실 없이 변환할 수 있다. 또한 충실도를 손상시키지 않고 압축하는 데 탁월하다.
TIFF.
태그 이미지 파일 형식(TIFF)은 매우 광범위한 옵션을 포함하는 형식이다. 이는 TIFF를 전문 이미지 편집 응용 프로그램 간의 일반적인 교환 형식으로 유용하게 만들지만, 응용 프로그램에 대한 지원을 추가하는 것을 훨씬 더 큰 작업으로 만들고 따라서 이미지 조작과 관련 없는 응용 프로그램(예: 웹 브라우저)에서는 거의 지원되지 않는다. 높은 확장성 수준은 또한 대부분의 응용 프로그램이 가능한 기능의 일부만 제공하여 사용자 혼란 및 호환성 문제를 잠재적으로 야기한다는 것을 의미한다.
TIFF와 함께 사용되는 가장 일반적인 범용 비손실 압축 알고리즘은 Lempel-Ziv-Welch(LZW)이다. 이 압축 기술은 GIF에서도 사용되었으며 2003년까지 특허에 의해 보호되었다. TIFF는 PNG가 사용하는 압축 알고리즘(즉, 압축 태그 000816 '어도비 스타일')도 중간 정도의 사용률과 응용 프로그램 지원을 제공한다. TIFF는 또한 CCITT 그룹 IV와 같은 특수 목적의 비손실 압축 알고리즘을 제공하며, 이는 PNG의 압축 알고리즘보다 바이너리 이미지(예: 팩스 또는 흑백 텍스트)를 더 잘 압축할 수 있다.
PNG는 미리 곱셈이 없는 알파만 지원하는 반면 TIFF는 "연관"(미리 곱셈) 알파도 지원한다.
WebP.
WebP는 구글이 개발한 형식으로, PNG, JPEG, GIF를 대체하기 위해 고안되었다. WebP 파일은 손실 및 비손실 압축을 모두 허용하는 반면, PNG는 비손실 압축만 허용한다. WebP는 또한 애니메이션을 지원하며, 이는 이전에 GIF 파일만 가능했던 기능이었다.
그러나 WebP가 PNG보다 주요 개선점은 파일 크기가 크게 줄어들어 웹사이트에 삽입될 때 로딩 시간이 빨라진다는 것이다. 구글은 비손실 WebP 이미지가 PNG 파일보다 26% 더 작다고 주장한다.
WebP는 PNG와 달리 다양한 이미지 편집 프로그램 및 소셜 미디어 웹사이트와의 호환성 문제로 비판을 받아왔다. 또한 WebP는 모든 웹 브라우저에서 지원되지 않아 웹 이미지 호스팅 업체에서 사용자에게 표시할 대체 이미지를 생성해야 할 수 있으며, 이는 WebP의 잠재적인 저장 공간 절약을 무효화한다.
AVIF.
AVIF는 오픈 미디어 연합이 개발한 이미지 형식이다. AVIF는 PNG, GIF, WebP를 포함한 다른 이미지 코덱의 단점을 보완하기 위해 재단에서 설계되었다.
AVIF는 일반적으로 WebP와 PNG보다 크기가 작다. AVIF는 PNG가 지원하지 않는 애니메이션을 지원한다.
그러나 WebP와 마찬가지로 AVIF는 PNG보다 적은 응용 프로그램에서 지원된다.
소프트웨어 지원.
PNG 형식의 공식 참조 구현은 프로그래밍 라이브러리 libpng이다. 이는 관대한 자유 소프트웨어 라이선스 조건에 따라 자유 소프트웨어로 게시된다. 따라서 일반적으로 자유 운영 체제에서 중요한 시스템 라이브러리로 발견된다.
비트맵 그래픽 편집기의 PNG 지원.
PNG 형식은 어도비 포토샵, 코렐의 Photo-Paint 및 Paint Shop Pro, 김프, 그래픽컨버터, 헬리콘 필터, 이미지매직, 잉크스케이프, 이르판뷰, Pixel 이미지 편집기, Paint.NET 및 Xara Photo &amp; Graphic Designer 등 많은 그래픽 프로그램(온라인 그래픽 디자인 플랫폼 Canva 포함)에서 널리 지원된다. 인기 있는 운영체제에 번들로 제공되는 일부 PNG 지원 프로그램으로는 마이크로소프트의 Paint와 애플의 Photos/아이포토 및 Preview가 있으며, 김프도 인기 있는 리눅스 배포판에 자주 번들로 제공된다.
어도비 파이어웍스(이전 매크로미디어)는 PNG를 기본 파일 형식으로 사용하여 다른 이미지 편집기 및 미리보기 유틸리티가 플랫 이미지(flattened image)를 볼 수 있게 한다. 그러나 파이어웍스는 기본적으로 레이어, 애니메이션, 벡터 데이터, 텍스트 및 효과에 대한 메타데이터도 저장한다. 이러한 파일은 직접 배포되어서는 안 된다. 파이어웍스는 웹 페이지 등에서 사용할 수 있도록 추가 메타데이터가 없는 최적화된 PNG로 이미지를 내보낼 수 있다.
웹 브라우저의 PNG 지원.
PNG 지원은 1997년에 처음 등장했으며, 인터넷 익스플로러 4.0b1(NT용 32비트 전용) 및 넷스케이프 4.04에서 지원되었다.
자유 소프트웨어 재단과 월드 와이드 웹 컨소시엄 (W3C)의 요청에도 불구하고, gif2png와 같은 도구와 Burn All GIFs와 같은 캠페인에도 불구하고, 인터넷 익스플로러의 늦고 버그가 있는 지원, 특히 투명도와 관련하여 웹사이트에서의 PNG 채택은 상당히 느렸다. PNG는 2018년부터 웹에서 가장 많이 사용되는 이미지 파일 형식이다.
PNG 호환 브라우저에는 Apple Safari, 구글 크롬, 모질라 파이어폭스, Opera, 카미노, 인터넷 익스플로러, 마이크로소프트 엣지, 그리고 다른 많은 브라우저가 포함된다. 전체 비교는 웹 브라우저 비교 (이미지 형식 지원)를 참조하라.
특히 9.0 (2011년 출시) 이전 버전의 인터넷 익스플로러 (윈도우)는 PNG 이미지를 올바르게 렌더링하지 못하게 하는 수많은 문제를 가지고 있었다.
PNG 아이콘의 운영체제 지원.
PNG 아이콘은 1999년부터 리눅스 대부분의 배포판에서 그놈과 같은 데스크톱 환경에서 지원되었다. 2006년에는 마이크로소프트 윈도우에서 PNG 아이콘 지원이 윈도우 비스타에 도입되었다. PNG 아이콘은 아미가OS 4, AROS, MacOS, IOS, 모르프OS에서도 지원된다. 또한 안드로이드는 PNG를 광범위하게 사용한다.
파일 크기 및 최적화 소프트웨어.
PNG 파일 크기는 인코딩 및 압축 방식에 따라 크게 달라질 수 있다. 이에 대한 논의와 몇 가지 팁은 PNG: The Definitive Guide에 나와 있다.
GIF와 비교.
GIF 파일과 비교할 때, 동일한 정보(256색, 보조 청크/메타데이터 없음)를 가진 PNG 파일은 효율적인 압축기로 압축하면 일반적으로 GIF 이미지보다 크기가 작다. 파일과 압축기에 따라 PNG는 약간 작거나(10%), 상당히 작거나(50%), 약간 클 수도(5%) 있지만, 큰 이미지에서는 거의 상당히 크지 않다. 이는 GIF의 LZW에 비해 PNG의 DEFLATE 성능과, PNG의 예측 필터의 추가 사전 압축 계층이 2차원 이미지 구조를 고려하여 파일을 추가로 압축하기 때문이다. 필터링된 데이터는 픽셀 간의 차이를 인코딩하므로, 가능한 모든 이미지 값에 분산되기보다 0 주변에 모이는 경향이 있어 DEFLATE에 의해 더 쉽게 압축된다. 그러나 어도비 포토샵, 코렐드로, MS Paint의 일부 버전은 PNG 압축이 좋지 않아 GIF가 더 효율적이라는 인상을 줄 수 있다.
파일 크기 요인.
PNG 파일 크기는 여러 요인에 따라 달라진다.
따라서 높은 색 깊이, 최대 메타데이터(색 공간 정보 및 디스플레이에 영향을 미치지 않는 정보 포함), 인터레이싱, 압축 속도(모두 큰 파일을 생성함)와 낮은 색 깊이, 적거나 없는 보조 청크, 인터레이싱 없음, 튜닝되었지만 계산 집약적인 필터링 및 압축 간에는 파일 크기 트레이드오프가 있다. 다른 목적을 위해 다른 트레이드오프가 선택된다. 최대 파일은 아카이빙 및 편집에 가장 적합할 수 있고, 스트립다운된 파일은 웹사이트 사용에 가장 적합할 수 있으며, 마찬가지로 빠르지만 압축률이 낮은 압축은 파일을 반복적으로 편집하고 저장할 때 선호되는 반면, 느리지만 압축률이 높은 압축은 파일이 안정적일 때(아카이빙 또는 게시할 때) 선호된다.
인터레이싱은 트레이드오프이다. 대용량 파일의 초기 렌더링 속도를 극적으로 높이지만(대기 시간 개선), 특히 작은 파일의 경우 파일 크기를 증가시킬 수 있다(처리량 감소).
손실 PNG 압축.
PNG는 무손실 형식임에도 불구하고, PNG 인코더는 PNG 압축을 개선하기 위해 손실 방식으로 이미지 데이터를 전처리할 수 있다. 예를 들어, 트루컬러 PNG를 256색으로 양자화하면 인덱스 색상 유형을 사용하여 파일 크기를 줄일 수 있다.
이미지 편집 소프트웨어.
일부 프로그램은 PNG 파일을 저장할 때 다른 프로그램보다 효율적이다. 이는 프로그램에서 사용되는 PNG 압축 구현과 관련이 있다.
많은 그래픽 프로그램(예: 애플의 Preview 소프트웨어)은 웹 보기에 일반적으로 불필요한 많은 메타데이터 및 색 보정 데이터를 포함하여 PNG를 저장한다. 어도비 파이어웍스에서 최적화되지 않은 PNG 파일도 이미지 편집 가능한 옵션을 포함하므로 악명 높다. 또한 코렐드로(최소 11버전)는 때때로 인터넷 익스플로러(6-8버전)에서 열리지 않는 PNG를 생성한다.
어도비 포토샵의 PNG 파일 성능은 웹용 저장 기능(명시적인 PNG/8 사용도 허용)을 사용할 때 CS Suite에서 향상되었다.
어도비 파이어웍스는 기본적으로 다른 많은 프로그램보다 큰 PNG 파일을 저장한다. 이는 저장 형식의 메커니즘에서 비롯된다. 파이어웍스의 저장 기능으로 생성된 이미지에는 완전한 레이어 및 벡터 정보를 포함하는 크고 비공개적인 청크가 포함된다. 이는 추가 무손실 편집을 가능하게 한다. 내보내기 옵션으로 저장될 때, 파이어웍스의 PNG는 다른 이미지 편집기에서 생성된 PNG와 경쟁할 수 있지만, 플랫 비트맵 외에는 편집할 수 없다. 파이어웍스는 크기가 최적화된 벡터 편집 가능한 PNG를 저장할 수 없다.
PNG 압축 성능이 좋지 않은 다른 주목할 만한 예는 다음과 같다.
압축 불량은 PNG 파일 크기를 증가시키지만, 이미지 품질이나 다른 프로그램과의 파일 호환성에는 영향을 미치지 않는다.
트루컬러 이미지의 색 깊이를 8비트 팔레트로 줄이면(GIF에서처럼), 결과 이미지 데이터는 일반적으로 훨씬 더 작아진다. 따라서 트루컬러 PNG는 일반적으로 색상이 줄어든 GIF보다 크지만, PNG는 색상이 줄어든 버전을 비슷한 크기의 팔레트 파일로 저장할 수 있다. 반대로, 일부 도구는 이미지를 PNG로 저장할 때, 원본 데이터가 8비트 색상만 사용하더라도 자동으로 트루컬러로 저장하여 파일을 불필요하게 부풀린다. 이 두 가지 요인 모두 PNG 파일이 동등한 GIF 파일보다 크다는 오해를 불러일으킬 수 있다.
최적화 도구.
PNG 파일을 최적화하는 데 사용할 수 있는 다양한 도구가 있다. 이들은 다음을 통해 이를 수행한다.
도구 목록.
이들의 기능에 대한 간단한 비교는 아래에 나열되어 있다.