이미지 파일 목록 프로그램 ‘lsix’ 출시

 (github.com/hackerb9)
4P by GN⁺ | ★ favorite | 댓글 1개
  • lsix는 ls처럼 현재 디렉터리나 지정한 파일 목록을 대상으로 이미지를 터미널 안에 썸네일로 보여주는 Bash 스크립트이며, 출력에는 Sixel 그래픽을 사용함
  • ImageMagick을 사용해 여러 이미지 형식을 처리하며, GIF나 여러 이미지를 담은 파일을 명령줄에 지정하면 프레임을 펼쳐 몽타주로 표시함
  • 터미널의 Sixel 지원 여부, 전경색·배경색, 색상 레지스터 확장 가능 여부, 창 너비를 감지해 썸네일 품질과 배치를 조정함
  • 설치는 lsix 파일을 경로에 넣고 ImageMagick을 준비하면 되며, macOS에서는 brew install lsix로 ImageMagick까지 함께 설치할 수 있음
  • XTerm은 기본적으로 Sixel 모드가 꺼져 있고 일부 터미널은 호환되지 않으므로, 실제 사용 전 Sixel 호환 터미널인지 확인해야 함

ls처럼 쓰는 터미널 이미지 목록 도구

  • lsix는 이미지용 ls에 가까운 도구로, 터미널에서 파일 썸네일을 인라인으로 보여줌
  • 기본 실행 방식은 단순함
    • lsix만 입력하면 현재 작업 디렉터리의 이미지를 표시함
    • lsix [ FILES ... ] 형태로 파일명을 지정할 수 있음
    • 셸 와일드카드를 사용할 수 있어 lsix *jpg * png 같은 실행이 가능함
  • 출력에는 Sixel 그래픽을 사용함

ImageMagick 기반 형식 처리와 표시 방식

  • ImageMagick을 사용하므로 다양한 이미지 형식을 지원함
  • PDF처럼 렌더링이 느릴 수 있는 형식은 명시적으로 요청하지 않으면 표시하지 않음
    • 특정 형식을 강제로 나열하려면 파일명을 직접 지정하거나 *.pdf 같은 와일드카드를 사용함
  • GIF 또는 여러 이미지를 포함한 파일을 명령줄에 지정하면 모든 프레임을 펼쳐 몽타주로 보여줌
    • GIF는 일부 프레임을 이전 프레임과 달라진 픽셀만 저장할 수 있음
  • 비트맵이 아닌 그래픽도 동작할 수 있음
    • 예: .svg, .eps, .pdf, .xcf

터미널 환경 감지 기능

  • lsix는 제어 시퀀스를 사용해 터미널이 Sixel 그래픽을 인라인으로 표시할 수 있는지 감지함
  • PNG와 SVG의 알파 채널은 터미널 배경색에 맞춰 처리됨
    • lsix는 터미널 이스케이프 시퀀스로 전경색과 배경색을 알아내려 함
    • 전경색은 텍스트 채움 색상에 사용됨
  • xterm처럼 색상 레지스터 수를 늘릴 수 있는 터미널을 감지하면 이미지 품질을 높이기 위해 자동으로 확장함
  • dtterm WindowOps를 지원하는 터미널에서는 창 너비에 맞춰 한 줄의 타일 수를 조정함
  • 디렉터리에 이미지가 많을 때는 전체 몽타주 생성을 기다리지 않도록 처리함
    • 이미지가 21개 초과이면 한 줄씩 표시함
  • 파일명이 너무 길면 ImageMagick montage에 넘기기 전에 텍스트를 줄바꿈함
    • lsix 없이 montage를 쓰면 긴 파일명이 서로 겹칠 수 있음
  • Unicode 파일명은 사용하는 폰트에 글리프가 있으면 동작함

