hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
나가사키현 경제
현청 소재지 나가사키시는 역사를 자랑하는 항만 도시로 관광객이 많다. 제2차 세계 대전 당시 일본 해군 전함 무사시를 건조한 조선업 도시이기도 하다. 사세보시는 옛날부터 군항이 있었으며 오늘날에도 해상자위대와 미군 제7함대의 기지가 있다. 남부에는 중세 유럽 도시를 본따 만든 하우스텐보스가 있어서 한국이나 대만에서 오는 관광객도 많다. 그 외 지역은 탄광, 저인망 어업 등이 번창하였으나 1970년대 이후 경쟁력을 잃어 쇠락하였다. 덧붙여 이키·쓰시마 지구는 행정 구역은 나가사키현이지만 후쿠오카와의 왕래가 더 편한 탓에 경제권은 후쿠오카에 속한다. 금융 기관으로는 후쿠오카 파이낸셜 그룹 계열의 은행사인 주하치 은행과 신와 은행이 거점 은행 역할을 하고 있다. 한국으로 따지자면 광주은행과 거의 비슷하다.
나가사키현 지역
나가사키현의 남녀 성비는 87.3으로, 여자가 더 많다.
미나미타카키군(南高来郡)
가즈사정(加津佐町) - 구니미정(国見町) - 구치노쓰정(口之津町) - 기타아리마정(北有馬町) - 니시아리에정(西有家町) - 미나미아리마정(南有馬町) - 미나미쿠시야마정(南串山町) - 미즈호정(瑞穂町) - 아리에정(有家町) - 아이노정(愛野町) - 아즈마정(吾妻町]] - 오바마정(小浜町) - 지지와정(千々石町) - 후쓰정(布津町) - 후카에정(深江町)
나가사키현 교통
국도
국도 제34호선
국도 제35호선
국도 제57호선
국도 제202호선
국도 제204호선 (일본)
국도 제205호선
국도 제206호선 (일본)
국도 제207호선 (일본)
국도 제251호선 (일본)
국도 제324호선 (일본)
국도 제382호선
국도 제383호선 (일본)
국도 제384호선 (일본)
국도 제389호선 (일본)
국도 제444호선 (일본)
국도 제498호선 (일본)
국도 제499호선
그누텔라 역사
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 프로젝트와 연관이 없다.
그누텔라 동작 방식
누텔라 네트워크에 참여하는 것은 어렵지 않다. 누텔라 소프트웨어 패키지 중 하나를 웹을 통해 다운로드한 다음 프로그램을 설치한 뒤, 누텔라 네트워크 상의 적어도 하나의 다른 노드를 찾아 연결하면 된다.
누텔라 노드를 찾는 방법은 클라이언트 프로그램에 미리 등록되어 있는 노드를 이용하는 방법, "Gwebcache"를 이용하는 방법, 그리고 IRC 채팅방에서 찾는 방법이 있다.
새로 누텔라 네트워크에 접속하고자 하는 노드 A와 기존에 누텔라에 접속해 있던 노드 B가 존재한다고 하자. 노드 A가 노드 B와의 연결을 완료하면 노드 B는 누텔라에 연결된 노드들의 주소를 노드 A에게 전송한다. 노드 A는 일정 수준 이상의 노드들(사용자가 상한선 결정)과 연결될 때까지 수동으로 설정한 주소와 다른 노드들이 전송해 준 노드들의 목록을 이웃으로 추가해 나간다. 연결을 시도해서 연결이 정상적으로 이루어진 노드만을 이웃으로 인정한다.
그누텔라 동작 방식
파일을 찾기 위해서 키워드를 치면, 그 요청은 자신과 가장 가까운 이웃 노드로 보내진다. 이 메시지를 받은 컴퓨터는 먼저 자신의 하드 디스크 드라이브를 뒤진 다음 맞는 것이 있으면 그 사실을 노드 A에게 알려주고 요청을 또 다른 노드로 다시 전송한다. 이걸 받은 노드는 또 똑같은 과정을 반복한다. 그 결과, 단 한 번의 요청이 순식간에 수천 대의 컴퓨터로 퍼져나갈 수 있다.
노드 A가 요청한 파일을 가지고 있는 노드는 노드 A와 직접 통신하여 전송여부를 결정한다. 만일 요청한 파일이 여러 노드에 동시에 존재한다면 노드 A는 분할 다운로드를 수행하여 다운로드 속도를 높인다. 한 번 이웃으로 등록된 노드들은 프로그램 종료후 다음에 다시 사용할 수 있다.
그누텔라 프로토콜의 특징과 확장
누텔라는 질의 플러딩 프로토콜이다. 누텔라 0.4 버전은 다섯가지의 패킷 유형을 제공한다.
패킷 유형들은 주소 누텔라 네트워크를 찾는 것과 관련되어 있고, 파일 전송은 HTTP를 통해 이루어진다.
현재 누텔라 프로토콜의 개발은 GDF(Gnutella Developer Forum)에서 주도하며, 소프트웨어 벤더와 GDF의 개발자들에 의해 프로토콜의 개선이 이루어지고 있다. 개선 내용은 지능적인 질의 경로 설정, SHA checksums, 여러 노드로부터 동시에 내려받기(swarming)등이 있다.
현재 누텔라 프로토콜 개발 웹사이트에서는 누텔라 0.6 스펙을 마지막으로 프로토콜을 완성하려고 하고 있다. 0.4 버전은 오래된 프로토콜이지만 아직도 사용되고 있으며, 이를 막을 방법은 없다.
2003년 1월, Shareaza는 검색을 위해 TCP가 아닌 UDP를 사용하는 누텔라2 프로토콜을 발표했다. 누텔라 2는 패킷 포맷에 XML 기법을 적용하고 많은 확장 기능들을 포함한다. 하지만 누텔라2를 지원하는 다른 클라이언트는 Gnucleus뿐이며 누텔라 개발자들은 GDF의 승인을 받지 않은 누텔라 2를 인정하지 않는다.
PNG
포터블 네트워크 그래픽스(Portable Network Graphics; PNG, /pɪŋ/)는 손실 없는 데이터 압축을 지원하는 래스터 그래픽스 파일 형식이다. 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 역사 및 개발
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 역사 및 개발
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)으로 출시되었다.
PNG 역사 및 개발
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 워킹 그룹
원래 PNG 사양은 컴퓨터 그래픽스 전문가 및 애호가로 구성된 임시 그룹이 작성했다. 형식에 대한 논의와 결정은 이메일로 진행되었다. RFC 2083에 나열된 원래 저자는 다음과 같다.
저자 (성별 알파벳순): 마크 애들러, 토마스 부텔, 크리스천 브룬첸, 애덤 M. 코스텔로, 리 다니엘 크로커, 안드레아스 딜거, 올리버 프롬, 장-루 가일리, 크리스 허보스, 알렉스 야쿨린, 닐 케틀러, 톰 레인, 알렉산더 레만, 크리스 릴리, 데이브 마틴데일, 오웬 모텐센, 키스 S. 피켄스, 로버트 P. 풀, 글렌 랜더스-페어슨, 그레그 로엘프스, 빌렘 반 스하이크, 가이 샬나트, 폴 슈미트, 팀 웨그너, 제레미 볼
PNG 파일 형식
PNG 파일은 8바이트 시그니처로 시작한다. (오른쪽의 헥사 편집기 이미지 참조):
헤더 다음에는 이미지에 대한 특정 정보를 전달하는 일련의 청크가 온다. 청크는 필수 또는 보조로 선언되며, 이해하지 못하는 보조 청크를 만난 프로그램은 이를 안전하게 무시할 수 있다. 이러한 청크 기반 저장 계층 구조는 컨테이너 형식 또는 아미가'의 교환 파일 형식(IFF)과 개념적으로 유사하며, PNG 형식이 이전 버전과의 호환성을 유지하면서 확장될 수 있도록 설계되었다. 이는 상위 호환성을 제공하며, 동일한 파일 구조(다른 시그니처 및 청크 포함)는 관련 MNG, JNG, 및 APNG 형식에도 사용된다.
청크는 길이(4바이트, 빅 엔디언), 청크 타입/이름(4바이트), 청크 데이터(길이 바이트) 및 CRC(순환 중복 코드/체크섬; 4바이트)로 구성된다. CRC는 청크 타입과 청크 데이터에 대해 계산되지만 길이는 제외한 네트워크 바이트 순서의 CRC-32이다.
PNG 파일 형식
청크 타입은 네 글자의 대소문자 구분 ASCII 타입/이름으로 지정된다. FourCC와 비교한다. 이름의 다른 글자들의 대소문자(문자의 숫자 값의 비트 5)는 비트 필드로, 디코더에게 이해하지 못하는 청크의 성격에 대한 일부 정보를 제공한다.
첫 번째 글자의 대소문자는 청크가 필수인지 아닌지를 나타낸다. 첫 번째 글자가 대문자이면 청크는 필수이다. 그렇지 않으면 청크는 보조이다. 필수 청크는 파일을 읽는 데 필요한 정보를 포함한다. 디코더가 인식하지 못하는 필수 청크를 만나면 파일을 읽는 것을 중단하거나 사용자에게 적절한 경고를 제공해야 한다.
두 번째 글자의 대소문자는 청크가 "공개"(사양 또는 특수 목적 공개 청크 레지스트리에 있음)인지 "비공개"(표준화되지 않음)인지를 나타낸다. 대문자는 공개이고 소문자는 비공개이다. 이는 공개 및 비공개 청크 이름이 서로 충돌하지 않도록 보장한다(두 개의 비공개 청크 이름이 충돌할 수 있음).
세 번째 글자는 PNG 사양을 따르기 위해 대문자여야 한다. 이는 미래 확장을 위해 예약되어 있다. 디코더는 소문자 세 번째 글자를 가진 청크를 다른 인식되지 않는 청크와 동일하게 처리해야 한다.
PNG 파일 형식
네 번째 글자의 대소문자는 인식하지 못하는 편집기에 의해 청크가 안전하게 복사될 수 있는지 여부를 나타낸다. 소문자이면 파일에 대한 수정 정도에 관계없이 청크를 안전하게 복사할 수 있다. 대문자이면 수정 사항이 필수 청크를 건드리지 않은 경우에만 복사할 수 있다.
디코더는 PNG 파일을 읽고 렌더링하기 위해 필수 청크를 해석할 수 있어야 한다.
IHDR은 첫 번째 청크여야 하며, 다음 정보를 (이 순서대로) 포함한다.
너비 (4바이트)
높이 (4바이트)
비트 깊이 (1바이트, 값 1, 2, 4, 8 또는 16)
컬러 타입 (1바이트, 값 0, 2, 3, 4 또는 6)
압축 방식 (1바이트, 값 0)
필터 방식 (1바이트, 값 0)
인터레이스 방식 (1바이트, 값 0 "인터레이스 없음" 또는 1 "아담7 인터레이스") (총 13 데이터 바이트).
월드 와이드 웹 컨소시엄에 명시된 대로, 비트 깊이는 "샘플당 또는 팔레트 인덱스당 비트 수(픽셀당 아님)"로 정의된다.
PNG 파일 형식
PLTE 청크는 컬러 타입 3 (인덱스 컬러)에 필수적이다. 컬러 타입 2와 6 (트루컬러 및 알파가 있는 트루컬러)에는 선택 사항이며, 컬러 타입 0과 4 (회색조 및 알파가 있는 회색조)에는 나타나서는 안 된다.
PNG 파일에 저장될 수 있는 다른 이미지 속성으로는 감마 값, 배경색, 텍스트 메타데이터 정보가 있다. PNG는 또한 ICC 색상 프로파일을 포함하여 색 관리를 지원한다.
tEXt는 ISO/IEC 8859-1로 표현될 수 있는 텍스트를 저장할 수 있으며, 각 청크에 대해 하나의 키-값 쌍을 갖는다. "키"는 1자에서 79자 사이여야 한다. 구분자는 널 문자이다. "값"은 키워드 길이와 구분자를 제외한 최대 청크 크기까지 임의의 길이를 가질 수 있으며, 0바이트일 수도 있다. "키"와 "값" 모두 널 문자를 포함할 수 없다. 선행 또는 후행 공백도 허용되지 않는다.
PNG 파일 형식
PNG 이미지의 픽셀은 팔레트의 샘플 데이터 인덱스이거나 샘플 데이터 자체일 수 있는 숫자이다. 팔레트는 PLTE 청크에 포함된 별도의 테이블이다. 단일 화소의 샘플 데이터는 1개에서 4개 사이의 숫자 튜플로 구성된다. 픽셀 데이터가 팔레트 인덱스를 나타내든 명시적 샘플 값을 나타내든, 이 숫자들은 채널이라고 불리며 이미지의 모든 숫자는 동일한 형식으로 인코딩된다.
허용되는 형식은 각 숫자를 고정된 비트 수(PNG 사양에서는 비트 깊이라고 함)를 사용하여 부호 없는 정수 값으로 인코딩한다. 이는 일반적으로 각 채널이 아닌 각 픽셀의 총 비트 수를 나타내는 색 깊이와는 다르다. 허용되는 비트 깊이는 표에 각 픽셀에 사용되는 총 비트 수와 함께 요약되어 있다.
채널 수는 이미지가 회색조인지 색상인지, 그리고 알파 채널을 가지고 있는지 여부에 따라 달라진다. PNG는 컬러 타입이라고 불리는 다음과 같은 채널 조합을 허용한다.
색상 유형은 8비트 값으로 지정되지만 하위 3비트만 사용되며, 위에서 나열된 5가지 조합만 허용된다. 따라서 색상 유형이 유효하다면 인접한 표에 요약된 대로 비트 필드로 간주될 수 있다.
PNG 파일 형식
인덱스 색상 이미지의 경우, 팔레트는 항상 채널당 8비트(팔레트 항목당 24비트) 깊이로 삼색형 색상을 저장한다. 또한, 팔레트 항목에 대한 8비트 알파 값 목록을 선택적으로 포함할 수 있다. 포함되지 않거나 팔레트보다 짧은 경우, 나머지 팔레트 항목은 완전히 불투명한 것으로 간주된다. 팔레트는 이미지 비트 깊이가 허용하는 것보다 많은 항목을 가질 수 없지만, 더 적을 수 있다(예: 8비트 픽셀을 가진 이미지가 90가지 색상만 사용하는 경우 256가지 색상 모두에 대한 팔레트 항목이 필요하지 않음). 팔레트는 이미지에 존재하는 모든 픽셀 값에 대한 항목을 포함해야 한다.
표준은 인덱스 색상 PNG가 픽셀당 1, 2, 4 또는 8비트를 가질 수 있도록 허용한다. 알파 채널이 없는 회색조 이미지는 픽셀당 1, 2, 4, 8 또는 16비트를 가질 수 있다. 다른 모든 것은 채널당 비트 깊이를 8 또는 16으로 사용한다. 허용되는 조합은 위 표에 나와 있다. 표준은 디코더가 지원되는 모든 색상 형식을 읽을 수 있어야 한다고 요구하지만, 많은 이미지 편집기는 그 중 일부만 생성할 수 있다.
PNG 파일 형식
PNG는 다양한 투명도 옵션을 제공한다. 트루컬러 및 회색조 이미지의 경우 단일 픽셀 값을 투명하게 선언하거나 알파 채널을 추가할 수 있다(부분 투명도 사용 가능). 팔레트 이미지의 경우 팔레트 항목에 알파 값을 추가할 수 있다. 저장되는 이러한 값의 수는 총 팔레트 항목 수보다 적을 수 있으며, 이 경우 나머지 항목은 완전히 불투명한 것으로 간주된다.
이진 투명도를 위한 픽셀 값 스캔은 의도치 않게 픽셀이 투명해지는 것을 방지하기 위해 어떤 색상 감소보다 먼저 수행되어야 한다. 이는 16비트-채널 이미지를 디코딩할 수 있지만(사양 준수를 위해 필요) 채널당 8비트만 출력하는 시스템(최고급 시스템을 제외한 모든 시스템의 표준)에서 가장 큰 문제가 될 수 있다.
알파 저장은 "연관"(미리 곱셈) 또는 "비연관"일 수 있지만, PNG는 이미지에 알파 인코딩이 되어 있지 않음을 의미하는 "비연관"("비미리 곱셈") 알파를 표준화했다. 이는 오버 작업이 RGB 방출에 알파를 곱할 것이며, 방출과 폐색을 적절하게 나타낼 수 없음을 의미한다.
PNG는 두 단계 압축 과정을 사용한다.
PNG 파일 형식
PNG는 LZ77과 허프먼 코딩의 조합을 포함하는 특허가 없는 손실 없는 데이터 압축 알고리즘인 DEFLATE를 사용한다. 관대한 라이선스를 가진 DEFLATE 구현체는 널리 사용 가능하다.
JPEG와 같은 손실 압축 형식과 비교할 때, 평균보다 높은 압축 설정을 선택하면 처리 시간이 지연되지만 파일 크기가 크게 줄어들지는 않는 경우가 많다.
DEFLATE를 적용하기 전에 데이터는 예측 방법을 통해 변환된다. 전체 이미지에 대해 단일 필터 방법이 사용되는 반면, 각 이미지 라인에 대해 데이터를 보다 효율적으로 압축할 수 있도록 필터 유형이 선택된다. 스캔라인에 사용되는 필터 유형은 인라인 압축 해제를 가능하게 하기 위해 스캔라인 앞에 추가된다.
PNG 파일 형식
현재 PNG 사양에는 하나의 필터 방법(방법 0으로 표시)만 있으며, 따라서 실제로는 각 줄에 어떤 필터 유형을 적용할지 선택하는 것뿐이다. 이 방법의 경우, 필터는 이전 인접 픽셀의 값을 기반으로 각 픽셀의 값을 예측하고, DPCM과 같이 예측된 픽셀 색상 값을 실제 값에서 뺀다. 이 방식으로 필터링된 이미지 줄은 원시 이미지 줄보다 더 압축 가능한 경우가 많다. 특히 위 줄과 유사한 경우, 예측과의 차이가 일반적으로 0 주변에 모여들고 가능한 모든 이미지 값에 퍼지지 않기 때문이다. 이는 DEFLATE가 이미지를 2D 개체로 이해하지 않고 단순히 바이트 스트림으로 보기 때문에 별도의 행을 연결하는 데 특히 중요하다.
필터 메서드 0에는 5가지 필터 유형이 있다. 각 유형은 왼쪽 픽셀(A), 위 픽셀(B), 왼쪽 위 픽셀(C) 또는 이들의 조합에 해당하는 바이트를 기반으로 각 바이트(필터링 전 이미지 데이터의) 값을 예측하고, 예측 값과 실제 값 간의 차이를 인코딩한다. 필터는 픽셀이 아닌 바이트 값에 적용된다. 픽셀 값은 1 또는 2바이트일 수 있거나 바이트당 여러 값일 수 있지만, 바이트 경계를 넘지 않는다. 필터 유형은 다음과 같다.
PNG 파일 형식
Paeth 필터는 앨런 W. 패스의 알고리즘을 기반으로 한다.
무손실 JPEG에서 사용되는 DPCM 버전과 1 × 2, 2 × 1 또는 (Paeth 예측기의 경우) 2 × 2 창 및 하르 웨이블릿을 사용하는 이산 웨이블릿 변환과 비교한다.
압축은 라인별로 필터 유형을 적응적으로 선택함으로써 더욱 향상된다. 이러한 개선과 PNG 작성 소프트웨어에서 일반적으로 사용되는 경험적 구현 방법은 리 다니엘 크로커에 의해 만들어졌으며, 그는 형식 생성 중에 많은 이미지에서 이러한 방법을 테스트했다. 필터 선택은 아래에서 논의하는 파일 크기 최적화의 구성 요소이다.
인터레이싱이 사용되는 경우, 인터레이싱의 각 단계는 별도로 필터링되어 각 단계가 수신됨에 따라 이미지가 점진적으로 렌더링될 수 있다. 그러나 인터레이싱은 일반적으로 압축 효율성을 떨어뜨린다.
PNG는 선택적인 2차원, 7패스 인터레이싱 스킴인 아담7 알고리즘을 제공한다. 이는 GIF의 1차원, 4패스 스킴보다 더 정교하며, 특히 쌍입방 보간법과 같은 보간 알고리즘이 사용될 경우 전송 초기에 더 선명한 저해상도 이미지를 볼 수 있게 한다.
PNG 파일 형식
그러나 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를 제한적으로 지원한다.
PNG 다른 파일 형식과의 비교
JPEG (Joint Photographic Experts Group) 형식은 사진 (및 사진과 유사한) 이미지의 경우 PNG보다 더 작은 파일을 생성할 수 있다. JPEG는 일반적으로 부드럽고 대비가 낮은 전환과 어느 정도의 노이즈 또는 유사한 불규칙한 구조가 지배적인 사진 이미지 데이터를 위해 특별히 설계된 손실 인코딩 방식을 사용하기 때문이다. 이러한 이미지에 고품질 JPEG 대신 PNG를 사용하면 파일 크기가 크게 증가하고 품질 향상은 무시할 수준이 된다. 이에 비해, 텍스트, 선화 또는 그래픽(선명한 전환과 넓은 단색 영역이 있는 이미지)을 포함하는 이미지를 저장할 때는 PNG 형식이 JPEG보다 이미지 데이터를 더 많이 압축할 수 있다. 또한 PNG는 무손실인 반면 JPEG는 고대비 영역 주변에 시각적 아티팩트를 생성한다. (이러한 아티팩트는 JPG 압축에 사용되는 설정에 따라 달라지며, 낮은 품질[높은 압축] 설정이 사용될 때 상당히 눈에 띌 수 있다.) 이미지가 선명한 전환과 사진 부분을 모두 포함하는 경우, 두 가지 효과 중에서 선택해야 한다. JPEG는 투명도를 지원하지 않는다.
PNG 다른 파일 형식과의 비교
JPEG의 손실 압축은 또한 세대 손실을 겪는다. 이미지를 저장하기 위해 반복적으로 디코딩하고 재인코딩하면 매번 정보 손실이 발생하여 이미지가 저하된다. PNG는 무손실이므로 편집할 이미지를 저장하는 데 적합하다. PNG는 사진 이미지를 압축할 때 합리적으로 효율적이지만, 사진 이미지를 위해 특별히 설계된 무손실 압축 형식, 예를 들어 무손실 WebP 및 Adobe DNG (디지털 네거티브)도 있다. 그러나 이러한 형식은 널리 지원되지 않거나 독점적이다. 이미지를 무손실로 저장하고 배포용으로만 JPEG 형식으로 변환할 수 있으므로 세대 손실이 발생하지 않는다.
PNG 사양은 디지털 카메라와 같은 소스에서 Exif 이미지 데이터를 포함하는 표준을 명시적으로 포함하지 않지만, PNG에 EXIF 데이터를 포함하는 선호되는 방법은 비필수 보조 청크 레이블인 eXIf를 사용하는 것이다.
PNG 다른 파일 형식과의 비교
초기 웹 브라우저는 PNG 이미지를 지원하지 않았다. JPEG와 GIF가 주요 이미지 형식이었다. JPEG는 GIF의 제한된 색상 깊이 때문에 웹 페이지용 그라데이션이 포함된 이미지를 내보낼 때 일반적으로 사용되었다. 그러나 JPEG 압축은 그라데이션을 약간 흐리게 만든다. PNG 형식은 주어진 비트 깊이에 대해 그라데이션을 가능한 한 정확하게 재현하면서 파일 크기를 작게 유지한다. 웹 브라우저의 형식 지원이 향상되면서 PNG는 작은 그라데이션 이미지에 최적의 선택이 되었다. 최신 브라우저에서는 CSS를 사용하여 그라데이션을 생성할 수 있으므로 그라데이션을 표시하기 위해 이미지가 전혀 필요하지 않다.
PNG 다른 파일 형식과의 비교
JPEG-LS는 Joint Photographic Experts Group의 이미지 형식이지만, 위에서 논의된 다른 손실 JPEG 형식보다 훨씬 덜 알려져 있고 지원된다. 이는 PNG와 직접 비교할 수 있으며, 표준 테스트 이미지 세트를 가지고 있다. JPEG-LS는 워털루 레퍼토리 컬러세트(JPEG-LS 적합성 테스트 세트와 관련 없는 표준 테스트 이미지 세트)에서 일반적으로 PNG보다 10-15% 더 나은 성능을 보이지만, 일부 이미지에서는 PNG가 50-75% 더 우수한 성능을 보인다. 따라서 이 두 형식이 모두 옵션이고 파일 크기가 중요한 기준이라면 이미지에 따라 둘 다 고려해야 한다.
PNG 다른 파일 형식과의 비교
JPEG XL은 PNG와 같은 비손실 형식을 대체하기 위해 개발된 또 다른, 훨씬 개선된, 비손실 또는 손실 형식으로, 안타깝게도 지원이 훨씬 적다. JPEG XL은 JPEG보다 50% 이상 작으며, 비손실일 때도 이렇게 작을 수 있으므로 PNG보다도 더 작다. 또한 높은 동적 범위, 넓은 색 영역, 그리고 큰 색 깊이를 지원한다. JPEG XL은 또한 디코딩 효율성이 매우 뛰어나며, 대체하려는 형식에서 부드러운 전환을 제공하고, JPEG에서 손실 없이 변환할 수 있다. 또한 충실도를 손상시키지 않고 압축하는 데 탁월하다.
태그 이미지 파일 형식(TIFF)은 매우 광범위한 옵션을 포함하는 형식이다. 이는 TIFF를 전문 이미지 편집 응용 프로그램 간의 일반적인 교환 형식으로 유용하게 만들지만, 응용 프로그램에 대한 지원을 추가하는 것을 훨씬 더 큰 작업으로 만들고 따라서 이미지 조작과 관련 없는 응용 프로그램(예: 웹 브라우저)에서는 거의 지원되지 않는다. 높은 확장성 수준은 또한 대부분의 응용 프로그램이 가능한 기능의 일부만 제공하여 사용자 혼란 및 호환성 문제를 잠재적으로 야기한다는 것을 의미한다.
TIFF와 함께 사용되는 가장 일반적인 범용 비손실 압축 알고리즘은 Lempel-Ziv-Welch(LZW)이다. 이 압축 기술은 GIF에서도 사용되었으며 2003년까지 특허에 의해 보호되었다. TIFF는 PNG가 사용하는 압축 알고리즘(즉, 압축 태그 000816 '어도비 스타일')도 중간 정도의 사용률과 응용 프로그램 지원을 제공한다. TIFF는 또한 CCITT 그룹 IV와 같은 특수 목적의 비손실 압축 알고리즘을 제공하며, 이는 PNG의 압축 알고리즘보다 바이너리 이미지(예: 팩스 또는 흑백 텍스트)를 더 잘 압축할 수 있다.
PNG는 미리 곱셈이 없는 알파만 지원하는 반면 TIFF는 "연관"(미리 곱셈) 알파도 지원한다.
WebP는 구글이 개발한 형식으로, PNG, JPEG, GIF를 대체하기 위해 고안되었다. WebP 파일은 손실 및 비손실 압축을 모두 허용하는 반면, PNG는 비손실 압축만 허용한다. WebP는 또한 애니메이션을 지원하며, 이는 이전에 GIF 파일만 가능했던 기능이었다.
그러나 WebP가 PNG보다 주요 개선점은 파일 크기가 크게 줄어들어 웹사이트에 삽입될 때 로딩 시간이 빨라진다는 것이다. 구글은 비손실 WebP 이미지가 PNG 파일보다 26% 더 작다고 주장한다.
WebP는 PNG와 달리 다양한 이미지 편집 프로그램 및 소셜 미디어 웹사이트와의 호환성 문제로 비판을 받아왔다. 또한 WebP는 모든 웹 브라우저에서 지원되지 않아 웹 이미지 호스팅 업체에서 사용자에게 표시할 대체 이미지를 생성해야 할 수 있으며, 이는 WebP의 잠재적인 저장 공간 절약을 무효화한다.
AVIF는 오픈 미디어 연합이 개발한 이미지 형식이다. AVIF는 PNG, GIF, WebP를 포함한 다른 이미지 코덱의 단점을 보완하기 위해 재단에서 설계되었다.
AVIF는 일반적으로 WebP와 PNG보다 크기가 작다. AVIF는 PNG가 지원하지 않는 애니메이션을 지원한다.
그러나 WebP와 마찬가지로 AVIF는 PNG보다 적은 응용 프로그램에서 지원된다.
PNG 소프트웨어 지원
PNG 형식의 공식 참조 구현은 프로그래밍 라이브러리 libpng이다. 이는 관대한 자유 소프트웨어 라이선스 조건에 따라 자유 소프트웨어로 게시된다. 따라서 일반적으로 자유 운영 체제에서 중요한 시스템 라이브러리로 발견된다.
PNG 형식은 어도비 포토샵, 코렐의 Photo-Paint 및 Paint Shop Pro, 김프, 그래픽컨버터, 헬리콘 필터, 이미지매직, 잉크스케이프, 이르판뷰, Pixel 이미지 편집기, Paint.NET 및 Xara Photo & Graphic Designer 등 많은 그래픽 프로그램(온라인 그래픽 디자인 플랫폼 Canva 포함)에서 널리 지원된다. 인기 있는 운영체제에 번들로 제공되는 일부 PNG 지원 프로그램으로는 마이크로소프트의 Paint와 애플의 Photos/아이포토 및 Preview가 있으며, 김프도 인기 있는 리눅스 배포판에 자주 번들로 제공된다.
PNG 소프트웨어 지원
어도비 파이어웍스(이전 매크로미디어)는 PNG를 기본 파일 형식으로 사용하여 다른 이미지 편집기 및 미리보기 유틸리티가 플랫 이미지(flattened image)를 볼 수 있게 한다. 그러나 파이어웍스는 기본적으로 레이어, 애니메이션, 벡터 데이터, 텍스트 및 효과에 대한 메타데이터도 저장한다. 이러한 파일은 직접 배포되어서는 안 된다. 파이어웍스는 웹 페이지 등에서 사용할 수 있도록 추가 메타데이터가 없는 최적화된 PNG로 이미지를 내보낼 수 있다.
PNG 지원은 1997년에 처음 등장했으며, 인터넷 익스플로러 4.0b1(NT용 32비트 전용) 및 넷스케이프 4.04에서 지원되었다.
자유 소프트웨어 재단과 월드 와이드 웹 컨소시엄 (W3C)의 요청에도 불구하고, gif2png와 같은 도구와 Burn All GIFs와 같은 캠페인에도 불구하고, 인터넷 익스플로러의 늦고 버그가 있는 지원, 특히 투명도와 관련하여 웹사이트에서의 PNG 채택은 상당히 느렸다. PNG는 2018년부터 웹에서 가장 많이 사용되는 이미지 파일 형식이다.
PNG 소프트웨어 지원
PNG 호환 브라우저에는 Apple Safari, 구글 크롬, 모질라 파이어폭스, Opera, 카미노, 인터넷 익스플로러, 마이크로소프트 엣지, 그리고 다른 많은 브라우저가 포함된다. 전체 비교는 웹 브라우저 비교 (이미지 형식 지원)를 참조하라.
특히 9.0 (2011년 출시) 이전 버전의 인터넷 익스플로러 (윈도우)는 PNG 이미지를 올바르게 렌더링하지 못하게 하는 수많은 문제를 가지고 있었다.
PNG 아이콘은 1999년부터 리눅스 대부분의 배포판에서 그놈과 같은 데스크톱 환경에서 지원되었다. 2006년에는 마이크로소프트 윈도우에서 PNG 아이콘 지원이 윈도우 비스타에 도입되었다. PNG 아이콘은 아미가OS 4, AROS, MacOS, IOS, 모르프OS에서도 지원된다. 또한 안드로이드는 PNG를 광범위하게 사용한다.
PNG 파일 크기 및 최적화 소프트웨어
PNG 파일 크기는 인코딩 및 압축 방식에 따라 크게 달라질 수 있다. 이에 대한 논의와 몇 가지 팁은 PNG: The Definitive Guide에 나와 있다.
GIF 파일과 비교할 때, 동일한 정보(256색, 보조 청크/메타데이터 없음)를 가진 PNG 파일은 효율적인 압축기로 압축하면 일반적으로 GIF 이미지보다 크기가 작다. 파일과 압축기에 따라 PNG는 약간 작거나(10%), 상당히 작거나(50%), 약간 클 수도(5%) 있지만, 큰 이미지에서는 거의 상당히 크지 않다. 이는 GIF의 LZW에 비해 PNG의 DEFLATE 성능과, PNG의 예측 필터의 추가 사전 압축 계층이 2차원 이미지 구조를 고려하여 파일을 추가로 압축하기 때문이다. 필터링된 데이터는 픽셀 간의 차이를 인코딩하므로, 가능한 모든 이미지 값에 분산되기보다 0 주변에 모이는 경향이 있어 DEFLATE에 의해 더 쉽게 압축된다. 그러나 어도비 포토샵, 코렐드로, MS Paint의 일부 버전은 PNG 압축이 좋지 않아 GIF가 더 효율적이라는 인상을 줄 수 있다.
PNG 파일 크기는 여러 요인에 따라 달라진다.
PNG 파일 크기 및 최적화 소프트웨어
색 깊이
색 깊이는 픽셀당 1비트에서 64비트까지 다양하다.
보조 청크
PNG는 메타데이터를 지원한다. 이는 편집에 유용할 수 있지만, 웹사이트에서와 같이 보기에 불필요할 수 있다.
인터레이싱
아담7 알고리즘의 각 패스는 개별적으로 필터링되므로 파일 크기가 증가할 수 있다.
필터
사전 압축 단계로, 각 라인은 예측 필터에 의해 필터링되며, 이는 라인마다 달라질 수 있다. 최종 DEFLATE 단계는 이미지 전체의 필터링된 데이터에 대해 작동하므로, 이를 행별로 최적화할 수 없다. 따라서 각 행에 대한 필터 선택은 매우 가변적일 수 있지만, 휴리스틱이 존재한다.
압축
추가 계산을 통해 DEFLATE 압축기는 더 작은 파일을 생성할 수 있다.
PNG 파일 크기 및 최적화 소프트웨어
따라서 높은 색 깊이, 최대 메타데이터(색 공간 정보 및 디스플레이에 영향을 미치지 않는 정보 포함), 인터레이싱, 압축 속도(모두 큰 파일을 생성함)와 낮은 색 깊이, 적거나 없는 보조 청크, 인터레이싱 없음, 튜닝되었지만 계산 집약적인 필터링 및 압축 간에는 파일 크기 트레이드오프가 있다. 다른 목적을 위해 다른 트레이드오프가 선택된다. 최대 파일은 아카이빙 및 편집에 가장 적합할 수 있고, 스트립다운된 파일은 웹사이트 사용에 가장 적합할 수 있으며, 마찬가지로 빠르지만 압축률이 낮은 압축은 파일을 반복적으로 편집하고 저장할 때 선호되는 반면, 느리지만 압축률이 높은 압축은 파일이 안정적일 때(아카이빙 또는 게시할 때) 선호된다.
인터레이싱은 트레이드오프이다. 대용량 파일의 초기 렌더링 속도를 극적으로 높이지만(대기 시간 개선), 특히 작은 파일의 경우 파일 크기를 증가시킬 수 있다(처리량 감소).
PNG는 무손실 형식임에도 불구하고, PNG 인코더는 PNG 압축을 개선하기 위해 손실 방식으로 이미지 데이터를 전처리할 수 있다. 예를 들어, 트루컬러 PNG를 256색으로 양자화하면 인덱스 색상 유형을 사용하여 파일 크기를 줄일 수 있다.
PNG 파일 크기 및 최적화 소프트웨어
일부 프로그램은 PNG 파일을 저장할 때 다른 프로그램보다 효율적이다. 이는 프로그램에서 사용되는 PNG 압축 구현과 관련이 있다.
많은 그래픽 프로그램(예: 애플의 Preview 소프트웨어)은 웹 보기에 일반적으로 불필요한 많은 메타데이터 및 색 보정 데이터를 포함하여 PNG를 저장한다. 어도비 파이어웍스에서 최적화되지 않은 PNG 파일도 이미지 편집 가능한 옵션을 포함하므로 악명 높다. 또한 코렐드로(최소 11버전)는 때때로 인터넷 익스플로러(6-8버전)에서 열리지 않는 PNG를 생성한다.
어도비 포토샵의 PNG 파일 성능은 웹용 저장 기능(명시적인 PNG/8 사용도 허용)을 사용할 때 CS Suite에서 향상되었다.
PNG 파일 크기 및 최적화 소프트웨어
어도비 파이어웍스는 기본적으로 다른 많은 프로그램보다 큰 PNG 파일을 저장한다. 이는 저장 형식의 메커니즘에서 비롯된다. 파이어웍스의 저장 기능으로 생성된 이미지에는 완전한 레이어 및 벡터 정보를 포함하는 크고 비공개적인 청크가 포함된다. 이는 추가 무손실 편집을 가능하게 한다. 내보내기 옵션으로 저장될 때, 파이어웍스의 PNG는 다른 이미지 편집기에서 생성된 PNG와 경쟁할 수 있지만, 플랫 비트맵 외에는 편집할 수 없다. 파이어웍스는 크기가 최적화된 벡터 편집 가능한 PNG를 저장할 수 없다.
PNG 압축 성능이 좋지 않은 다른 주목할 만한 예는 다음과 같다.
압축 불량은 PNG 파일 크기를 증가시키지만, 이미지 품질이나 다른 프로그램과의 파일 호환성에는 영향을 미치지 않는다.
PNG 파일 크기 및 최적화 소프트웨어
트루컬러 이미지의 색 깊이를 8비트 팔레트로 줄이면(GIF에서처럼), 결과 이미지 데이터는 일반적으로 훨씬 더 작아진다. 따라서 트루컬러 PNG는 일반적으로 색상이 줄어든 GIF보다 크지만, PNG는 색상이 줄어든 버전을 비슷한 크기의 팔레트 파일로 저장할 수 있다. 반대로, 일부 도구는 이미지를 PNG로 저장할 때, 원본 데이터가 8비트 색상만 사용하더라도 자동으로 트루컬러로 저장하여 파일을 불필요하게 부풀린다. 이 두 가지 요인 모두 PNG 파일이 동등한 GIF 파일보다 크다는 오해를 불러일으킬 수 있다.
PNG 파일을 최적화하는 데 사용할 수 있는 다양한 도구가 있다. 이들은 다음을 통해 이를 수행한다.
advpng와 유사한 advdef 유틸리티는 AdvanceCOMP 패키지에서 PNG IDAT를 재압축한다. 선택된 압축 수준에 따라 다른 DEFLATE 구현이 적용되어 속도와 파일 크기 간의 균형을 맞춘다. zlib는 수준 1, libdeflate는 수준 2, 7-zip의 LZMA DEFLATE는 수준 3, Zopfli는 수준 4이다.
PNG 파일 크기 및 최적화 소프트웨어
pngout은 저자 자신의 디플레이터(저자의 zip 유틸리티인 kzip과 동일)로 만들어졌으며, 색상 감소/필터링의 모든 기능을 유지한다. 그러나 pngout은 한 번의 실행에서 여러 번의 필터 시도를 허용하지 않는다. 상용 GUI 버전인 pngoutwin을 사용하거나, 래퍼와 함께 사용하여 시도를 자동화하거나, 자체 디플레이터를 사용하여 필터를 라인별로 유지하면서 재압축하는 것이 좋다.
이들의 기능에 대한 간단한 비교는 아래에 나열되어 있다.
zopflipng가 나오기 전에는 최적의 압축을 위해 두 가지 도구를 순차적으로 사용하는 것이 효과적인 png 최적화 방법이었다. 하나는 필터를 최적화하고(보조 청크 제거), 다른 하나는 DEFLATE를 최적화하는 방식이었다. pngout은 둘 다 제공하지만, 한 번의 실행에서 한 가지 필터 유형만 지정할 수 있으므로, pngcrush와 함께 래퍼 도구 또는 advdef처럼 재디플레이터 역할을 하는 방식으로 사용할 수 있다.
PNG 파일 크기 및 최적화 소프트웨어
보조 청크를 제거하기 위해 대부분의 PNG 최적화 도구는 PNG 파일에서 모든 색 보정 데이터(감마, 화이트 밸런스, ICC 색상 프로파일, 표준 RGB 색상 프로파일)를 제거하는 기능을 가지고 있다. 이는 종종 훨씬 더 작은 파일 크기를 초래한다. 예를 들어, 다음 명령줄 옵션은 pngcrush로 이를 달성한다.
pngcrush, pngout, zopflipng는 모두 필터 유형 0-4 중 하나를 전역적으로 적용하거나("유사 필터" 번호 5 사용), 각 라인에 대해 적응형 알고리즘을 사용하여 필터 유형 0-4 중 하나를 선택하는 옵션을 제공한다. zopflipng는 무차별 대입 검색을 포함하여 3가지 다른 적응형 방법을 제공하며, 이는 필터링을 최적화하려고 시도한다.
`pngout`과 `zopflipng`는 입력 이미지에 존재하는 라인별 필터 세트를 보존/재사용하는 옵션을 제공한다.
`pngcrush`와 `zopflipng`는 한 번의 실행에서 다양한 필터 전략을 시도하고 최적의 것을 선택하는 옵션을 제공한다. `pngout`의 프리웨어 명령줄 버전은 이를 제공하지 않지만, 상용 버전인 `pngoutwin`은 제공한다.
Zopfli와 LZMA SDK는 성능을 희생하는 대신 Zlib 참조 구현보다 더 높은 압축률을 생성할 수 있는 DEFLATE 구현을 제공한다. AdvanceCOMP의 `advpng` 및 `advdef`는 이러한 라이브러리 중 하나를 사용하여 PNG 파일을 재압축할 수 있다. 또한 PNGOUT은 자체 독점 DEFLATE 구현을 포함한다.
`advpng`는 필터를 적용하는 옵션이 없으며 항상 필터 0을 전역적으로 사용한다(이미지 데이터를 필터링하지 않은 상태로 둠). 따라서 이미지에 필터링이 크게 도움이 되는 경우에는 사용해서는 안 된다. 이와 대조적으로, 같은 패키지의 `advdef`는 PNG 구조를 다루지 않고 재디플레이터 역할만 하며, 기존 필터 설정을 유지한다.
Windows Vista 및 이후 버전을 위한 아이콘이 PNG 하위 이미지를 포함할 수 있으므로, 이러한 아이콘에도 최적화를 적용할 수 있다. 적어도 하나의 아이콘 편집기인 Pixelformer는 ICO 파일을 저장할 때 특별한 최적화 패스를 수행하여 크기를 줄일 수 있다.
macOS용 아이콘도 PNG 하위 이미지를 포함할 수 있지만, 이러한 도구는 현재 없다.
우파니샤드
《우파니샤드》(산스크리트어: उपनिषद् Upaniṣad)는 힌두교 이론과 사상의 토대를 이루는 철학 문헌들을 모은 것이다. 또한 베다의 끝 또는 베다의 결론이라는 뜻에서 베단타(Vedanta)라고도 불린다. 힌두교 경전은 크게 신으로부터 계시된 지식을 뜻하는 슈루티와 스승에서 제자로 전승된 지식을 뜻하는 스므리티로 나뉘는데, 전통적으로 우파니샤드는 슈루티에 속한다. 하지만, 우파니샤드는 베다의 정수(精髓)를 해설하는 주해서이기 때문에 슈루티의 엄밀한 정의에 따를 경우 슈루티에 속하지 않는다고 할 수도 있다. 대다수의 우파니샤드는 《브라마나(Brahmanas)》와 《아란야캬(Aranyakas)》의 결론부에서 발견되었으며, 모든 우파니샤드는 구전으로 전수되어 내려왔다.
우파니샤드
총 200편 이상의 문헌이 우파니샤드에 속한 것으로 알려져 있다. 이들 중 최초의 10편 내지 13편 정도가 가장 오랜 것이며 가장 중요한 것으로 여겨지고 있는데, 이들을 통칭하여 무키아 우파니샤드(Mukhya Upanishads) 또는 고(古)우파니샤드라고 한다. 산스크리트어 낱말 무키아(Mukhya)는 "주된 · 주요한 · 으뜸의 · 뛰어난"의 의미를 가진다. 《우파니샤드》, 《바가바드 기타》, 《브라흐마 수트라》를 통칭하여 프라스타나트라이이(Prasthanatrayi)라고 하는데, 《바가바드 기타》와 《브라흐마 수트라》와 더불어 무키아 우파니샤드는 후기 인도 철학의 여러 학파들(베단타 철학)의 사상적 · 이론적 토대를 제공한다. 이들 학파들에는 힌두교에서 가장 큰 영향력을 가진 두 일원론 학파인 아드바이타 베단타 학파와 비시슈타아드바이타 베단타 학파가 속한다.
우파니샤드 어원
산스크리트어 낱말 우파니샤드(उपनिषद्, Upaniṣad)는 "가까이"를 뜻하는 우파(upa-), "적당한 장소에서" 또는 "아래에서"를 뜻하는 니(ni-), "앉다"를 뜻하는 샤드(ṣad)에서 유래한 낱말로, 따라서 문자 그대로의 의미는 "가까이에 앉는다"로, 가르침을 받기 위해 스승의 가까이에 앉는다는 것을 의미한다. 또는, "(스승의) 발 아래에 앉는다 또는 하석에 앉는다" 혹은 "(스승을) 둘러싸고 앉는다"를 뜻한다.
우파니샤드 어원
모니어윌리엄스(Monier-Williams: 1819~1899)가 편찬한 19세기 후반의 사전에는 "인도인 권위자들에 따르면 우파니샤드는 '지고한 영에 대한 앎을 드러냄으로써 무지를 쉬게 하는 것'을 뜻한다"고 부연하고 있다. 샹카라는 《카타 우파니샤드》와 《브리하다란야카 우파니샤드》에 대한 자신의 주해에서 "우파니샤드"라는 낱말을 자아를 아는 것을 뜻하는 "아트마비드야(Ātmavidyā)" 또는 브라흐마(브라만을 뜻함)를 아는 것을 뜻하는 "브라흐마비드야(Brahmavidyā)"와 동일한 낱말로 취급하고 있다. 막스 뮐러(1823~1900)는 우파니샤드들 자체에서 발견되는 "우파니샤드"라는 낱말에 대한 기타 다른 정의로는 "밀교적 교의(esoteric doctrine)", "비밀 교의(secret doctrine)", "밀교적 해설(esoteric explanation)", "비밀한 해설(secret explanation)", "참된 교의(true doctrine)"가 있다고 하였다.
우파니샤드 분류
알려진 우파니샤드로는 총 200권 이상이 있다. 이들 우파니샤드의 집성물 중, "구원" 또는 "구제"라는 뜻의 《묵티카(Muktikā)》는 108권의 우파니샤드를 집성한 것으로 이 숫자는 힌두교의 염주인 말라(mala)에 있는 염주알의 총 개수와 동일하다.
현대 학자들은 《묵티카(Muktikā)》의 최초의 10권, 11권, 12권 혹은 13권의 우파니샤드들을 주요한 우파니샤드들, 즉 무키아 우파니샤드(Mukhya Upanishads)라고 보고 있으며 나머지 우파니샤드들은 무키아 우파니샤드로부터 파생된 것이라고 보고 있다. 즉, 어떤 우파니샤드가 샹카라와 같은 권위 있는 철학자들에 의해 주해되거나 인용되는 경우, 그 우파니샤드는 "하나의 무키아 우파니샤드"로 분류되며 대다수의 힌두교인들은 그것을 슈루티로 받아들인다. 무키아 우파니샤드는 구우파니샤드라고도 한다.
우파니샤드 분류
《묵티카(Muktikā)》의 신우파니샤드들은 인도 남부에서 유래한 것으로 보이는데, 주제에 따라 (사만야) 베단타 · 요가 · 산야사 · 비슈누 · 시바 · 샥티 우파니샤드의 6그룹으로 나뉜다. (사만야) 베단타 우파니샤드(Samanya Vedanta Upanishads)는 철학적 성격의 것이고, 요가 우파니샤드는 요가 수행과 관련된 것이고, 산야사(Sanyasa) 우파니샤드는 영적 포기의 삶에 관한 것이고, 비슈누 우파니샤드는 비슈누에 대한 헌신에 관한 것이고, 시바 우파니샤드는 시바에 대한 헌신에 관한 것이고, 샥티 우파니샤드는 여신 샥티에 대한 헌신에 관한 것이다. 신우파니샤드들은 종종 종파주의적인데 그 이유는 힌두교의 각 종파들은 자신들이 소의(所依)하는 우파니샤드들이 슈루티에 속한다고 주장함으로써 스스로에게 정통성, 정당성 또는 권위를 부여했기 때문이다.
또 다른 분류법은 해당하는 《브라마나》별로 우파니샤드들을 분류하는 것이다.
아이타레야(Aitareya), 카우시타키(Kauṣītaki), 타이티리야(Taittirīya) 우파니샤드는 모두 거의 동시대에 성립된 것으로 여겨지고 있으며 나머지 우파니샤드들은 베다 산스크리트어(기원전 1500~500)에서 고전 산스크리트어(기원전 4세기에 성립)로 전이하는 시기부터 성립되기 시작한 것으로 여겨지고 있다.