shopkeeper/korean_wiki_content_only_120125 huggingface dataset:
GIF의 첫 글자 발음은 1990년대부터 논란이 되어왔다. 영어에서 가장 흔한 발음은 (gin처럼 부드러운 g)와 (gift처럼 센 g)로, 문자 G가 나타내는 음소가 다르다. 형식의 개발자들은 GIF를 로 발음했는데, 부드러운 g로 발음했다. 윌하이트는 발음이 미국 땅콩버터 브랜드 Jif를 의도적으로 반영하기를 원했으며, 컴퓨서브 직원들은 종종 Jif의 텔레비전 광고를 패러디하여 "까다로운 개발자는 GIF를 선택한다"고 농담을 하곤 했다. 그러나 이 단어는 로 널리 발음되는데, 센 g로 발음되며, 여론 조사는 일반적으로 이러한 센 g 발음이 더 우세하다는 것을 보여준다.
Dictionary.com은 두 발음 모두를 인용하며, 를 주된 발음으로 나타내고, 반면 Cambridge Dictionary of American English는 센 g 발음만을 제공한다. 메리엄-웹스터 대학 사전과 Oxford Dictionaries는 두 발음 모두를 인용하지만, 센 g를 먼저 배치한다: . The New Oxford American Dictionary는 2판에서 만 제공했지만, 3판에서는 로 업데이트했다.
발음 논쟁은 인터넷에서 뜨거운 논쟁으로 이어졌다. 2013년 웹비 어워드 시상식에서 평생 공로상을 받은 자리에서 윌하이트는 센 g 발음을 공개적으로 거부했다. 그의 연설은 트위터에 17,000개 이상의 게시물과 수십 개의 뉴스 기사를 불러왔다. 백악관과 TV 프로그램 제퍼디!도 2013년에 이 논쟁에 참여했다. 2020년 2월, Jif 브랜드 소유주인 The J.M. Smucker Company는 애니메이션 이미지 데이터베이스 및 검색 엔진인 Giphy와 협력하여 한정판 "Jif vs. GIF" (해시태그 #JIFvsGIF) 땅콩 버터 병을 출시했다. 이 병의 라벨에는 부드러운 g 발음은 땅콩 버터에만 해당되고, GIF는 센 g 발음으로만 발음되어야 한다는 유머러스한 내용이 적혀 있었다.
GIF는 로고와 같이 색상 수가 제한된 선명한 가장자리를 가진 선화에 적합하다. 이는 형식이 잘 정의된 가장자리를 가진 단색의 평평한 영역을 선호하는 비손실 압축의 이점을 활용한다. 또한 게임을 위한 저해상도 스프라이트 데이터를 저장하는 데도 사용될 수 있다. GIF는 작은 애니메이션과 저해상도 비디오 클립에 사용될 수 있으며, 온라인 메시징에서 단어 대신 감정을 전달하기 위한 반응으로도 사용된다. 텀블러, 페이스북, 트위터와 같은 소셜 미디어 플랫폼에서 인기가 많다.
개념적으로, GIF 파일은 고정된 크기의 그래픽 영역("논리적 화면")을 설명하며, 이 영역에는 0개 이상의 "이미지"가 채워져 있다. 많은 GIF 파일은 전체 논리적 화면을 채우는 단일 이미지를 가지고 있다. 다른 파일들은 논리적 화면을 별도의 하위 이미지로 나눈다. 이미지는 애니메이션 GIF 파일에서 애니메이션 프레임으로도 작동할 수 있지만, 이 역시 전체 논리적 화면을 채울 필요는 없다.
GIF 파일은 버전을 나타내는 고정 길이 헤더("GIF87a" 또는 "GIF89a")로 시작하며, 이어서 논리적 화면의 픽셀 크기 및 기타 특성을 나타내는 고정 길이 논리적 화면 디스크립터가 온다. 화면 디스크립터는 또한 전역 색상 테이블(GCT)의 존재 여부와 크기를 지정할 수 있으며, 존재하는 경우 그 다음에 온다.
그 후 파일은 1바이트의 센티넬로 시작하는 다음과 같은 유형의 세그먼트로 나뉜다:
이미지는 고정 길이 이미지 디스크립터로 시작하며, 이는 로컬 색상 테이블(존재하는 경우 그 다음에 옴)의 존재 여부와 크기를 지정할 수 있다. 이미지 데이터가 그 뒤를 따른다: 인코딩되지 않은 심볼의 비트 너비를 나타내는 1바이트(이진 이미지의 경우에도 최소 2비트 너비여야 함), 그 다음 LZW로 인코딩된 데이터를 포함하는 일련의 서브 블록.
확장 블록(87a 사양에 이미 정의된 메커니즘을 통해 87a 정의를 "확장"하는 블록)은 센티넬, 확장 유형을 지정하는 추가 바이트, 그리고 확장 데이터를 포함하는 일련의 서브 블록으로 구성된다. 이미지를 수정하는 확장 블록(예: 선택적 애니메이션 지연 시간 및 선택적 투명 배경색을 지정하는 그래픽 제어 확장)은 해당 이미지가 있는 세그먼트 바로 앞에 와야 한다.
각 서브 블록은 서브 블록의 다음 데이터 바이트 수(1에서 255)를 나타내는 바이트로 시작한다. 서브 블록의 시리즈는 빈 서브 블록(0 바이트)으로 종료된다.
이러한 구조는 모든 부분이 이해되지 않더라도 파일을 구문 분석할 수 있도록 한다. 87a로 표시된 GIF는 확장 블록을 포함할 수 있다. 의도는 디코더가 이해하지 못하는 확장 기능 없이 파일을 읽고 표시할 수 있도록 하는 것이다.
파일 형식의 전체 세부 사항은 GIF 사양에 설명되어 있다.
팔레트.
GIF는 팔레트 기반이다: 파일 내 이미지(프레임)에 사용된 색상은 최대 256개 항목을 담을 수 있는 팔레트 테이블에 RGB 값이 정의되어 있으며, 이미지 데이터는 팔레트 테이블의 인덱스(0–255)로 색상을 참조한다. 팔레트의 색상 정의는 수백만 색조(각 주색당 8비트, 224 색조)의 색상 공간에서 가져올 수 있지만, 프레임이 사용할 수 있는 최대 색상 수는 256개이다. 이 제한은 GIF가 개발될 당시 256개 이상의 색상을 동시에 표시할 수 있는 하드웨어가 드물었기 때문에 합리적이었다. 단순한 그래픽, 선 그림, 만화, 회색조 사진은 일반적으로 256개 미만의 색상이 필요하다.
각 프레임은 하나의 인덱스를 "투명 배경색"으로 지정할 수 있다: 이 인덱스에 할당된 모든 픽셀은 배경의 동일한 위치에 있는 픽셀의 색상을 취하며, 이는 이전 애니메이션 프레임에 의해 결정되었을 수 있다.
디더링이라고 총칭되는 많은 기술들이 두 가지 이상의 색상 픽셀을 사용하여 중간 색상을 근사화함으로써 작은 색상 팔레트로 더 넓은 범위의 색상을 근사화하기 위해 개발되었다. 이러한 기술들은 더 깊은 색상 해상도를 근사화하기 위해 공간 해상도를 희생한다. GIF 사양의 일부는 아니지만, 디더링은 나중에 GIF 이미지로 인코딩된 이미지에 사용될 수 있다. 이는 일반적으로 GIF 이미지에 이상적인 해결책이 아닌데, 공간 해상도의 손실이 일반적으로 화면에서 이미지를 흐릿하게 보이게 하고, 디더링 패턴이 이미지 데이터의 압축성에 방해가 되어 GIF의 주요 목적에 반하기 때문이다.
초창기 그래픽 웹 브라우저에서는 8비트 버퍼(256가지 색상만 허용)를 가진 그래픽 카드가 흔했으며, 웹 안전 팔레트를 사용하여 GIF 이미지를 만드는 것이 매우 흔했다. 이는 예측 가능한 디스플레이를 보장했지만, 색상 선택을 심각하게 제한했다. 24비트 색상이 표준이 되면서 팔레트는 개별 이미지에 최적의 색상으로 채워질 수 있었다.
작은 이미지에는 작은 색상 테이블로도 충분하며, 색상 테이블을 작게 유지하면 파일을 더 빠르게 다운로드할 수 있다. 87a 및 89a 사양 모두 n이 1에서 8까지인 모든 2n 색상의 색상 테이블을 허용한다. 대부분의 그래픽 응용 프로그램은 이러한 테이블 크기를 가진 GIF 이미지를 읽고 표시하지만, 이미지를 생성할 때는 모든 크기를 지원하지 않는 경우도 있다. 2, 16, 256 색상 테이블은 널리 지원된다.
트루컬러.
GIF는 트루컬러 이미지에 거의 사용되지 않지만, 그렇게 하는 것이 가능하다. GIF 이미지에는 여러 이미지 블록이 포함될 수 있으며, 각 블록은 자체 256색 팔레트를 가질 수 있고, 이 블록들을 타일링하여 완전한 이미지를 만들 수 있다. 또는 GIF89a 사양은 "투명" 색상의 개념을 도입하여 각 이미지 블록이 자체 255개의 보이는 색상 팔레트와 하나의 투명 색상을 포함할 수 있도록 했다. 완전한 이미지는 이미지 블록을 겹쳐서 만들 수 있으며, 각 레이어의 보이는 부분이 위 레이어의 투명 부분을 통해 표시된다.
풀 컬러 이미지를 GIF로 렌더링하려면 원본 이미지를 255개 또는 256개 이하의 다른 색상을 가진 작은 영역으로 분할해야 한다. 그런 다음 각 영역은 자체 로컬 팔레트가 있는 별도의 이미지 블록으로 저장되며, 이미지 블록이 함께 표시될 때(타일링 또는 부분적으로 투명한 이미지 블록을 겹침으로써) 완전한 풀 컬러 이미지가 나타난다. 예를 들어, 이미지를 16x16픽셀(총 256픽셀) 타일로 분할하면 어떤 타일도 로컬 팔레트 제한인 256색 이상을 가지지 않도록 보장하지만, 더 큰 타일을 사용할 수 있고 유사한 색상이 병합되어 일부 색상 정보가 손실될 수 있다.
각 이미지 블록은 자체 로컬 색상 테이블을 가질 수 있으므로, 많은 이미지 블록을 가진 GIF 파일은 매우 커질 수 있어 풀 컬러 GIF의 유용성을 제한한다. 또한, 모든 GIF 렌더링 프로그램이 타일링되거나 레이어링된 이미지를 올바르게 처리하는 것은 아니다. 많은 렌더링 프로그램은 타일 또는 레이어를 애니메이션 프레임으로 해석하고 애니메이션으로 순서대로 표시하며 대부분의 웹 브라우저는 프레임을 0.1초 이상의 지연 시간으로 자동으로 표시한다.
GIF 파일 예시.
다음 표의 16진수는 형식 사양에 따라 리틀 엔디언 바이트 순서이다.
이미지 코딩.
왼쪽 상단에서 수평으로 스캔된 이미지 픽셀 데이터는 LZW 인코딩에 의해 코드로 변환된 후 파일에 저장하기 위해 바이트로 매핑된다. 픽셀 코드는 일반적으로 바이트의 8비트 크기와 일치하지 않으므로, 코드는 "리틀 엔디언" 방식에 의해 바이트로 압축된다: 첫 번째 코드의 최하위 비트는 첫 번째 바이트의 최하위 비트에 저장되고, 코드의 상위 비트는 바이트의 상위 비트에 저장되며, 필요한 경우 다음 바이트의 최하위 비트로 넘어간다. 각 후속 코드는 아직 사용되지 않은 최하위 비트에서 시작하여 저장된다.
이 바이트 스트림은 파일에 일련의 "서브 블록"으로 저장된다. 각 서브 블록은 최대 길이 255바이트를 가지며, 서브 블록의 데이터 바이트 수를 나타내는 바이트가 앞에 붙는다. 서브 블록의 시리즈는 빈 서브 블록(단일 0 바이트, 0 데이터 바이트를 가진 서브 블록을 나타냄)으로 종료된다.
위 샘플 이미지의 경우 9비트 코드와 바이트 간의 가역 매핑은 다음과 같다.
약간의 압축이 분명하다: 처음 15바이트로 정의된 픽셀 색상이 제어 코드를 포함하여 12바이트의 코드로 정확하게 표현된다.
9비트 코드를 생성하는 인코딩 프로세스는 아래와 같다. 로컬 문자열은 팔레트에서 픽셀 색상 번호를 누적하며, 로컬 문자열이 코드 테이블에서 발견되는 한 출력 동작은 없다. 테이블이 초기 크기에서 문자열 추가로 커지기 전에 도착하는 처음 두 픽셀은 특별히 처리된다. 각 출력 코드 후에 로컬 문자열은 최신 픽셀 색상(출력 코드에 포함될 수 없었던)으로 초기화된다.
Table 9-bit
string --&gt; code code Action
#0 | 000h Initialize root table of 9-bit codes
palette | :
colors | :
#255 | 0FFh
clr | 100h
end | 101h
| 100h Clear
Pixel Local |
color Palette string |
BLACK #40 28 | 028h 1st pixel always to output
WHITE #255 FF | String found in table
28 FF | 102h Always add 1st string to table
FF | Initialize local string
WHITE #255 FF FF | String not found in table
| 0FFh - output code for previous string
FF FF | 103h - add latest string to table
FF | - initialize local string
WHITE #255 FF FF | String found in table
BLACK #40 FF FF 28 | String not found in table
| 103h - output code for previous string
FF FF 28 | 104h - add latest string to table
28 | - initialize local string
WHITE #255 28 FF | String found in table
WHITE #255 28 FF FF | String not found in table
| 102h - output code for previous string
28 FF FF | 105h - add latest string to table
WHITE #255 FF FF FF | String not found in table
FF FF FF | 106h - add latest string to table
WHITE #255 FF FF FF | String found in table
WHITE #255 FF FF FF FF | String not found in table
| 106h - output code for previous string
FF FF FF FF| 107h - add latest string to table
WHITE #255 FF FF FF FF | String found in table
No more pixels
107h - output code for last string
101h End
명확성을 위해 위 표는 길이가 증가하는 문자열로 구성된 것으로 나타난다. 이 방식은 작동할 수 있지만 테이블이 예측할 수 없는 양의 메모리를 소비한다. 실제로 각 새로운 문자열이 이전에 저장된 문자열에 하나의 문자가 추가된 형태로 구성된다는 점에 주목하여 메모리를 절약할 수 있다. 각 주소에 기존 주소와 하나의 문자만 저장하는 것이 경제적이다.
LZW 알고리즘은 각 픽셀에 대해 테이블을 검색해야 한다. 최대 4096개 주소를 선형 검색하면 코딩이 느려진다. 실제로 코드는 숫자 값 순서로 저장할 수 있다. 이렇게 하면 각 검색이 SAR(Successive Approximation Register, 일부 ADC에서 사용됨)에 의해 단 12개의 크기 비교만으로 수행될 수 있다. 이러한 효율성을 위해 코드와 실제 메모리 주소 간의 변환을 위한 추가 테이블이 필요하다. 추가 테이블 유지는 픽셀 속도보다 훨씬 적은 빈도로 새 코드가 저장될 때만 필요하다.
압축되지 않은 GIF.
GIF 인코딩 프로세스는 LZW 압축 없이도 GIF 이미지로 볼 수 있는 파일을 생성하도록 수정될 수 있다. 이 기술은 원래 특허 침해를 피하는 방법으로 도입되었다. 압축되지 않은 GIF는 개별 픽셀을 읽거나 그릴 수 있기 때문에 그래픽 프로그래머에게 유용한 중간 형식일 수도 있다. 압축되지 않은 GIF 파일은 이미지 편집기를 통해 단순히 통과시키는 것만으로 일반 GIF 파일로 변환될 수 있다.
수정된 인코딩 방식은 LZW 테이블 구축을 무시하고 루트 팔레트 코드와 CLEAR 및 STOP 코드를 내보낸다. 이는 더 간단한 인코딩(코드 값과 팔레트 코드 간의 1대1 대응)을 제공하지만, 모든 압축을 희생한다: 이미지의 각 픽셀은 해당 색상 인덱스를 나타내는 출력 코드를 생성한다. 압축되지 않은 GIF를 처리할 때, 표준 GIF 디코더는 문자열을 사전 테이블에 쓰는 것을 막지 않지만, 코드 너비는 절대 증가해서는 안 된다. 이는 비트와 바이트의 다른 패킹을 유발하기 때문이다.
심볼 너비가 이면, 너비가 인 코드는 자연스럽게 두 블록으로 나뉜다: 단일 심볼을 코딩하기 위한 개의 하위 블록 코드와 길이가 1보다 큰 시퀀스에 대해 디코더가 사용할 개의 상위 블록 코드. 이 상위 블록 중 처음 두 코드는 이미 사용 중이다: CLEAR의 경우 이고, STOP의 경우 이다. 디코더는 상위 블록의 마지막 코드인 도 사용하지 못하게 해야 한다. 디코더가 해당 슬롯을 채우면 코드 너비가 증가하기 때문이다. 따라서 상위 블록에는 코드 너비 증가를 유발하지 않는 개의 코드가 디코더에서 사용 가능하다. 디코더는 항상 테이블 유지에서 한 단계 뒤처져 있으므로 인코더로부터 첫 번째 코드를 받을 때 테이블 항목을 생성하지 않지만, 각 후속 코드에 대해 테이블 항목을 생성한다. 따라서 인코더는 코드 너비 증가를 유발하지 않고 개의 코드를 생성할 수 있다. 그러므로 인코더는 디코더가 코딩 사전을 재설정하도록 개의 코드 또는 그 이하의 간격으로 추가 CLEAR 코드를 내보내야 한다. GIF 표준은 이러한 추가 CLEAR 코드를 이미지 데이터에 언제든지 삽입할 수 있도록 허용한다. 복합 데이터 스트림은 각 1에서 255바이트를 포함하는 서브 블록으로 분할된다.
위 샘플 3x5 이미지의 경우, 다음 9비트 코드는 "지우기"(100) 뒤에 스캔 순서대로 이미지 픽셀 및 "정지"(101)를 나타낸다.
100 028 0FF 0FF 0FF 028 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 101
위 코드가 바이트로 매핑되면 압축되지 않은 파일은 압축된 파일과 다음과 같이 달라진다.
압축 예시.
단색의 큰 이미지라는 사소한 예시는 GIF 파일에 사용되는 가변 길이 LZW 압축을 보여준다.
표시된 코드 값은 바이트로 압축된 다음 최대 255바이트 블록으로 압축된다. 이미지 데이터 블록은 뒤따르는 바이트 수를 선언하는 바이트로 시작한다. 이미지의 마지막 데이터 블록은 0 블록 길이 바이트로 표시된다.
GIF 사양은 GIF 파일의 논리적 화면 내 각 이미지가 인터레이스되어 있음을 지정할 수 있도록 허용한다. 즉, 데이터 블록의 래스터 라인 순서가 순차적이지 않음을 의미한다. 이를 통해 전체 이미지가 그려지기 전에 인식될 수 있는 이미지의 부분적인 표시가 가능하다.
인터레이스된 이미지는 위에서 아래로 8픽셀 높이의 스트립으로 나뉘며, 이미지의 행은 다음 순서로 표시된다:
각 줄 내의 픽셀은 인터레이스되지 않고 왼쪽에서 오른쪽으로 연속적으로 표시된다. 비인터레이스 이미지와 마찬가지로 한 줄의 데이터와 다음 줄의 데이터 사이에 끊김이 없다. 이미지가 인터레이스되었음을 나타내는 것은 해당 이미지 디스크립터 블록에 설정된 비트이다.
애니메이션 GIF.
GIF는 애니메이션 매체로 설계되지는 않았지만, 하나의 파일에 여러 이미지를 저장하는 기능은 자연스럽게 애니메이션 시퀀스의 프레임을 저장하는 데 이 형식을 사용하도록 제안되었다. 애니메이션 표시를 용이하게 하기 위해 GIF89a 사양은 파일의 이미지(프레임)를 시간 지연과 함께 그려서 비디오 클립을 형성할 수 있는 그래픽 제어 확장(GCE)을 추가했다. 애니메이션 GIF의 각 프레임은 프레임이 그려진 후 기다릴 시간 지연을 지정하는 자체 GCE로 시작된다. 파일 시작 부분의 전역 정보는 기본적으로 모든 프레임에 적용된다. 데이터는 스트림 지향적이므로 각 GCE의 시작 파일 오프셋은 이전 데이터의 길이에 따라 달라진다. 각 프레임 내에서 LZW로 코딩된 이미지 데이터는 최대 255바이트의 서브 블록으로 배열되며, 각 서브 블록의 크기는 그 앞에 오는 바이트로 선언된다.
기본적으로 애니메이션은 프레임 시퀀스를 한 번만 표시하고 마지막 프레임이 표시되면 멈춘다. 애니메이션을 반복할 수 있도록, 1990년대 넷스케이프는 애플리케이션 확장 블록(벤더가 GIF 파일에 응용 프로그램별 정보를 추가할 수 있도록 의도됨)을 사용하여 넷스케이프 애플리케이션 블록(NAB)을 구현했다. 이 블록은 애니메이션 프레임 시퀀스 바로 앞에 배치되며, 프레임 시퀀스를 재생할 횟수(1에서 65535회) 또는 연속적으로 반복해야 하는지(0은 영원히 반복을 나타냄)를 지정한다. 이러한 반복 애니메이션에 대한 지원은 넷스케이프 내비게이터 버전 2.0에서 처음 등장했으며, 이후 다른 브라우저로 확산되었다. 대부분의 브라우저는 이제 NAB를 인식하고 지원하지만, 이는 GIF89a 사양의 엄격한 부분은 아니다.
다음 예시는 문서 정보 상자에 미리보기 이미지로 표시된 애니메이션 파일의 구조를 보여준다.
각 프레임의 애니메이션 지연은 GCE에 1/100초 단위로 지정된다. 프레임이 디스플레이의 일부 픽셀만 다시 그리면 되는 경우 데이터 절약이 가능하며, 이는 이미지 디스크립터가 전체 이미지가 아닌 다시 스캔될 작은 사각형을 정의할 수 있기 때문이다. 애니메이션 GIF를 지원하지 않는 브라우저 또는 다른 디스플레이는 일반적으로 첫 번째 프레임만 표시한다.
애니메이션 GIF 파일의 크기와 색상 품질은 파일을 생성하는 데 사용된 응용 프로그램에 따라 크게 달라질 수 있다. 파일 크기를 최소화하는 전략에는 모든 프레임에 공통 전역 색상 테이블을 사용하는 것(각 프레임에 완전한 로컬 색상 테이블을 사용하는 대신)과 연속 프레임에서 덮는 픽셀 수를 최소화하는 것(따라서 한 프레임에서 다음 프레임으로 변경되는 픽셀만 나중 프레임에 포함되도록)이 포함된다. 더 고급 기술은 기존 LZW 사전에 더 잘 맞도록 색상 시퀀스를 수정하는 것을 포함하며, 이는 손실 압축의 한 형태이다. 단순히 일련의 독립적인 프레임 이미지를 복합 애니메이션으로 압축하는 것은 큰 파일 크기를 초래하는 경향이 있다. 기존 GIF의 파일 크기를 최소화하는 도구를 사용할 수 있다.
메타데이터는 GIF 파일에 주석 블록, 일반 텍스트 블록 또는 애플리케이션별 애플리케이션 확장 블록으로 저장될 수 있다. 여러 그래픽 편집기는 이미지 생성에 사용된 데이터를 포함하기 위해 비공식 애플리케이션 확장 블록을 사용하여 추가 편집을 위해 데이터를 복구할 수 있도록 한다.
이러한 모든 방법은 기술적으로 메타데이터를 하위 블록으로 분할해야 하므로 애플리케이션은 내부 구조를 알지 않고도 메타데이터 블록을 탐색할 수 있다.
XMP 메타데이터 표준은 GIF 파일에 XMP 데이터를 포함하기 위한 비공식적이지만 현재 널리 사용되는 "XMP Data" 애플리케이션 확장 블록을 도입했다. XMP 데이터는 NUL 문자가 없는 UTF-8로 인코딩되므로 데이터에 0 바이트가 없다. 데이터를 공식적인 하위 블록으로 분할하는 대신, 확장 블록은 데이터를 하위 블록으로 처리하는 모든 애플리케이션을 하위 블록 체인을 종료하는 최종 0 바이트로 라우팅하는 "매직 트레일러"로 종료된다.
유니시스 및 LZW 특허 시행.
1977년과 1978년, 야콥 지브와 아브라함 렘펠은 새로운 종류의 비손실 데이터 압축 알고리즘에 대한 논문 두 편을 발표했는데, 현재는 총칭하여 LZ77 및 LZ78이라고 불린다. 1983년, 테리 웰치는 LZ78의 빠른 변형을 개발했으며, 이는 렘펠-지브-웰치(LZW)로 명명되었다.
웰치는 1983년 6월 LZW 방식에 대한 특허 출원을 제출했다. 그 결과 1985년 12월에 부여된 특허 US4558302는 스페리 코퍼레이션에 할당되었고, 스페리는 이후 1986년에 버로스 코퍼레이션과 합병하여 유니시스를 설립했다. 추가 특허는 영국, 프랑스, 독일, 이탈리아, 일본, 캐나다에서 취득되었다.
위의 특허 외에도, 웰치의 1983년 특허는 또한 그것에 영향을 미친 몇 가지 다른 특허를 인용하고 있다:
1984년 6월, 웰치의 논문이 IEEE 잡지에 실리면서 LZW 기술이 처음으로 공개적으로 설명되었다. LZW는 인기 있는 데이터 압축 기술이 되었고, 특허가 부여되자 유니시스는 백 개 이상의 회사와 라이선스 계약을 체결했다.
LZW의 인기로 인해 컴퓨서브는 1987년에 개발한 GIF 버전에 이를 압축 기술로 선택했다. 당시 컴퓨서브는 특허의 존재를 알지 못했다. 유니시스는 GIF 버전이 LZW 압축 기술을 사용한다는 사실을 알게 되었고 1993년 1월 컴퓨서브와 라이선스 협상을 시작했다. 그 후의 계약은 1994년 12월 24일에 발표되었다. 유니시스는 LZW 특허를 사용하는 모든 주요 상업 온라인 정보 서비스 회사가 유니시스로부터 합리적인 요율로 기술 라이선스를 받을 것으로 예상했지만, 온라인 서비스에 사용되는 비상업적, 비영리 GIF 기반 애플리케이션에 대해서는 라이선스 또는 수수료를 요구하지 않을 것이라고 밝혔다.
이 발표 이후 컴퓨서브와 유니시스에 대한 광범위한 비난이 있었고, 많은 소프트웨어 개발자들이 GIF 사용을 중단하겠다고 위협했다. 포터블 네트워크 그래픽스 (PNG) 형식(아래 참조)은 이를 대체하기 위해 1995년에 개발되었다. 그러나 PNG 형식에 대한 웹 브라우저 및 기타 소프트웨어 제작사의 지원을 얻는 것은 어려웠고, PNG의 인기가 점차 증가했음에도 불구하고 GIF를 대체하는 것은 불가능했다. 따라서 LZW 압축이 없는 GIF 변형이 개발되었다. 예를 들어, 에릭 레이먼드의 giflib을 기반으로 하는 libungif 라이브러리는 데이터 형식을 따르지만 압축 기능을 피하여 유니시스 LZW 특허 사용을 피하는 GIF 생성을 허용한다. 2001년 닥터 돕스 기사는 LZW 호환 인코딩을 특허 침해 없이 달성하는 방법을 설명했다.
1999년 8월, 유니시스는 라이선스 관행의 세부 사항을 변경하여 특정 비상업적 및 개인 웹사이트 소유자가 5000달러 또는 7500달러의 일회성 라이선스 비용을 지불하고 라이선스를 얻을 수 있는 옵션을 발표했다. 이러한 라이선스는 라이선스 소프트웨어를 사용하여 GIF를 생성한 웹사이트 소유자 또는 기타 GIF 사용자에게는 필요하지 않았다. 그럼에도 불구하고, 유니시스는 웹사이트에 GIF를 사용하면 5000달러를 청구하거나 고소당할 것이라고 믿는 사용자들로부터 수천 건의 온라인 공격과 모욕적인 이메일을 받았다. 유니시스는 수백 개의 비영리 단체, 학교 및 정부에 무료 라이선스를 제공했음에도 불구하고 어떠한 좋은 홍보도 얻지 못했으며, 1999년에 "모든 GIF 태워버리기" 캠페인을 시작한 League for Programming Freedom과 같은 개인 및 단체로부터 계속해서 비난을 받았다.
미국의 LZW 특허는 2003년 6월 20일에 만료되었다. 영국, 프랑스, 독일, 이탈리아의 대응 특허는 2004년 6월 18일에, 일본 특허는 2004년 6월 20일에, 캐나다 특허는 2004년 7월 7일에 만료되었다. 따라서 유니시스는 LZW 기술 개선과 관련된 추가 특허 및 특허 출원을 가지고 있지만, LZW 자체(및 결과적으로 GIF)는 2004년 7월부터 자유롭게 사용할 수 있게 되었다.
포터블 네트워크 그래픽스 (PNG)는 유니시스의 LZW 압축 기술에 대한 특허 침해를 피하기 위해 GIF의 대체제로 설계되었다. PNG는 GIF보다 더 나은 압축과 더 많은 기능을 제공하며, 애니메이션만이 유일한 중요한 예외이다. PNG는 트루컬러 이미징과 알파 투명도가 필요한 경우 GIF보다 더 적합하다.
PNG 형식 지원은 천천히 이루어졌지만, 새로운 웹 브라우저는 PNG를 지원한다. 인터넷 익스플로러의 이전 버전은 PNG의 모든 기능을 지원하지 않는다. 버전 6 이하에서는 마이크로소프트 특정 HTML 확장을 사용하지 않으면 알파 채널 투명도를 지원하지 않는다. PNG 이미지의 감마 보정은 버전 8 이전에는 지원되지 않았으며, 이전 버전에서 이러한 이미지를 표시하면 잘못된 색조를 가질 수 있었다.
동일한 8비트(또는 그 이하) 이미지 데이터의 경우, PNG 인코딩에 사용되는 더 효율적인 압축 기술 덕분에 PNG 파일은 일반적으로 해당 GIF보다 작다. GIF에 대한 완전한 지원은 주로 허용하는 복잡한 캔버스 구조로 인해 복잡하지만, 이것이 바로 컴팩트한 애니메이션 기능을 가능하게 하는 요인이다.
애니메이션 형식.
비디오는 웹에서 흔히 사용되는 GIF가 가진 많은 문제를 해결한다. 여기에는 현저히 작은 파일 크기, 8비트 컬러 제한을 초과하는 능력, 프레임 간 코딩을 통한 더 나은 프레임 처리 및 압축이 포함된다. 웹 브라우저에서 GIF 형식에 대한 거의 보편적인 지원과 HTML 표준에서 비디오에 대한 공식 지원 부족으로 인해 GIF는 웹에서 짧은 비디오와 같은 파일을 표시하는 목적으로 부상했다.
2014년 4월, 4chan은 크기가 3MB 미만이고 길이가 2분인 무음 WebM 비디오를 지원하기 시작했으며, 2014년 10월에는 Imgur가 사이트에 업로드된 모든 GIF 파일을 H.264 비디오로 변환하고 HTML 플레이어 링크에 codice_2 확장자를 가진 실제 파일처럼 보이도록 제공하기 시작했다.
2016년 1월, 텔레그램은 모든 GIF를 MPEG-4 비디오로 다시 인코딩하기 시작했는데, 이는 "동일한 이미지 품질에 대해 최대 95% 적은 디스크 공간을 필요로 한다."
한국어 위키백과(, 약칭 한위백)는 한국어로 운영되는 위키백과의 다언어판 가운데 하나로서, 2002년 10월 11일에 시작되었다. 또한 년 일 현재 한국어 위키백과에는 넘겨주기, 토론, 그림 등 페이지로 불리는 모든 문서를 포함하면 총 개가 수록되어 있으며, 넘겨주기를 포함한 일반 문서 수는 개, 그중 넘겨주기, 를 제외한 일반 문서 수는 개이다. 위키백과 언어판 중에서 번째로 크고 한국어로 된 위키 중에서는 1위 규모이며, 기호는 ko이다.
위키백과의 최상위 도메인이 .com이던 시절 ko.wikipedia.com에 구판 미디어위키가 깔렸으나 한글 처리에 문제가 있어 글을 올릴 수도 없는 이름뿐인 곳이었다. 2002년 10월에 새로운 위키 소프트웨어를 쓰면서 한글 처리 문제가 풀리기 시작했지만, 가장 많은 사람이 쓰는 인터넷 익스플로러에서는 인코딩 문제가 여전했다. 이런 이유로 초기에는 도움말을 옮기거나 쓰는 일에 어려움을 겪었다. 이런 어려움이 있었는데도 위키백과 통계로는, 2002년 10월에서 2003년 7월까지 열 달 사이에 글이 13개에서 159개로 늘었고 2003년 7월과 8월 사이에는 한 달 만에 159개에서 348개로 늘어났다. 2003년 9월부터는 인터넷 익스플로러의 인코딩 문제가 사라졌으며, 대한민국 언론에서도 몇 차례 위키백과를 소개하면서 참여자가 점증하리라고 예측했다. 참고로 한국어 위키백과의 최초 문서는 2002년 10월 12일에 등재된 지미 카터 문서이다.
2005년 6월 5일 양자장론 문서 등재를 기점으로 총 등재 문서 수가 1만 개를 돌파하였고 이어 동년 11월에 제1회 정보트러스트 어워드 인터넷 문화 일반 분야에 선정되었다. 2007년 8월 9일에는 《한겨레21》에서 한국어 위키백과와 을 취재한 기사를 표지 이야기로 다루었다.
2008년 광우병 촛불 시위 때 생긴 신조어인 명박산성이 한국어 위키백과에 등재되고 이 문서의 존치 여부를 두고 갑론을박의 과정이 화제가 되고 각종 매체에도 보도가 되었다. 시위대의 난입과 충돌을 방지하기 위해 거리에 설치되었던 컨테이너 박스를 이명박 정부의 불통으로 풍자를 하기 위해 사용된 이 신조어는 을 지켰는지와 인지가 쟁점이 되었는데 일시적으로 사용된 신조어일 뿐이라는 주장과 이미 여러 매체에서 사용되어 지속성이 보장되었다는 주장 등 논쟁이 벌어졌고 《다음 아고라》 등지에서 이 항목을 존치하는 방안을 지지하는 의견을 남기기 위해 여러 사람이 새로 가입하는 등 혼란이 빚어졌다. 11월 4일에는 다음커뮤니케이션에서 《글로벌 세계 대백과사전》을 기증받았으며, 2009년 3월에는 서울특별시로부터 를 기증받았다. 2009년 6월 4일에는 액세스권 문서의 등재를 기점으로 10만 개 문서 수를 돌파했다.
2011년 4월 16일에는 대한민국에서의 위키미디어 프로젝트를 지원하는 모임을 결성할 것을 추진하는 논의가 이뤄졌고 이후 2012년 3월 10일 위키미디어 대한민국 지부 창립준비위원회 결성을 거쳤다. 2014년 10월 19일 창립총회를 개최하였으며, 최종적으로 2015년 11월 4일 사단법인 가 결성되어 활동 중에 있다. 그리고 2019년 미국 위키미디어재단으로부터 한국 지역 지부(챕터)로 승인을 받았다.
2012년 5월 19일에는 보비 탬블링 문서의 등재를 기점으로 총 20만 개 문서가 등재되었고 2015년 1월 5일, 《Rojo -Tierra-》 문서 등재를 기점으로 총 30만 개 문서, 2017년 10월 21일에는 충청남도 동물위생시험소 문서 등재로 40만 개의 문서까지 등재되었다. 2020년 6월 15일에는 규장전운 문서의 등재로 50만 개의 문서까지 등재되었으며 2022년 8월 16일 광기의 밍크스 문서를 기점으로 60만 문서가 등재되었다. 2025년 3월 18일에 70만 번째 문서인 존 몽고메리가 등재되었다.
한국어 위키백과는 한국어의 문자인 한글로 쓰이며 한자는 표제어를 한자 표기하거나 동음이의어로 인한 혼란을 방지하기 위한 병행 표기의 용도로만 쓰인다. 국한문혼용 표기 도입을 추진하는 라는 그룹이 있었고 국한문혼용 프로젝트를 위한 본래 한국어 위키백과와 분리된 프로젝트의 설립이 추진되었으나 메타위키에서 거부되었다.
한국어를 쓰는 사람들은 주로 대한민국과 조선민주주의인민공화국에 거주하고 있으나 조선민주주의인민공화국 사람들은 인터넷 검열로 인해 접속을 하지 못해 한국어 위키백과를 대표하지 않고 있고 대한민국 사람들이 대부분 한국어 위키백과를 편집하고 있다. 이에 따라 현재 한국어 위키백과의 공식 표기는 한국어를 조선민주주의인민공화국에서 가리키는 말인 '조선어'를 쓰지 않고 '한국어'를 쓰고 있다. 다만 '조선민주주의인민공화국'의 표기는 모든 국가와 집단에 대해서 중립적 시각을 지킨다는 원칙에 따라 대한민국에서 쓰는 말인 '북한'이라는 말은 지양하고 대신 '조선민주주의인민공화국'이란 용어로 풀어서 쓰고 있다.
파생 서비스.
2005년 8월 11일부터는 엠파스에서 한국어 위키백과 테이터베이스를 검색해 자신들의 통합 검색을 이용하여 검색하는 사용자들에게 제공하기 시작했다. 2007년 7월 6일부터는 SK텔레콤에서 SK텔레콤 가입자들이 휴대전화 무선 인터넷 네이트를 이용해 한국어 위키백과의 문서를 검색하는 서비스를 시작했다. 8월 21일부터는 포털사이트 다음이 백과사전 서비스에 사용하고자 한국어 위키백과와 영어 위키백과의 글을 가져가 반영하였으며 네이버도 2008년 1월 11일부터 한국어 위키백과와 영어 위키백과의 글을 검색 결과에서 우선으로 노출한다.
사건사고 및 비판.
내부적 문제.
인터넷이 잘 발달되어 있다고 평가받는 대한민국에선 다른 언어판인 일본어 위키백과, 영어 위키백과 등 다른 언어판에 비해 부진하다는 평가를 받는다. 이 원인에 대해서 지미 웨일스는 네이버 지식iN 등 집단협업 서비스가 이미 제공되어 있었고 다른 나라에서는 위키백과와 같은 모델에 처음 소개될 때가 인터넷이 막 구축이 되던 시기여서 매우 열광적인 호응을 얻었던 반면 대한민국은 그렇지 않았기에 별다른 반응을 얻지 못해서 부진하고 있다고 말했다. 진중권 교수는 서양에서는 16세기 구텐베르크 인쇄술 발명을 시작으로 해서 문자 문화가 역사적으로 발달해왔지만 대한민국은 문맹 탈출의 역사가 몇십 년 밖에 안되었고 구술 문화가 강해서 부진하고 있다고 분석하였다. 그 외에도 전문직 종사자들이 지식의 기부 활동에 소극적이다는 점, 사회 전반적으로 전문화 수준이 낮다는 점, 대한민국에 협업 문화가 성숙되지 않았다는 점 등이 한국어 위키백과의 부진의 원인으로 거론되고 있다.
한국어 위키백과를 비판하는 사람들은 내용 중에 일차 서술이 아닌 번역된 내용이 많다고 지적한다. 다수의 사람의 참여와 토론으로 전문적 지식을 쌓고자 하는 본연의 취지가 흐려진다는 것이 지적의 이유이다.
2016년 8월 2일, 위키트리는 나무위키가 고유의 편향적 매력으로 서비스 약 1년 만에 대한민국에서 한국어 위키백과를 대체하였다고 보도하였다. 한국어 위키백과는 중립적 시각을 지키고 출처가 있어야 하는 등 진입 장벽은 높은 편인데 반해, 나무위키는 중립적인 시각을 찾기 어렵고 지나치게 주관적이라는 비판이 있으나 편향적 서술을 허용하고 편집도 엄격하지 않게 되어있는 등 진입 장벽이 낮은 편이다.
문서 훼손.
2008년 12월 18일, 한 IP 사용자가 성승헌 문서에 "성승헌은 캐스터이다. 그리고 똥을 잘 싼다. 뿌직뿌직."이라는 내용으로 교체를 하였고 이는 이내 1분 만에 되돌려졌다. 하지만 이 내용이 그대로 네이버 검색에 노출된 채로 장기간 방치되고 이내 여러 사이트에 퍼져 화제가 되고 네이버 실시간 검색어 1위까지 올라갔던 바가 있다. 성승헌 본인은 이 사건에 대해 이 단어를 지적재산권으로 등록하고 사업에서 써먹을 생각하고 있다며 좋게 생각하고 있다고 하였다.
2017년 2월 28일에는 문재인 문서와 이재명 문서에 가해진 문서훼손이 타 사이트로 그대로 노출되는 사건이 있었다. 문재인과 이재명의 기본 정보에서 국적을 대한민국에서 조선민주주의인민공화국의 정치인으로 바꿔놓은 문재인 문서 2017년 2월 27일 (월) 03:23 판와 2017년 2월 27일 (월) 03:13 판이 포털사이트 네이버에 그대로 갱신된 것인데, 위키백과 문서는 오후 9시에 문재인 문서가 수정되었고 이재명 문서도 9시에 수정되었으나 네이버 검색결과는 오후 4시에 들어서 뒤늦게 정정되었다. 이에 대해 문재인 측은 편집의 고의성 여부를 따져 강경하게 대응할 방침을 시사하고, "허위 사실 유포가 개인 행위로 넘기기에는 위험한 측면이 있다"면서 "특정인의 조직적 사주 여부를 확인할 필요"가 있다고 밝혔다. 중앙선거관리위원회 역시 "가짜 정보 유포는 당장 선거법으로 규제하기에는 논란의 여지가 있으나, 선거를 앞두고 당선과 낙선을 위해 의도적ㆍ조직적 허위사실 유포 행위를 지속할 경우, 법적 처벌을 강구할 필요가 있다"는 입장을 밝혔다. 서울중앙지검 공안2부는 이와 같이 문서에 허위 사실을 기재한 건으로 소프트웨어 개발업체 대표 양모씨를 공직선거법 위반과 정보통신망이용촉진 및 정보보호 등에 관한 법률 위반 혐의로 불구속 기소하였다.
30km 이내에 다울라기리, 안나푸르나, 마나슬루 등 8,000 m가 넘는 고봉이 위치하고 있다. 페와 호수 등 포카라 인근 어디에서도 고봉들을 조망할 수 있어 관광객들이 많이 찾고 있는데, 특히 인근에 있는 사랑곳은 고봉을 조망할 수 있는 최적의 장소로 꼽히고 있다.
네팔어로 포카라()는 연못을 의미한다. 포카라 시내에 많은 연못들이 자리하고 있어서 이러한 이름이 붙여진 것으로 추정된다.
포카라가 위치한 네팔 서부는 자연재해가 자주 일어난다. 세티 간다키강이 이 도시를 관통하기 때문에 지진과 홍수에 특히 취약하다. 또한 포카라는 2015년 4월 네팔 지진에 의해 심한 피해를 입었다.
1990년대 이후 포카라는 급속한 도시화를 겪었다. 결과적으로 서비스업 부문 산업은 전통적인 농업을 능가하여 네팔 최고 수준의 높은 땅값이 나타나고 있다.  포카라 경제의 주요 기여자는 관광을 포함한 제조업 및 서비스업이다.
바그마티강은 네팔의 수도인 카트만두를 흐르는 성스러운 강인데, 카트만두 계곡의 북쪽에 있는 언덕에서 발원하여 카트만두 시내 중심을 통과한다. 힌두교 성지의 하나인 파슈파티나트 사원은 바그마티 강변에 위치하고 있는데, 특히 이 사원 주변은 화장터로 이용되고 있다.
카트만두 외에도 파탄과 박타부르 등 카트만두 계곡의 주요도시들도 바그마티강을 끼고 발달하였다.
크리에이티브 커먼즈(Creative Commons, CC)는 저작권의 부분적 공유를 목적으로 2001년에 설립된 비영리 단체이다. 이 기관은 2002년 12월 16일에 저작권 라이선스인 크리에이티브 커먼즈 라이선스(CCL)를 만들었다.
크리에이티브 커먼즈 라이선스(CCL)를 따르는 대표적인 프로젝트에는 위키백과가 있다. 위키백과는 크리에이티브 커먼즈(CCL)와 GNU 자유 문서(GFDL)의 2중 라이선스를 따른다.
크리에이티브 커먼즈는 2001년 샌프란시스코에 본부를 두고 시작되었다. 설립자이자 회장인 로런스 레시그 교수는 그가 맡았던 엘드리드 대 애시크로프트 사건에서 불거진 문제를 해결하기 위해서 이 조직을 만들었다.
이 중에 변경 금지 조항과 동일조건 변경 허락 조항은 동시에 사용할 수 없으므로 총 11가지의 라이선스를 사용할 수 있다. 그리고 많은 나라에서 저작자 표시를 기본 사항으로 채택하고 있어 퍼블릭 도메인과 함께 일반적으로 다음의 7가지를 선택할 수 있다.
지역화.
크리에이티브 커먼즈 라이선스는 미국의 저작권을 염두에 두고 개발되었다. 따라서 개별 나라의 사정에 맞지 않을 수도 있기에, 이를 각 나라에 맞도록 수정하는 iCommons 프로젝트를 진행하고 있다. 2008년 기준으로 대한민국을 포함한 50개국에서 이 작업이 완료되었고, 아일랜드, 요르단 등 5개국에서 작업이 진행 중이다. 대한민국에서는 "사단법인 한국정보법학회"가 이 일을 맡아서, 대한민국 법에 맞는 크리에이티브 커먼즈 라이선스를 개발하여 발표하고 있다. 대한민국에 맞춘 지역화가 완료된 최신 버전은 2.0이다.다만, 대한민국에 지역화된 CCL은 2.0 버전이 이미 국제화 버전의 3.0에서 해결된 문제를 해결하여, 버전의 업그레이드만 없었을 뿐이라고 하였다.
CCL 4.0 버전부터는 국제 공통 라이선스로 변경되어 개발 중이다. 또한, 4.0 미만의 버전에서는 해당 라이선스가 적용되는 지역을 명확히 구분해야 한다. 한국어로 표시되었다고 해도, 단순 번역임과 동시에 라이선스 내용이 다른, 다른 국가의 라이선스 일 수 있기 때문이다.
남극점(南極點)은 보통 지구의 가장 남쪽, 남위 90° 지점을 말한다. 현재 조금씩 이동하고 있다. 평균 고도는 2835m이다.
최초로 남극점에 도달한 것은 노르웨이의 로알 아문센의 팀으로 1911년 12월 14일에 도달하였다. 경쟁자였던 로버트 팰컨 스콧은 한 달 늦게 남극점에 도달하였다. 스콧 일행은 되돌아오는 길에 추위와 허기에 지쳐 모두 사망했다.
대부분의 목적에서 지리 남극은 지구의 회전 축이 지표면과 교차하는 두 지점의 남쪽 지점(다른 곳은 북극 지형)으로 정의된다. 그러나 지구의 자전축은 실제로 매우 작은 "웨이블"(극기 운동)을 받으므로 이 정의는 매우 정밀한 작업에 적합하지 않다.
남극의 경도는 기하학적으로 정의되지 않고 무관하기 때문에 보통 90°S로 단순하게 주어진다. 경도가 필요할 때는 } 남극에서는 사방이 북쪽을 향한다. 이러한 이유로 북극의 방향은 위선을 따라 북쪽을 가리키는 "그리드 북쪽"에 비례하여 지정된다. 지리적으로 남극점은 남극대륙에 위치한다(그러나 지구의 역사는 대륙의 표류 때문에 지구의 역사의 모든 경우에 해당되지는 않았다). 해발 2,835미터의 고도에서 척박하고 바람이 잘 불지 않는 빙판 위에 위치하고 있으며, 고래의 만에서 가장 가까운 공해로부터 약 1,300km 떨어진 곳에 위치해 있다. 이 얼음의 두께는 약 2700m로 추정되기 때문에, 얼음판 아래의 지표면은 실제로 해수면과 가깝다. 남극 빙판은 북쪽으로 37°에서 40° 사이의 방향으로 매년 약 10m의 속도로 움직이고 있다. 따라서 지리적 극과 관련된 역의 위치와 기타 인공적인 특징들은 시간이 지남에 따라 점차 이동한다.
지리적으로 남극점은 작은 표지판과 함께 얼음의 말뚝으로 표시되어 있다; 이것들은 매년 1월 1일에 재배치, 재배치 기념식이 열린다. 얼음의 움직임에 의해 남극점의 위치도 변하고 있기 때문이다. 남극점 표지판에는 로알 아문센과 로버트 팰컨 스콧이 정복한 날짜가 각각 기록되어 있다.
북극점(北極點)은 지구의 가장 북쪽 지점을 말한다. 북극해의 가운데에 있으며 북극점 지점의 깊이는 4087 m이다.
북극점은 지구 최북단 지점으로서, 남극점과 직경으로 정반대 지점에 위치해 있다. 측지학상으로는 북위 90도의 기준이 되며 진북의 방향을 삼는 데도 기준이 된다. 북극점을 기준으로 하면 어느 방향이든 남쪽을 향해 가리키게 되며, 모든 경선이 만나는 지점이기에 어느 경도이든 북극점이 한 축의 기점이 된다. 북극점 주변의 위선을 따라 반시계 방향으로 돌면 동쪽을 향하고, 시계 방향으로 돌면 서쪽을 향하게 된다. 그밖에 북극점은 북반구의 중앙 지점이기도 하다.
남극점은 남극이라는 대륙 위에 있지만 북극점은 북극해의 중심 해역에 위치해 있으며, 그 바다는 지속적으로 움직이는 반영구 해빙으로 뒤덮여 있다. 이 때문에 남극점과는 달리 북극점에 영구 기지를 건설하기란 불가능에 가깝다. 하지만 구소련 (이후 러시아)가 1937년부터 해마다 유빙 기지를 여러 곳 지은 바 있으며, 그 중 일부는 북극점을 지나치거나 매우 근접하기도 했다. 2002년부터 러시아는 매년 바르네오 기지를 북극점 부근에 설치하고 있다. 바르네오 기지는 봄이 찾아온 몇 주 동안만 운영된다. 2000년대에는 북극 해빙면적 감소로 북극점 일대가 계절에 따라 얼음이 사라질 수도 있다는 예측이 나온 바 있으며, 그 시점은 2016년에서 21세기 말 이후까지 다양하다.
북극점의 수심은 2007년 러시아의 미르 잠수함이 4,261m, 1958년 USS 노틸러스 호가 4,087m로 측정한 적이 있다. 북극점에서 가장 가까운 땅은 보통 그린란드 북부의 카페클루 섬을 꼽으며, 거리는 700km에 불과하다. 다만 계절에 따라 사주가 북극점에 살짝 더 근접해 있기도 하다. 북극점에서 가장 가까운 영구 유인지는 캐나다 누나부트 준주 키킥탈루크 지방의 앨러트 마을로, 817km 떨어진 거리에 위치해 있다.
16세기부터 많은 지리학자들은 북극점이 바다 속에 위치해 있다고 생각했으며, 19세기에는 이를 ‘폴리니야(polynya)’ 또는 ‘개방된 극지해’라고 불렀다. 독일의 지리학자 아우구스트 페터만은 얼음이 없는 극지해의 존재를 강력히 주장한 인물이다. 비록 이 이론은 이후 잘못된 것으로 판명되었으나, 1853년부터 1876년까지 여러 탐험이 이 이론을 근거로 수행되었다. 탐험가들은 해빙기 때 얼음이 없는 항로를 통해 북극점에 도달할 수 있기를 희망하였다.
1596년 6월 16일 네덜란드 탐험대가 빌럼 바렌츠의 지휘 아래 북위 79도 49분에 도달하여 인류가 도달한 가장 북쪽 기록을 세웠다. 바렌츠는 다음 해 사망하였다.
1893년 프리드퇴프 난센과 할마르 요한센은 ‘프람’이라는 선박을 이용한 탐험을 진행하였는데, 이 선박은 새로운 유형의 쇄빙선의 시초가 되었다. 그들은 1895년 4월 8일 북위 86도 14분에 도달하여 북극점에 가장 근접한 인간이 되었다
1908년 미국인 프레더릭 쿡은 두 명의 이누이트와 함께 소규모 탐험을 조직하였다. 그는 1908년 4월 21일 북극점에 도달했다고 주장하였으나, 긴 여정을 거쳐 1909년 4월 18일에야 기지로 돌아왔다. 그의 증언은 여러 역사학자들에 의해 의심받았으며, 쿡이 위치를 잘못 계산했을 가능성이 제기되었다. 일부는 쿡이 실제 경로를 조작했으며, 실제로는 북극점 접근을 시도조차 하지 않았을 것이라는 증거도 발견하였다. 이 탐험의 역사는 오늘날까지도 논란이 되고 있다.
미국인 로버트 피어리는 1909년 4월 6일 매튜 헨슨과 네 명의 이누이트인 우타, 에깅와, 시글루, 우키아와 함께 북극점에 도달했다고 주장하였다. 그는 미국 의회로부터 그 업적에 대한 인정을 어렵게 얻어내어, 결국 공식적으로 북극점에 최초로 도달한 인물로 지정되었다. 그러나 피어리의 일기 사본이 발견된 이후, 그의 위치 추정이 잘못되었으며 실제로는 북극점에서 약 40킬로미터 떨어진 지점까지 접근했을 가능성이 거의 확실시되고 있다.
당시 탐험가 사회는 피어리가 북극점으로 향한 마지막 200킬로미터 구간에서 어떠한 위치 측량도 하지 않았다는 점을 강하게 비판하였다. 또한 로버트 M. 브라이스는 피어리가 귀환 시 유지했다고 주장한 평균 속도가 인간적으로 불가능한 수준이며, 이후로도 결코 재현된 적이 없다고 지적하였다. 한편, 아프리카계 미국인 탐험가 매튜 헨슨은 피어리보다 45분 먼저 북극점에 도착하여 탐험대에서 가장 먼저 북극점에 도달한 인물이었으나, 그는 흑인이었기에 모든 영예는 피어리에게 돌아갔다.
북극점에 확실히 도달한 최초의 인물들은 이탈리아인 움베르토 노빌레와 노르웨이인 로알 아문센으로, 이들은 1926년 3월 29일 로마를 출발하여 4월 14일 오슬로를 경유한 이탈리아 비행선 노르게(Norge)를 타고 북극점을 비행하였다. 두 사람은 1926년 5월 12일 북극점을 비행하며 통과하였다.
소련의 이반 파파닌은 1937년 5월 21일 비행기로 북극점에 착륙하였으며, 영국인 월리 허버트는 1969년 4월 5일 개썰매를 이용하여 북극점에 도달하였다.
1958년에는 미국 잠수함 USS 노틸러스가 북극해를 횡단하며 최초로 북극점에 도달한 잠수함이 되었으며, 1959년에는 USS 스케이트가 북극점에서 수면으로 부상한 최초의 잠수함이 되었다.
1977년 8월 17일 소련의 원자력 쇄빙선 아르크티카는 최초로 북극점에 도달한 표면선박이 되어 여름철 북극 해역 항해가 가능함을 입증하였다.
1978년 4월 29일 일본 탐험가 나오미 우에무라는 800킬로미터의 여정을 거쳐 단독으로 북극점에 도달한 최초의 인물이 되었다. 그는 캐나다 엘즈미어섬 북쪽의 케이프 콜럼비아에서 출발하여 피어리 탐험대의 경로를 따라 17마리 개가 끄는 썰매를 이용하였다. 우에무라는 항공기로부터 식량 보급을 정기적으로 받으며 여정을 완수하였다.
1982년 래널프 피언스와 찰스 버턴은 단일 시즌에 북극해를 횡단한 최초의 인물이 되었다. 1982년 2월 17일, 그들은 엘즈미어섬 인근의 크로지어 섬을 출발하여 1982년 4월 11일 북극점에 도달하였다. 이들의 탐험은 도보와 스노모바일을 이용하여 진행되었다. 북극점 도달 후, 그들은 스발바르 제도를 향해 남쪽으로 이동을 시도했으나, 빙판의 불안정성으로 인해 빙하 가장자리에서 여정을 중단하고, 약 99일간 빙판 위에서 남쪽으로 표류하였다.
결국 1982년 8월 4일 북위 80도 31분 지점에서 탐험선 MV 벤자민 보링호에 도착할 수 있었다. 이 탐험 이후, 피언스와 버턴은 3년에 걸친 트랜스글로브 탐험에 참가하여, 두 극지를 모두 통과하는 세계 일주를 완수한 최초의 인물이 되었다. 이 업적은 현재까지도 의심받지 않고 있으며, 기네스 세계 기록은 래널프 피언스를 “현존하는 최고의 탐험가”로 평가하고 있다.
1986년 5월 1일 윌 스테거 국제 극지 탐험대는 보급 없이 북극점에 도달한 최초의 탐험대가 되었다. 팀원은 폴 셔크, 브렌트 바디, 리처드 웨버, 제프 캐롤, 앤 뱅크로프트 및 21마리의 개들로 구성되었다. 브렌트 바디와 리처드 웨버는 북극점에 도달한 최초의 캐나다인이 되었으며, 앤 뱅크로프트는 최초의 여성으로 기록되었다. 그로부터 며칠 후인 5월 11일, 장루이 에티엔은 63일간의 도보 여정을 거쳐 스키로 단독 북극점에 도달한 최초의 프랑스인이 되었다.