설치와 설정 방식

  • 설치는 lsix 파일을 /usr/local/bin 같은 경로에 넣고 실행하면 됨
  • lsix는 Bash 셸 스크립트임
  • 필수 소프트웨어는 ImageMagick뿐임
    • 예: apt-get install imagemagick
  • macOS 사용자는 brew install lsix를 사용할 수 있음
    • 필요한 경우 ImageMagick도 함께 설치됨
  • 현재 설계는 매우 단순함
    • 명령줄 플래그 없음
    • 설정 파일 없음
    • 조정용 노브 없음
  • 타일 너비, 폰트 패밀리, 포인트 크기 같은 값은 파일 상단의 변수 수정으로 바꿀 수 있음
    • 설치된 폰트 목록은 convert -list font로 확인할 수 있음

Sixel 지원 터미널 요구사항

  • 터미널은 Sixel 그래픽을 지원해야 함
  • 단일 이미지를 Sixel로 출력해 터미널을 테스트할 수 있음
convert foo.jpg -geometry 800x480 sixel:-
  • 개발에는 xterm의 vt340 에뮬레이션 모드가 사용됨
  • XTerm은 기본적으로 Sixel 모드가 켜져 있지 않음
    • 실행 시 xterm -ti vt340을 사용할 수 있음
    • 또는 .Xresources에 xterm*decTerminalID : vt340을 추가하고 xrdb -merge .Xresources를 실행할 수 있음
  • Fedora 같은 일부 배포판은 xterm을 Sixel 지원 없이 컴파일할 수 있음
    • 이 경우 foot 또는 mlterm 같은 대체 터미널을 시도할 수 있음

호환 터미널과 비호환 터미널

  • Sixel 호환 터미널로 확인되거나 보고된 항목
    • XTerm, MLterm, foot, Wezterm, Contour, iTerm2 for Apple MacOS, Yaft는 테스트됨
    • Konsole, yakuake, WSLtty for Microsoft Windows, MinTTY for Cygwin, VTE 특수 컴파일, sixel-tmux, ttyd는 보고됨
  • Sixel 비호환 터미널
    • MacOS Terminal, kitty
    • 표준 libvte 기반 터미널
      • gnome-terminal
      • terminator
      • lxterm
    • Alacritty는 패치를 적용하면 동작할 수 있음

알려진 버그와 제약

  • XTerm의 reverse video 모드인 xterm -rv는 전경색과 배경색을 명시적으로 지정하는 것과 다름
    • 명시 지정은 감지할 방법이 있지만 reverseVideo 리소스는 감지할 수 없어 배경색이 틀릴 수 있음
  • XTerm의 화면 너비는 현재 1000px로 제한됨
    • 1000x1000보다 큰 이미지를 xterm이 처리할 수 있게 되면 제한을 제거할 예정임
    • 마지막 테스트는 XTerm(344) 기준임
  • @로 시작하는 파일명은 ImageMagick에서 특별하게 취급됨
    • lsix ./@foo.png처럼 디렉터리를 앞에 붙여야 함
    • 이는 lsix가 아니라 ImageMagick 버그임
  • 빈 문자열 ""을 파일명으로 지정하면 ImageMagick이 멈춤
    • ImageMagick 버그 또는 잘못된 동작으로 보임
  • 긴 파일명 줄바꿈은 동작하지만 지능적이지 않음
    • 공백, 대시, 언더스코어, 마침표 기준 줄바꿈은 아직 구현되지 않음
  • 명령줄에 디렉터리를 지정하면 사용자가 그 디렉터리로 cd한 것처럼 처리함
    • 재귀 처리는 어렵지 않지만 단순한 스크립트에 명령줄 플래그를 추가하는 점을 꺼림
  • lsix foo.avi 실행은 문제를 일으킬 수 있음

Sixel 표준과 구현상의 한계

  • Sixel 표준에는 그래픽 화면 크기를 질의하는 방법이 없는 것으로 보임
  • VT340 문서를 기준으로 보면 렌더링 대상 장치의 해상도를 프로그램이 이미 알고 있어야 함
  • XTerm 344는 이 문제를 해결하는 제어 시퀀스 CSI ? Pi ; Pa ; Pv S를 추가함
    • mlterm 같은 일부 터미널은 아직 구현하지 않음
  • dtterm WindowOps 확장으로 창 크기를 읽는 대안이 있음
    • Sixel 그래픽 화면의 기하와 창 크기가 반드시 같지는 않아 정확한 해법은 아님
    • 예를 들어 xterm은 창이 더 커도 그래픽 기하를 1000x1000으로 제한함
  • 두 방법이 모두 실패하면 lsix는 VT340 환경으로 가정함
    • 해상도는 800x480
    • 한 줄에 타일 6개만 들어간다고 봄
  • Sixel 표준은 사용 가능한 색상 레지스터 수를 질의하는 방법도 제공하지 않음
    • lsix는 xterm 확장을 사용함
    • 터미널이 응답하지 않으면 원래 VT340으로 가정하고 16개 색상 레지스터만 사용함

