Twitter 이미지 인코딩 문제 [닫힘]
사진이 1000 단어의 가치가 있다면 140 자에 해당하는 사진은 얼마나 될까요?
참고 : 그게 다야! 바운티 마감일이 다가 오고 있습니다. 힘든 심의 끝에 Boojum의 항목이 Sam Hocevar의 . 글을 쓸 기회가 생기면 더 자세한 메모를 게시하겠습니다. 물론 모든 사람은 계속해서 솔루션을 제출하고 사람들이 투표 할 수있는 솔루션을 개선 할 수 있어야합니다. 응모 해주신 모든 분들께 감사드립니다. 나는 그들 모두를 즐겼다. 뛰는 것이 정말 즐거웠고, 참가자와 관중 모두에게 즐거웠기를 바랍니다.
나는 우연히 이 흥미로운 게시물 트위터 코멘트로 압축 이미지에 노력에 대해, 그 스레드 (그리고 사람들의 많은 레딧에 스레드는 ) 당신이 그것을 할 수있는 다른 방법에 대한 제안을했다. 그래서 저는 그것이 좋은 코딩 도전이 될 것이라고 생각합니다. 사람들이 그들의 입에 돈을 두도록하고, 인코딩에 대한 그들의 아이디어가 당신이 이용할 수있는 제한된 공간에서 어떻게 더 자세한 정보로 이어질 수 있는지 보여줍니다.
이미지를 140 자 Twitter 메시지로 인코딩하고 다시 이미지로 디코딩하는 범용 시스템을 생각해 보도록하겠습니다. 유니 코드 문자를 사용할 수 있으므로 문자 당 8 비트 이상을 얻을 수 있습니다. 그러나 유니 코드 문자를 허용하더라도 이미지를 매우 작은 공간으로 압축해야합니다. 이것은 확실히 손실 압축이 될 것이므로 각 결과가 얼마나 좋은지에 대한 주관적인 판단이 필요합니다.
다음은 원저자 인 Quasimondo 가 그의 인코딩에서 얻은 결과입니다 (이미지는 Creative Commons Attribution-Noncommercial license 하에 사용이 허가되었습니다 ).
더 잘할 수 있습니까?
규칙
- 프로그램에는 인코딩 및 디코딩의 두 가지 모드가 있어야합니다 .
- 인코딩 할 때 :
- 프로그램 은 사용자가 선택한 합리적인 래스터 그래픽 형식의 그래픽을 입력으로 가져와야 합니다. ImageMagick이 지원하는 모든 래스터 형식이 합리적 이라고 생각합니다 .
- 프로그램은 140 개 이하의 유니 코드 코드 포인트로 표현할 수있는 메시지를 출력해야합니다. 범위 (140) 코드 포인트
U+0000-U+10FFFF제외한 비 문자 (U+FFFE,U+FFFF,U+NFFFE,U+NFFFF여기서 N 인1-10진수 및 범위U+FDD0-U+FDEF) 및 대리 코드 포인트 (U+D800-U+DFFF). 선택한 합리적인 인코딩으로 출력 될 수 있습니다. GNU에서iconv지원하는 모든 인코딩 은 합리적인 것으로 간주되며 플랫폼 기본 인코딩 또는 로케일 인코딩이 좋은 선택 일 것입니다. 자세한 내용 은 아래의 유니 코드 노트 를 참조하십시오.
- 디코딩 할 때 :
- 프로그램은 인코딩 모드 의 출력을 입력으로 가져와야 합니다.
- 프로그램은 위에 정의 된대로 선택한 합리적인 형식으로 이미지를 출력해야하지만 출력 벡터 형식도 괜찮습니다.
- 이미지 출력은 입력 이미지의 근사치 여야합니다. 입력 이미지에 가까울수록 좋습니다.
- 디코딩 프로세스는 위에 지정된 출력 이외의 인코딩 프로세스의 다른 출력에 액세스 할 수 없습니다. 즉, 이미지를 어딘가에 업로드하고 디코딩 프로세스를 다운로드 할 URL을 출력 할 수 없습니다.
사용자 인터페이스의 일관성을 위해 프로그램은 다음과 같이 작동해야합니다.
- 프로그램은 적절한 인터프리터가있는 플랫폼에서 실행 가능하도록 설정할 수있는 스크립트이거나 실행 파일로 컴파일 할 수있는 프로그램이어야합니다.
- 프로그램은
encode또는decode모드를 설정하기 위해 첫 번째 인수로 취해야 합니다. 프로그램은 다음 방법 중 하나 이상으로 입력해야합니다 (파일 이름을 사용하는 방법을 구현하는 경우 파일 이름이 누락 된 경우 stdin 및 stdout에서 읽고 쓸 수도 있습니다).
표준 입력에서 입력을 받아 표준 출력으로 출력합니다.
my-program encode <input.png >output.txt my-program decode <output.txt >output.png두 번째 인수에 이름이 지정된 파일에서 입력을 받고 세 번째 인수에 이름이 지정된 파일에 출력을 생성합니다.
my-program encode input.png output.txt my-program decode output.txt output.png
- 솔루션에 대해서는 다음을 게시하십시오.
- 코드 전체 및 / 또는 다른 곳에서 호스팅되는 링크 (매우 길거나 컴파일하는 데 많은 파일이 필요한 경우).
- 코드에서 즉시 명확하지 않거나 코드가 길고 사람들이 요약에 관심이있는 경우 작동 방식에 대한 설명.
- 원본 이미지, 압축 할 텍스트 및 디코딩 된 이미지가 포함 된 예제 이미지입니다.
- 다른 사람이 가지고있는 아이디어를 기반으로하고 있다면 그 아이디어를 귀속 시키십시오. 다른 사람의 아이디어를 구체화하는 것은 괜찮지 만, 당신 은 그들을 귀속시켜야합니다.
지침
다음은 기본적으로 위반 될 수있는 규칙, 제안 또는 채점 기준입니다.
- 미학이 중요합니다. 저는 다음을 기준으로 다른 사람들이 판단 할 것을 제안합니다.
- 출력 이미지가 얼마나 좋아 보이는지, 원본 이미지와 얼마나 유사한 지.
- 텍스트가 얼마나 멋진 지. 당신이 정말 영리한 압축 체계를 가지고 있다면 완전히 임의의 구 블디 구 크는 괜찮습니다.하지만 저는 또한 이미지를 다국어 시로 바꾸는 답을보고 싶습니다. 원래 솔루션의 작성자는 한자 만 사용하기로 결정했습니다. 그게 더 멋져 보이기 때문입니다.
- 흥미로운 코드와 영리한 알고리즘은 항상 좋습니다. 나는 짧고, 요점은 명확하고, 명확한 코드를 좋아하지만, 정말 영리한 복잡한 알고리즘은 좋은 결과를 생성하는 한 괜찮습니다.
- 속도도 중요하지만 작업이 이미지를 얼마나 잘 압축하는지만큼 중요하지는 않습니다. 나는 며칠 동안 유전 알고리즘을 실행하는 것보다 10 분의 1 초 만에 이미지를 변환 할 수있는 프로그램을 갖고 싶다.
- 품질면에서 합리적으로 비교 가능한 한 긴 솔루션보다 짧은 솔루션을 선호합니다. 간결함은 미덕입니다.
- 프로그램은 Mac OS X, Linux 또는 Windows에서 자유롭게 구현할 수있는 언어로 구현해야합니다. 프로그램을 실행하고 싶지만 MATLAB 등에서 만 실행되는 훌륭한 솔루션이 있다면 괜찮습니다.
- 프로그램은 가능한 한 일반적이어야합니다. 일부는 다른 이미지보다 더 나은 결과를 생성 할 수 있지만 가능한 한 많은 다른 이미지에서 작동해야합니다. 특히:
- 일치하고 참조를 작성한 다음 디코딩시 일치하는 이미지를 생성하는 프로그램에 몇 개의 이미지를 내장하는 것은 상당히 절름발이이며 몇 개의 이미지 만 포함합니다.
- 단순하고 평평한 기하학적 모양의 이미지를 가져 와서 벡터 프리미티브로 분해 할 수있는 프로그램은 꽤 멋지지만 특정 복잡성을 초과하는 이미지에서 실패하면 일반적이지 않을 것입니다.
- 특정 고정 종횡비의 이미지 만 찍을 수 있지만 잘 작동하는 프로그램도 괜찮지 만 이상적이지는 않습니다.
- 흑백 이미지는 컬러 이미지보다 작은 공간에 더 많은 정보를 얻을 수 있습니다. 다른 한편으로는 적용 가능한 이미지 유형을 제한 할 수 있습니다. 얼굴은 흑백으로 잘 나오지만 추상적 인 디자인은 잘 어울리지 않을 수 있습니다.
- 출력 이미지가 입력보다 작 으면서 거의 같은 비율이면 완벽합니다. 원본과 비교하기 위해 이미지를 확대해야한다면 괜찮습니다. 중요한 것은 그것이 어떻게 보이는지입니다.
- 귀하의 프로그램은 실제로 트위터를 통해 손상없이 나올 수있는 출력을 생성해야합니다. 지원되는 정확한 문자 집합에 대한 문서를 찾을 수 없기 때문에 이것은 규칙 이라기보다는 지침 일 뿐이지 만 제어 문자, 펑키 한 보이지 않는 조합 문자, 개인 사용 문자 등은 피해야합니다.
채점 루 브릭
내가 받아 들인 솔루션을 선택할 때 솔루션의 순위를 매기는 방법에 대한 일반적인 가이드로서, 아마도 25 점 척도로 솔루션을 평가할 것이라고 가정 해 보겠습니다 (매우 거칠기 때문에 직접 점수를 매기지는 않을 것입니다. 이것은 기본 지침으로) :
- 인코딩 체계가 광범위한 입력 이미지를 얼마나 잘 재현하는지 15 점 . 이것은 주관적이고 미적인 판단입니다.
- 0은 전혀 작동하지 않음을 의미하며 매번 동일한 이미지를 반환합니다.
- 5는 디코딩 된 버전이보기 흉하고 더 복잡한 이미지에서는 전혀 작동하지 않을 수 있지만 몇 개의 이미지를 인코딩 할 수 있음을 의미합니다.
- 10은 광범위한 이미지에서 작동하며 때때로 구별 할 수있는 쾌적한 이미지를 생성 함을 의미합니다.
- 15는 일부 이미지의 완벽한 복제본을 생성하고 더 크고 복잡한 이미지의 경우에도 알아볼 수있는 무언가를 제공함을 의미합니다. 또는 잘 알아볼 수있는 이미지를 만들지는 않지만 원본에서 분명하게 파생 된 아름다운 이미지를 생성합니다.
- 유니 코드 문자 집합의 영리한 사용을위한
3 점
- 허용 된 전체 문자 집합을 단순히 사용하는 경우 0 점
- 트위터를 통한 전송 또는 다양한 상황에서 안전한 제한된 문자 세트 사용시 1 점
- 한글 표의 문자 만 또는 오른쪽에서 왼쪽 문자 만 등 주제별 문자 하위 집합을 사용하기위한 2 점
- 읽을 수있는 텍스트를 생성하거나 문제의 이미지와 같은 문자를 사용하는 것과 같이 정말 깔끔한 작업을 수행하는 3 가지 포인트
- 영리한 알고리즘 접근 방식과 코드 스타일을위한
3 가지 포인트
- 이미지를 축소하고 픽셀 당 1 비트로 처리하고 base64로 인코딩하기위한 1000 줄의 코드에 대해 0 점
- 표준 인코딩 기술을 사용하고 잘 작성되고 간략하게 작성된 항목에 대해 1 점
- 비교적 새로운 인코딩 기술을 도입하거나 놀라 울 정도로 짧고 깔끔한 항목에 대해 2 점
- 실제로 좋은 결과를 생성하는 하나의 라이너 또는 그래픽 인코딩의 새로운 지평을 여는 것에 대해 3 점 (새로운 지평을 개척하기위한 점수가 낮은 것 같으면이 제품이 미학적 측면에서 높은 점수를받을 수 있음을 기억하십시오. 게다가)
- 속도 2 점 . 다른 모든 것은 동일하고 빠를수록 좋지만 위의 기준은 모두 속도보다 중요합니다.
- 무료 (오픈 소스) 소프트웨어에서 실행하는 경우 1 점. 무료 소프트웨어를 선호하기 때문입니다 (C #은 Mono에서 실행되는 한 여전히이 점에 적합하며, 마찬가지로 GNU Octave에서 실행되는 경우 MATLAB 코드도 적합합니다)
- 실제로 모든 규칙을 준수하면 1 점 . 이 규칙은 조금 크고 복잡해 졌기 때문에 작은 세부 사항 하나가 잘못되는 다른 좋은 대답을 받아 들일 것입니다. 그러나 실제로 모든 규칙을 따르는 모든 솔루션에 추가 요점을 줄 것입니다.
참조 이미지
일부 사람들은 일부 참조 이미지를 요청했습니다. 다음은 시도해 볼 수있는 몇 가지 참조 이미지입니다. 더 작은 버전이 여기에 포함되어 있으며 필요한 경우 모두 더 큰 이미지 버전으로 연결됩니다.
상
나는 제공하고 500 담당자 현상금 솔루션에 대한 (플러스 50 그 StackOverflow의 킥을) 그 I 위의 기준에 따라, 최고의있다. 물론 다른 모든 사람들이 여기에서 가장 좋아하는 솔루션에 투표하도록 권장합니다.
마감일에 대한 참고 사항
이 콘테스트는 5 월 30 일 토요일 오후 6 시경 현상금이 소진 될 때까지 진행됩니다. 종료 될 정확한 시간은 말할 수 없습니다. 오후 5 시부 터 7 시까 지입니다. 나는 오후 2 시까 지 제출 된 모든 출품작을 검토 할 것을 보장하고 오후 4 시까 지 제출 된 모든 출품작을 확인하기 위해 최선을 다할 것입니다. 그 이후에 해결책이 제출되면 결정을 내리기 전에 공정한 검토를 할 기회가 없을 수 있습니다. 또한 빨리 제출할수록 투표를 통해 최상의 솔루션을 선택하는 데 도움이 될 수 있으므로 마감일에 늦게 제출하는 것보다 일찍 제출해주세요.
유니 코드 노트
또한 정확히 어떤 유니 코드 문자가 허용되는지에 대해 약간의 혼동이있었습니다. 가능한 유니 코드 코드 포인트의 범위는 U+0000~ U+10FFFF입니다. 공개 된 데이터 교환에서 유니 코드 문자로 사용하기에 결코 유효하지 않은 코드 포인트가 있습니다. 이들은 비 문자 및 대리 코드 포인트 입니다. Noncharacters가 정의되어 Unidode 표준 섹션 5.1.0 16.7 값으로서 U+FFFE, U+FFFF, U+NFFFE , U+NFFFF 여기서 N 인 1- 10진수 및 범위 U+FDD0-U+FDEF. 이러한 값은 애플리케이션 별 내부 사용에 사용하기위한 것이며, 준수 애플리케이션은 처리 된 텍스트에서 이러한 문자를 제거 할 수 있습니다. Unicode Standard 5.1.0 섹션 3.8 에서 U+D800– 로 정의 된 대리 코드 포인트 U+DFFF는 기본 다국어 평면을 넘어서 UTF-16으로 문자를 인코딩하는 데 사용됩니다. 따라서 이러한 코드 포인트를 UTF-16 인코딩으로 직접 표현하는 것은 불가능하며 다른 인코딩으로 인코딩하는 것은 유효하지 않습니다. 따라서이 콘테스트의 목적을 위해 위에서 정의한 모든 비 문자 및 대리 쌍을 제외하고 U+0000– 범위에서 140 개 이하의 유니 코드 코드 포인트 시퀀스로 이미지를 인코딩하는 모든 프로그램을 허용합니다 U+10FFFF.
나는 것이다 선호 에만 할당 된 문자 및 할당 된 문자의 영리한 하위 집합을 사용하거나 그들이 사용하는 문자 집합으로 뭔가 재미있는을 더 나은 사람을 사용하는 솔루션을. 할당 된 문자 목록은 유니 코드 문자 데이터베이스를 참조하십시오 . 일부 문자는 직접 나열되지만 일부는 범위의 시작과 끝으로 만 나열됩니다. 또한 대리 코드 포인트는 데이터베이스에 나열되어 있지만 위에서 언급 한대로 금지되어 있습니다. 텍스트를 더 흥미롭게 만들기 위해 문자의 특정 속성을 활용하려면 명명 된 코드 블록 목록 및 다양한 문자 속성 과 같은 다양한 문자 정보 데이터베이스를 사용할 수 있습니다..
Twitter는 지원하는 정확한 문자 집합을 지정하지 않기 때문에 특정 문자가 추가로 계산되거나 특정 문자가 제거되기 때문에 실제로 Twitter에서 작동하지 않는 솔루션에 대해 관대합니다. 모든 인코딩 된 출력이 Twitter 또는 identi.ca 와 같은 다른 마이크로 블로깅 서비스를 통해 손상 없이 전송 될 수 있어야하지만 필수는 아닙니다 . Twitter 엔티티가 <,> 및 &를 인코딩하여 각각 4, 4 및 5 문자로 계산한다는 일부 문서를 보았지만 직접 테스트하지 않았으며 JavaScript 문자 카운터가 보이지 않습니다. 그렇게 계산합니다.
팁 및 링크
- 규칙에서 유효한 유니 코드 문자의 정의는 약간 복잡합니다. CJK 통합 표의 문자 (U + 4E00–U + 9FCF)와 같은 단일 문자 블록을 선택하는 것이 더 쉬울 수 있습니다.
- ImageMagick 또는 Python Imaging Library 와 같은 기존 이미지 라이브러리를 이미지 조작에 사용할 수 있습니다.
- 유니 코드 문자 집합과 다양한 인코딩을 이해하는 데 도움이 필요하면 이 빠른 가이드 또는 Linux 및 Unix의 UTF-8에 대한 자세한 FAQ를 참조하십시오 .
- 솔루션을 더 일찍받을수록 나 (및 투표하는 다른 사람들)가 더 많은 시간을보아야합니다. 솔루션을 개선하면 편집 할 수 있습니다. 마지막으로 솔루션을 살펴볼 때 가장 최근 버전을 기준으로 현상금을 지급하겠습니다.
- 쉽게 이미지 형식을 구문 분석하고 작성하고 싶다면 (기존 형식 만 사용하고 싶지는 않음) PPM 형식을 사용하는 것이 좋습니다 . 작업하기 매우 쉬운 텍스트 기반 형식이며 ImageMagick 을 사용 하여 변환 할 수 있습니다 .
좋습니다 . 여기에 nanocrunch.cpp 및 CMakeLists.txt 파일이 있습니다. 대부분의 이미지 처리를 위해 Magick ++ ImageMagick API에 의존합니다 . 또한 문자열 인코딩을위한 bignum 산술을위한 GMP 라이브러리 가 필요합니다 .
나는 몇 가지 독특한 변형을 통해 프랙탈 이미지 압축을 기반으로 솔루션을 구축했습니다. 기본 아이디어는 이미지를 가져 와서 사본을 50 %로 축소하고 원본 이미지에서 겹치지 않는 블록과 유사한 다양한 방향의 조각을 찾는 것입니다. 이 검색에는 매우 무차별 대입 접근 방식이 필요하지만 수정 사항을 도입하기가 더 쉽습니다.
첫 번째 수정은 90도 회전과 뒤집기를 보는 대신 내 프로그램도 45도 방향을 고려한다는 것입니다. 블록 당 하나의 비트이지만 이미지 품질을 크게 향상시킵니다.
다른 하나는 각 블록의 각 색상 구성 요소에 대한 대비 / 밝기 조정을 저장하는 것이 너무 비싸다는 것입니다. 대신, 나는 단순히 약간의 비율로 혼합되는 고도로 양자화 된 색상 (팔레트에는 4 * 4 * 4 = 64 색상 만 있음)을 저장합니다. 수학적으로 이것은 각 색상에 대한 가변 밝기 및 일정한 대비 조정과 동일합니다. 불행히도 색상을 뒤집는 데 부정적인 대비가 없음을 의미합니다.
각 블록의 위치, 방향 및 색상이 계산되면이를 UTF-8 문자열로 인코딩합니다. 첫째, 블록 테이블의 데이터와 이미지 크기를 나타내는 매우 큰 bignum을 생성합니다. 이에 대한 접근 방식은 Sam Hocevar의 솔루션과 유사합니다. 이는 위치에 따라 기수가 달라지는 일종의 큰 수입니다.
그런 다음 사용 가능한 문자 집합의 크기가 무엇이든 기본으로 변환합니다. 기본적으로 할당 된 유니 코드 문자 집합에서보다 작음,보다 큼, 앰퍼샌드, 제어, 결합, 서로 게이트 및 개인 문자를 뺀 값을 모두 사용합니다. 예쁘지는 않지만 작동합니다. 또한 기본 테이블을 주석 처리하고 인쇄 가능한 7 비트 ASCII (<,> 및 & 문자 제외) 또는 CJK 통합 표의 문자를 대신 선택할 수도 있습니다. 문자 코드를 사용할 수있는 테이블은 유효하지 않은 문자와 유효한 문자를 번갈아 실행하여 인코딩 된 실행 길이로 저장됩니다.
어쨌든, 여기에 몇 가지 이미지와 시간 (예전 3.0GHz P4에서 측정)이 있으며 위에서 설명한 전체 할당 된 유니 코드 세트에서 140 자로 압축되었습니다. 전반적으로 나는 그들이 어떻게 밝혀 졌는지에 대해 상당히 만족합니다. 이에 대해 작업 할 시간이 더 있다면 압축 해제 된 이미지의 고르지 않은 부분을 줄이려고 할 것입니다. 그럼에도 불구하고 결과는 극한 압축률에 대해 꽤 좋은 것 같습니다. 압축 해제 된 이미지는 약간 인상적이지만 비트가 원본과 어떻게 일치하는지 비교적 쉽게 알 수 있습니다.
스택 오버플로 로고 (인코딩 8.6 초, 디코딩 7.9 초, 485 바이트) :
http://i44.tinypic.com/2w7lok1.png
Lena (인코딩 32.8 초, 디코딩 13.0 초, 477 바이트) :
http://i42.tinypic.com/2rr49wg.png http://i40.tinypic.com/2rhxxyu.png
모나리자 (인코딩 43.2 초, 디코딩 14.5 초, 490 바이트) :
http://i41.tinypic.com/ekgwp3.png http://i43.tinypic.com/ngsxep.png
편집 : CJK 통합 문자
Sam은 CJK에서 이것을 사용하는 것에 대한 의견에서 물었습니다. 다음은 CJK Unified 문자 집합에서 139 자로 압축 된 Mona Lisa 버전입니다.
http://i43.tinypic.com/2yxgdfk.png咏璘驞凄脒鵚据蛥鸂拗朐朖辿韩瀦魷歪痫栘璯緍脲蕜抱揎頻蓼債鑡嗞靊寞柮嚛嚵籥聚隤慛絖銓馿渫櫰矍昀鰛掾撄粂敽牙稉擎蔍螎葙峬覧絀蹔抆惫冧笻哜搀澐芯譶辍澮垝黟偞媄童竽梀韠镰猳閺狌而羶喙伆杇婣唆鐤諽鷍鴞駫搶毤埙誖萜愿旖鞰萗勹鈱哳垬濅鬒秀瞛洆认気狋異闥籴珵仾氙熜謋繴茴晋髭杍嚖熥勳縿餅珝爸擸 萿
이 작업을 위해 사용한 프로그램 상단의 튜닝 매개 변수는 19, 19, 4, 4, 3, 10, 11, 1000, 1000이었습니다. 또한 number_assigned 및 코드의 첫 번째 정의를 주석 처리하고 주석을 제거했습니다. CJK 통합 문자 세트를 선택하기위한 마지막 정의.
이미지 파일 및 Python 소스 (버전 1 및 2)
버전 1 첫 번째 시도입니다. 내가가는대로 업데이트하겠습니다.
나는 거의 무손실로 300 자까지 SO 로고를 얻었습니다. 내 기술은 SVG 벡터 아트로의 변환을 사용하므로 라인 아트에서 가장 잘 작동합니다. 실제로는 SVG 압축기이지만 여전히 원본 아트가 벡터화 단계를 거쳐야합니다.
첫 번째 시도 에서 PNG 트레이스에 온라인 서비스 를 사용 했지만 potrace (오픈 소스)를 포함하여이 부분을 처리 할 수있는 무료 및 비 무료 도구가 많이 있습니다 .
결과는 다음과 같습니다.
원본 SO 로고 http://www.warriorhut.org/graphics/svg_to_unicode/so-logo.png 원본 디코딩 된 SO 로고 http://www.warriorhut.org/graphics/svg_to_unicode/so-logo-decoded.png 인코딩 후 디코딩
캐릭터 : 300
시간 : 측정되지는 않았지만 거의 즉각적 (벡터화 / 래스터 화 단계 제외)
다음 단계는 유니 코드 문자 당 4 개의 기호 (SVG 경로 지점 및 명령)를 포함하는 것입니다. 현재 내 파이썬 빌드에는 문자 당 해상도를 제한하는 광범위한 문자 지원 UCS4가 없습니다. 또한 최대 범위를 유니 코드 예약 범위 0xD800의 하단으로 제한했지만 허용 된 문자 목록과이를 방지하기위한 필터를 작성하면 이론적으로 필요한 문자 수를 70-100까지 낮출 수 있습니다. 위의 로고.
현재이 방법의 한계는 출력 크기가 고정되어 있지 않다는 것입니다. 벡터화 후 벡터 노드 / 포인트의 수에 따라 다릅니다. 이 제한을 자동화하려면 이미지를 픽셀 화 (벡터의 주요 이점 제거)하거나 원하는 노드 수에 도달 할 때까지 (현재 Inkscape에서 수동으로 수행중인) 단순화 단계를 통해 경로를 반복 실행해야합니다.
버전 2
업데이트 : v2는 이제 경쟁 할 자격이 있습니다. 변경 사항 :
- 명령 줄 제어 입력 / 출력 및 디버깅
- 정규식 대신 SVG를 처리하기 위해 XML 파서 (lxml)를 사용합니다.
- 유니 코드 심볼 당 2 개의 경로 세그먼트를 압축합니다.
- 문서화 및 정리
- style = "fill : color"및 fill = "color"지원
- 단일 문자로 압축 된 문서 너비 / 높이
- 단일 문자로 압축 된 경로 색상
- 색상 압축은 색상 당 4 비트의 색상 데이터를 버리고 16 진수 변환을 통해 문자로 압축함으로써 달성됩니다.
캐릭터 : 133
시간 : 몇 초
v2 디코딩 http://www.warriorhut.org/graphics/svg_to_unicode/so-logo-decoded-v2.png 인코딩 및 디코딩 후 (버전 2)
보시다시피 이번에는 약간의 유물이 있습니다. 그것은 방법의 제한이 아니라 내 변환 어딘가에서 실수입니다. 아티팩트는 포인트가 0.0-127.0 범위를 벗어나고 제한하려는 시도가 혼합 성공했을 때 발생합니다. 해결책은 단순히 이미지를 축소하는 것이지만 아트 보드 또는 그룹 매트릭스가 아닌 실제 포인트의 크기를 조정하는 데 문제가있어서 너무 피곤해서 신경 쓸 수 없습니다. 요컨대, 포인트가 지원되는 범위에 있으면 일반적으로 작동합니다.
중간의 꼬임은 연결된 핸들의 반대쪽으로 이동하는 핸들 때문이라고 생각합니다. 기본적으로 포인트는 애초에 너무 가깝습니다. 압축하기 전에 소스 이미지에 단순화 필터를 실행하면이 문제를 해결하고 불필요한 문자를 제거해야합니다.
업데이트 :이 방법은 간단한 개체에 적합하므로 복잡한 경로를 단순화하고 노이즈를 줄이는 방법이 필요했습니다. 이 작업에는 Inkscape 를 사용했습니다 . Inkscape를 사용하여 불필요한 경로를 정리하는 데 행운이 있었지만 자동화를 시도 할 시간이 없었습니다. 경로 수를 줄이기 위해 Inkscape 'Simplify'기능을 사용하여 샘플 svg를 만들었습니다.
단순화는 정상적으로 작동하지만 이렇게 많은 경로로 인해 느려질 수 있습니다.
autotrace 예 http://www.warriorhut.org/graphics/svg_to_unicode/autotrace_16_color_manual_reduction.png 코넬 상자 http://www.warriorhut.com/graphics/svg_to_unicode/cornell_box_simplified.png lena http://www.warriorhut.com/graphics /svg_to_unicode/lena_std_washed_autotrace.png
추적 된 축소판 http://www.warriorhut.org/graphics/svg_to_unicode/competition_thumbnails_autotrace.png
다음은 초 저해상도 샷입니다. 일부 영리한 경로 압축이 필요할 수도 있지만 이는 140 자 제한에 더 가깝습니다.
정리 http://www.warriorhut.org/graphics/svg_to_unicode/competition_thumbnails_groomed.png 단순화 및 얼룩 제거.
삼각 측량 http://www.warriorhut.org/graphics/svg_to_unicode/competition_thumbnails_triangulated.png 단순화, 얼룩 제거 및 삼각 측량.
autotrace --output-format svg --output-file cornell_box.svg --despeckle-level 20 --color-count 64 cornell_box.png
위 : autotrace를 사용하는 단순화 된 경로 .
불행히도 내 파서는 autotrace 출력을 처리하지 않으므로 포인트가 어떻게 사용되는지 또는 얼마나 단순화해야하는지 알 수 없습니다. 슬프게도 마감일 전에 작성할 시간이 거의 없습니다. 그래도 inkscape 출력보다 구문 분석이 훨씬 쉽습니다.
내 전체 솔루션은 http://caca.zoy.org/wiki/img2twit . 다음과 같은 기능이 있습니다.
- 합리적인 압축 시간 (고품질을 위해 약 1 분)
- 빠른 감압 (1 초)
- 원본 이미지 크기 유지 (종횡비뿐만 아니라)
- 괜찮은 재건 품질 (IMHO)
- 메시지 길이 및 문자 세트 (ASCII, CJK, 기호)는 런타임에 선택할 수 있습니다.
- 압축 해제시 메시지 길이 및 문자 집합이 자동 감지 됨
- 매우 효율적인 정보 패킹
http://caca.zoy.org/raw-attachment/wiki/img2twit/so-logo.png http://caca.zoy.org/raw-attachment/wiki/img2twit/twitter4.png
蜥 秓 鋖 筷 聝 诿 缰 偺 腶 漷 庯 祩 皙 靊 谪 獜 岨 幻 寤 厎 趆 脘 搇 梄 踥 桻 粿 踥 桻 粿 踥 桻 粿 踥 桻 渹 裥 欇 渹 裏 軱 渹 裏 軱 渹 裥 欇 渹玧 霫 鏓 蓕 戲 債 鼶 襋 躻 弯 袮 足 庭 侅 旍 凼 飙 驅 據 嘛 掔 倾 诗 籂 阉 嶹 婻 椿 糢 墤 渽 緛 赐 更 儅 棫 武 婩 縑 逡 荨 璙 杯 翉 珸 齸 陁 颗 鳣 憫擲 舥 攩 寉 鈶 兓 庭 璱 篂 鰀 乾 丕 耓 庁 錸 努 樀 肝 亖 弜 喆 蝞 躐 葌 熲 谎 蛪 曌 缰 嘰 曟 暙 嘍 镶 庭 璱
다음은 인코딩 프로세스에 대한 대략적인 개요입니다.
- 사용 가능한 비트 수는 원하는 메시지 길이와 사용 가능한 문자 집합에서 계산됩니다.
- 소스 이미지는 사용 가능한 비트가 허용하는 한 많은 정사각형 셀로 분할됩니다.
- 고정 된 수의 포인트 (현재 2 개)가 초기 좌표 및 색상 값과 함께 각 셀에 영향을줍니다.
- 품질 조건이 충족 될 때까지 다음이 반복됩니다.
- 무작위로 포인트가 선택됩니다
- 이 지점에서 작업이 무작위로 수행됩니다 (셀 내부로 이동, 색상 변경).
- 결과 이미지 (아래 디코딩 프로세스 참조)가 소스 이미지에 더 가까우면 작업이 유지됩니다.
- 이미지 크기와 포인트 목록은 UTF-8로 인코딩됩니다.
그리고 이것은 디코딩 프로세스입니다.
- 이미지 크기와 포인트는 UTF-8 스트림에서 읽습니다.
- 대상 이미지의 각 픽셀에 대해 :
- 자연 이웃의 목록이 계산됩니다.
- 픽셀의 최종 색상은 주변 자연 색상의 가중 평균으로 설정됩니다.
프로그램의 가장 독창적 인 부분은 비트 스트림이라고 생각합니다. 비트 정렬 값 ( stream <<= shift; stream |= value) 을 패킹하는 대신 2의 거듭 제곱 범위 ( stream *= range; stream += value)에 속하지 않는 임의의 값을 패킹합니다 . 이것은 큰 계산이 필요하고 물론 훨씬 느리지 만 20902의 주요 CJK 문자를 사용할 때 1960 대신 2009.18 비트를 제공합니다 (데이터에 3 개의 포인트를 더 넣을 수 있습니다). 그리고 ASCII를 사용하면 840 대신 917.64 비트를 제공합니다.
처음에는 정말 도움이 될지 확신하지 못했기 때문에 무거운 무기 (코너 감지, 특징 추출, 색상 양자화 ...)가 필요한 초기 이미지 계산 방법에 반대하기로 결정했습니다. 이제 수렴이 느리다는 것을 알고 (1 분은 허용되지만 그럼에도 불구하고 느림) 개선을 시도 할 수 있습니다.
메인 피팅 루프는 Direct Binary Seach 디더링 알고리즘 (더 나은 하프 톤을 얻을 때까지 픽셀이 무작위로 교체되거나 뒤집히는 알고리즘)에서 느슨하게 영감을 받았습니다. 에너지 계산은 단순한 제곱 평균 제곱근 거리이지만 먼저 원본 이미지에 대해 5x5 중앙값 필터를 수행합니다. 가우시안 블러는 인간의 눈 동작을 더 잘 나타낼 수 있지만 날카로운 모서리를 잃고 싶지 않았습니다. 또한 시뮬레이션 어닐링 또는 기타 조정하기 어려운 방법을 사용하지 않기로 결정했습니다. 공정을 보정 할 수있는 달이 없기 때문입니다. 따라서 "품질"플래그는 인코더가 종료되기 전에 각 지점에서 수행되는 반복 횟수를 나타냅니다.
http://caca.zoy.org/raw-attachment/wiki/img2twit/Mona_Lisa_scaled.jpg http://caca.zoy.org/raw-attachment/wiki/img2twit/twitter2.png
苉 憗 揣 嶕 繠 剳 腏 篮 濕 茝 霮 墧 蒆 棌 杚 蓳 縳 樟 赒 肴 飗 噹 砃 燋 任 朓 峂 釰 靂 陴 貜 犟 掝 喗 讄 荛 砙 矺 敨 鷾 瓔 亨 髎 芟 氲 簵 鸬 嫤 鉸 俇激 躙 憮 鄴 甮 槺 骳 佛 愚 猪 駪 惾 嫥 綖 珏 矯 坼 堭 颽 箽 赭 飉 訥 偁 箝 窂 蹻 熛 漧 衆 橼 愀 航 玴 毡 裋 頢 羔 恺 墎 嬔 鑹 楄 瑥 鶼 呍 蕖 抲 鸝 秓苾 绒 酯 嵞 脔 婺 污 囉 酼 俵 菛 琪 棺 则 辩 曚 鸸 職 銛 蒝 礭 鱚 蟺 稿 纡 醾 陴 忩 綥 尥 蟀 惘 鋁 污 囉 酼 俵 菛 琪
모든 이미지가 잘 압축되는 것은 아니지만 결과에 놀랐고 이미지를 250 바이트로 압축 할 수있는 다른 방법이 있는지 정말 궁금합니다.
또한 임의의 초기 상태 와 "좋은"초기 상태 에서 인코더 상태의 진화에 대한 작은 동영상도 있습니다 .
편집 : 여기에 압축 방법이 JPEG와 비교되는 방법이 있습니다. 왼쪽에는 jamoes의 536 바이트 이상의 사진이 있습니다. 오른쪽에서 Mona Lisa는 여기에 설명 된 방법을 사용하여 534 바이트로 압축했습니다 (여기에 언급 된 바이트는 데이터 바이트를 참조하므로 유니 코드 문자를 사용하여 낭비되는 비트는 무시 됨).
http://caca.zoy.org/raw-attachment/wiki/img2twit/minimona.jpg http://caca.zoy.org/raw-attachment/wiki/img2twit/minimona2.png
편집 : CJK 텍스트를 최신 버전의 이미지로 바꿨습니다.
내 소프트웨어가 지정된 작업에 대해 어떤 방식 으로든 맞춤화되지 않았기 때문에 다음은 공식 제출이 아닙니다. DLI 는 최적화 된 범용 손실 이미지 코덱으로 설명 할 수 있습니다. 이미지 압축을위한 PSNR 및 MS-SSIM 레코드 홀더이며,이 특정 작업에서 어떻게 작동하는지 보는 것이 흥미로울 것이라고 생각했습니다. 제공된 참조 Mona Lisa 이미지를 사용하고 100x150으로 축소 한 다음 DLI를 사용하여 344 바이트로 압축했습니다.
모나리자 DLI http://i40.tinypic.com/2md5q4m.png
JPEG 및 IMG2TWIT 압축 샘플과 비교하기 위해 DLI를 사용하여 이미지도 534 바이트로 압축했습니다. JPEG는 536 바이트이고 IMG2TWIT는 534 바이트입니다. 이미지는 쉽게 비교할 수 있도록 거의 동일한 크기로 확대되었습니다. JPEG는 왼쪽 이미지, IMG2TWIT는 중앙, DLI는 오른쪽 이미지입니다.
비교 http://i42.tinypic.com/302yjdg.png
DLI 이미지는 일부 얼굴 특징, 특히 유명한 미소를 보존합니다. :).
내 솔루션의 일반적인 개요는 다음과 같습니다.
- 140 utf8 문자에 맞출 수있는 최대 원시 데이터 양을 계산하는 것으로 시작합니다.
- (저는 원래 웹 사이트 가 트위터에서 메시지를 저장했다고 주장한 utf8을 가정 하고 있습니다. 이것은 utf16을 요구하는 위의 문제 설명과 다릅니다.)
- 이 utf8 faq를 사용 하여 단일 utf8 문자로 인코딩 할 수있는 최대 비트 수는 31 비트라고 계산합니다. 이를 위해 U-04000000 – U-7FFFFFFF 범위에있는 모든 문자를 사용합니다. (1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx, 31 개의 x가 있으므로 최대 31 비트까지 인코딩 할 수 있습니다.)
- 31 비트 x 140 문자는 4340 비트와 같습니다. 이 값을 8로 나누어 524.5를 얻고 542 바이트 로 내림 합니다 .
- (우리가 utf16으로 제한하면 문자 당 2 바이트 만 저장할 수 있으며 이는 280 바이트와 같습니다).
- 표준 jpg 압축을 사용하여 이미지를 압축합니다.
- 압축 된 이미지의 원시 비트를 utf-8 문자로 인코딩합니다.
- 다음 바이트에서 각 x를 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx, 이미지의 비트로 바꿉니다.
- 이 부분은 아마도 대부분의 코드를 작성해야하는 부분 일 것입니다. 현재이를 수행하는 것은 존재하지 않기 때문입니다.
나는 당신이 코드를 요구하고 있다는 것을 알고 있지만 실제로 이것을 코딩하는 데 시간을 소비하고 싶지는 않습니다. 나는 효율적인 디자인이 적어도 누군가가 이것을 코딩하도록 영감을 줄 것이라고 생각했습니다.
제가 제안한 솔루션의 주요 이점은 가능한 한 많은 기존 기술을 재사용한다는 것입니다. 좋은 압축 알고리즘을 작성하는 것은 재미 있을지 모르지만, 더 나은 알고리즘이 있다는 것이 보장되며, 아마도 고등 수학 학위를 가진 사람들이 작성한 것 같습니다.
그러나 또 다른 중요한 점은 utf16이 선호되는 인코딩으로 결정되면이 솔루션이 무너진다는 것입니다. jpeg는 280 바이트로 압축하면 실제로 작동하지 않습니다. 이 특정 문제 설명에 대해 jpg보다 더 나은 압축 알고리즘이있을 수 있습니다.
좋아, 나는 게임에 늦었지만 그럼에도 불구하고 내 프로젝트를 만들었다.
반투명 다채로운 원을 사용하여 초기 이미지를 재현하는 장난감 유전 알고리즘입니다.
풍모:
- 순수한 루아. Lua 인터프리터가 실행되는 모든 곳에서 실행됩니다.
- netpbm P3 형식 사용
- comes with a comprehensive suite of unit tests
- preserves original image size
Mis-feautres:
- slow
- at this space constraints it preserves only the basic color scheme of the initial image and a general outline of few features thereof.
Here's an example twit that represents Lena: 犭楊谷杌蒝螦界匘玏扝匮俄归晃客猘摈硰划刀萕码摃斢嘁蜁嚎耂澹簜僨砠偑婊內團揕忈義倨襠凁梡岂掂戇耔攋斘眐奡萛狂昸箆亲嬎廙栃兡塅受橯恰应戞优猫僘瑩吱賾卣朸杈腠綍蝘猕屐稱悡詬來噩压罍尕熚帤厥虤嫐虲兙罨縨炘排叁抠堃從弅慌螎熰標宑簫柢橙拃丨蜊缩昔儻舭勵癳冂囤璟彔榕兠摈侑蒖孂埮槃姠璐哠眛嫡琠枀訜苄暬厇廩焛瀻严啘刱垫仔
The code is in a Mercurial repository at bitbucket.org. Check out http://bitbucket.org/tkadlubo/circles.lua
The following is my approach to the problem and I must admit that this was quite an interesting project to work on, it is definitely outside of my normal realm of work and has given me a something new to learn about.
The basic idea behind mine is as follows:
- Down-sample the image gray-scale such that there were a total of 16 different shades
- Preform RLE on the image
- Pack the results into the UTF-16 characters
- Preform RLE on the packed results to remove any duplication of characters
It turns out that this does work, but only to a limited extent as you can see from the sample images below. In terms of output, what follows is a sample tweet, specifically for the Lena image shown in the samples.
乤乤万乐唂伂倂倁企儂2企倁3企倁2企伂8企伂3企伂5企倂倃伂倁3企儁企2伂倃5企倁3企倃4企倂企倁企伂2企伂5企倁企伂쥹皗鞹鐾륶䦽阹럆䧜椿籫릹靭욶옷뎷歩㰷歉䴗鑹㞳鞷㬼獴鏙돗鍴祳㭾뤶殞焻�乹Ꮛ靆䍼
As you can see, I did try and constrain the character set a bit; however, I ran into issues doing this when storing the image color data. Also, this encoding scheme also tends to waste a bunch of bits of data that could be used for additional image information.
In terms of run times, for small images the code is extremely fast, about 55ms for the sample images provided, but the time does increase with larger images. For the 512x512 Lena reference image the running time was 1182ms. I should note that the odds are pretty good that the code itself isn't very optimized for performance (e.g. everything is worked with as a Bitmap) so the times could go down a bit after some refactoring.
Please feel free to offer me any suggestions on what I could have done better or what might be wrong with the code. The full listing of run times and sample output can be found at the following location: http://code-zen.info/twitterimage/
Update One
I've updated the the RLE code used when compressing the tweet string to do a basic look back and if so so use that for the output. This only works for the number value pairs, but it does save a couple of characters of data. The running time is more or less the same as well as the image quality, but the tweets tend to be a bit smaller. I will update the chart on the website as I complete the testing. What follows is one of the example tweet strings, again for the small version of Lena:
乤乤万乐唂伂倂倁企儂2企倁3企倁ウ伂8企伂エ伂5企倂倃伂倁グ儁企2伂倃ガ倁ジ倃4企倂企倁企伂ツ伂ス倁企伂쥹皗鞹鐾륶䦽阹럆䧜椿籫릹靭욶옷뎷歩㰷歉䴗鑹㞳鞷㬼獴鏙돗鍴祳㭾뤶殞焻�乹Ꮛ靆䍼
Update Two
Another small update, but I modified the code to pack the color shades into groups of three as opposed to four, this uses some more space, but unless I'm missing something it should mean that "odd" characters no longer appear where the color data is. Also, I updated the compression a bit more so it can now act upon the entire string as opposed to just the color count block. I'm still testing the run times, but they appear to be nominally improved; however, the image quality is still the same. What follows is the newest version of the Lena tweet:
2乤万乐唂伂倂倁企儂2企倁3企倁ウ伂8企伂エ伂5企倂倃伂倁グ儁企2伂倃ガ倁ジ倃4企倂企倁企伂ツ伂ス倁企伂坹坼坶坻刾啩容力吹婩媷劝圿咶坼妛啭奩嗆婣冷咛啫凃奉佶坍均喳女媗决兴宗喓夽兴唹屹冷圶埫奫唓坤喝奎似商嗉乃
StackOverflow Logo http://code-zen.info/twitterimage/images/stackoverflow-logo.bmp Cornell Box http://code-zen.info/twitterimage/images/cornell-box.bmp Lena http://code-zen.info/twitterimage/images/lena.bmp Mona Lisa http://code-zen.info/twitterimage/images/mona-lisa.bmp
This genetic algorithm that Roger Alsing wrote has a good compression ratio, at the expense of long compression times. The resulting vector of vertices could be further compressed using a lossy or lossless algorithm.
http://rogeralsing.com/2008/12/07/genetic-programming-evolution-of-mona-lisa/
Would be an interesting program to implement, but I'll give it a miss.
In the original challenge the size limit is defined as what Twitter still allows you to send if you paste your text in their textbox and press "update". As some people correctly noticed this is different from what you could send as a SMS text message from your mobile.
What is not explictily mentioned (but what my personal rule was) is that you should be able to select the tweeted message in your browser, copy it to the clipboard and paste it into a text input field of your decoder so it can display it. Of course you are also free to save the message as a text file and read it back in or write a tool which accesses the Twitter API and filters out any message that looks like an image code (special markers anyone? wink wink). But the rule is that the message has to have gone through Twitter before you are allowed to decode it.
Good luck with the 350 bytes - I doubt that you will be able to make use of them.
Posting a Monochrome or Greyscale image should improve the size of the image that can be encoded into that space since you don't care about colour.
Possibly augmenting the challenge to upload three images which when recombined give you a full colour image while still maintaining a monochrome version in each separate image.
Add some compression to the above and It could start looking viable...
Nice!!! Now you guys have piqued my interest. No work will be done for the rest of the day...
Regarding the encoding/decoding part of this challenge. base16b.org is my attempt to specify a standard method for safely and efficiently encoding binary data in the higher Unicode planes.
Some features :
- Uses only Unicode's Private User Areas
- Encodes up to 17 bits per character; nearly three times more efficient than Base64
- A reference Javascript implementation of encode/decode is provided
- Some sample encodings are included, including Twitter and Wordpress
Sorry, this answer comes way too late for the original competition. I started the project independently of this post, which I discovered half-way into it.
The idea of storing a bunch of reference images is interesting. Would it be so wrong to store say 25Mb of sample images, and have the encoder try and compose an image using bits of those? With such a minuscule pipe, the machinery at either end is by necessity going to be much greater than the volume of data passing through, so what's the difference between 25Mb of code, and 1Mb of code and 24Mb of image data?
(note the original guidelines ruled out restricting the input to images already in the library - I'm not suggesting that).
Stupid idea, but sha1(my_image) would result in a "perfect" representation of any image (ignoring collisions). The obvious problem is the decoding process requires inordinate amounts of brute-forcing..
1-bit monochrome would be a bit easier.. Each pixel becomes a 1 or 0, so you would have 1000 bits of data for a 100*100 pixel image. Since the SHA1 hash is 41 characters, we can fit three into one message, only have to brute force 2 sets of 3333 bits and one set of 3334 (although even that is probably still inordinate)
It's not exactly practical. Even with the fixed-length 1-bit 100*100px image there is.., assuming I'm not miscalculating, 49995000 combinations, or 16661667 when split into three.
def fact(maxu):
ttl=1
for i in range(1,maxu+1):
ttl=ttl*i
return ttl
def combi(setsize, length):
return fact(length) / (fact(setsize)*fact(length-setsize))
print (combi(2, 3333)*2) + combi(2, 3334)
# 16661667L
print combi(2, 10000)
# 49995000L
Here this compression is good.
http://www.intuac.com/userport/john/apt/
http://img86.imageshack.us/img86/4169/imagey.jpg http://img86.imageshack.us/img86/4169/imagey.jpg
다음 배치 파일을 사용했습니다.
capt mona-lisa-large.pnm out.cc 20
dapt out.cc image.pnm
Pause
결과 파일 크기는 559 바이트입니다.
아이디어 : 글꼴을 팔레트로 사용할 수 있습니까? 벡터 세트의 조합으로 이미지를 설명하려고 일련의 벡터로 이미지를 분할하십시오 (각 문자는 본질적으로 벡터 세트입니다). 이것은 글꼴을 사전으로 사용하고 있습니다. 예를 들어 수직선에는 al을, 수평선에는-를 사용할 수 있습니까? 그냥 아이디어.
참고 URL : https://stackoverflow.com/questions/891643/twitter-image-encoding-challenge
'Programing' 카테고리의 다른 글
| bash 스크립트에서 set -e는 무엇을 의미합니까? (0) | 2020.10.03 |
|---|---|
| 중간에 커밋하지 않고 두 커밋 사이의 변경 사항을 보는 방법은 무엇입니까? (0) | 2020.10.03 |
| Moment.js를 날짜 객체로 변환 (0) | 2020.10.03 |
| JQuery에서 each () 함수를 중단 / 종료하는 방법은 무엇입니까? (0) | 2020.10.03 |
| 정적 변수가 왜 나쁜 것으로 간주됩니까? (0) | 2020.10.03 |