libsixel을 쓰지 않는 이유

  • libsixel은 최적화된 Sixel 그래픽 명령을 출력하는 프로젝트임
  • lsix는 libsixel 대신 Bash와 ImageMagick을 사용함
    • Bash와 ImageMagick이 널리 있어 어디서나 쉽게 동작하게 하려는 선택임
    • 스크립트를 단순하게 유지해 사용자가 쉽게 수정하고 확장할 수 있게 함
    • ImageMagick은 libsixel의 img2sixel이 사용하는 stb_image보다 더 다양한 입력 형식을 읽을 수 있음
      • 예: xpm, svg, 16-bit png, sixel 파일
    • ImageMagick은 입력을 읽고 Sixel 출력을 직접 쓸 수 있음
    • libsixel은 더 빠를 수 있지만 단순한 디렉터리 목록 표시에는 ImageMagick도 충분히 빠름

참고 자료

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 나처럼 tmux 없이는 터미널을 쓰기 어렵다면, 실험적이던 Sixel 브랜치가 약 10개월 전에 드디어 병합됐음
    이제 메인라인 tmux를 --enable-sixel로 빌드해서 tmux 안에서 lsix 같은 도구를 쓸 수 있음
    좋아하는 터미널이나 터미널 멀티플렉서가 Sixel을 지원하는지 궁금하면 "Are We Sixel Yet" 사이트를 보면 됨
    https://github.com/tmux/tmux/commit/dfbc6b1888c110cf0ade66f2...
    https://www.arewesixelyet.com

    • 몇 년 전에 Zellij로 갈아탔고, 2022년 어느 시점부터 Sixel 지원을 잘 쓰고 있음
      작업 흐름에 변화를 주고 싶다면 기본 상태에서 tmux보다 훨씬 나은 경험이라고 봄
      원래 외부 플러그인과 복잡한 설정 스크립트로 추가했을 기능들이 기본으로 들어 있고, 안정성과 성능도 훨씬 좋았음
      https://zellij.dev/
    • tmux의 용도를 잘 이해하지 못하겠음
      왜 작업 흐름에 필수 도구가 되는지, 내 작업에도 왜 필수가 될 수 있는지 설명해 줄 수 있나?
    • 그런데 왜 필요한가? 픽셀 그래픽을 굳이 텍스트 기반 저해상도 격자에 밀어 넣을 이유가 있나? 그냥 픽셀 그래픽을 쓰면 되지 않나?
    • 오래전부터 tmux를 써 왔고 그 전에는 screen을 썼지만, Sixel이 왜 큰 차이를 만드는지는 잘 모르겠음
      현재의 타일링 방식에 비해 tmux에 스택형 창 관리자를 들여오는 정도의 변화인가? 아니면 그냥 터미널 그래픽이 좋아지는 건가? 내가 완전히 잘못 이해한 건가?
      단순히 그래픽이 좋아지는 것이라면 왜 tmux가 지원해야 하는지 잘 모르겠고, Gnome Terminal 같은 터미널 에뮬레이터 쪽이 중요할 것 같음. 둘 다 필요할 수도 있지만 tmux는 그냥 통과시켜 주면 된다고 생각했음
    • brew로 tmux를 설치하면 Sixel이 활성화되는지 혹시 아나?

  • 이 저장소에서 가장 마음에 드는 기능은 README.md.d 디렉터리임
    꽤 좋은 아이디어이고, 굳이 .md는 빼도 될 것 같음

    • 진짜 강한 한 수는 README 파일 안에 이미지를 그대로 Sixel로 임베드하는 것임
      그러면 cat README만 해도 이미지가 그대로 보일 수 있음

  • "\e[c"를 써서 Sixel 지원 여부를 자동 감지함
    https://github.com/hackerb9/lsix/blob/3a431793a747df3f934051...
    "\e[c"는 "send device attributes"임
    https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h3-F...

  • 아이디어는 멋진데 PuTTY/KiTTY에서는 동작하지 않음
    $ lsix를 실행하면 터미널이 Sixel 그래픽 지원을 보고하지 않는다는 오류가 나고, xterm -ti vt340 같은 Sixel 지원 터미널을 쓰거나 터미널 제작자에게 지원을 요청하라고 함
    단일 이미지는 convert foo.jpg -geometry 800x480 sixel:-로 테스트할 수 있고, 실제로 지원하는 터미널이라면 http://github.com/hackerb9/lsix/issues 에 버그를 보고하라고 안내함
    장치 속성 코드는 ^[[?6c라고 표시됨
    아쉽다. 꽤 근사했을 텐데. Sixel을 지원하는 오픈소스 Windows 터미널이 있나? 대부분 Cygwin이나 WSL 쪽만 보이고, 순수 Windows용은 잘 안 보임

    • 최근 wezterm을 쓰기 시작했는데 꽤 마음에 듦
      크로스 플랫폼이고 Sixel 그래픽을 지원함
      https://github.com/wez/wezterm
    • Mintty는 Sixel을 지원하는 훌륭한 Windows 터미널임

  • 비슷한 계열로 timg도 있음: https://github.com/hzeller/timg

  • MacOS용 iTerm2에는 비슷한 기능이 내장돼 있고, 서버 쪽 부담은 더 적음
    서버에서 많은 이미지 라이브러리로 이미지를 Sixel로 렌더링하는 대신, 전체 이미지를 base64로 인코딩해서 클라이언트로 보내고 클라이언트가 이미지 형식을 판단해 터미널에 로컬로 렌더링함
    https://iterm2.com/documentation-images.html

    • konsole도 같은 프로토콜을 구현했음
      Linux에서 수정하지 않은 imgcat 스크립트를 그대로 쓰고 있음
      ImageMagick으로 변환하는 것보다 당연히 훨씬 빠르지만, 일단 lsix도 bin 디렉터리에 추가해 둠

  • 신뢰할 수 없는 디렉터리에서 실행할 때는 조심해야 함
    특히 PDF처럼 이미지를 파싱하는 것들은 다른 도구와 마찬가지로 위험할 수 있고, ImageMagick을 쓸 때는 더 주의가 필요함

    • 신뢰할 수 없는 이미지를 파싱하는 것이 본질적으로 문제가 되나?
      신뢰할 수 없는 다운로드 폴더를 Gnome Files로 열었을 때 내부 이미지들을 표시하고 따라서 파싱한다면, 신경 써야 할 보안 이슈인가?
      PDF 안의 JavaScript 같은 것은 문제가 될 수 있다고 생각했지만, 단순 미리보기까지 위험하다고는 생각하지 않았음

  • 사용하는 터미널이 Sixel 그래픽을 지원해야 함

    • Sixel을 지원하지 않는 터미널용 그래픽 라이브러리를 만들었음
      https://github.com/dheera/python-termgraphics
      이 라이브러리를 수정해서 대체 경로로 지원하게 만들면 흥미로울 수 있음
    • xterm은 Sixel을 지원하니, TERM=xterm256-color 같은 값을 설정하는 건 전부 호환되겠지… 맞지? 기침 gnome-terminal 기침
    • mlterm은 동작함

  • fzf는 0.44.0부터 미리보기 창에서 실험적 Sixel 이미지 지원을 제공함
    Windows에서는 사용할 수 없음
    https://github.com/junegunn/fzf/releases/tag/0.44.0
    fzf --preview='fzf-preview.sh {}'

    • 대안으로 fzf --preview 'convert {} -geometry 800x480 sixel:-'를 쓸 수 있음
      이것도 ImageMagick 설치가 필요함
답변달기