Imagemagick과 GraphicsMagick의 차이점은 무엇입니까?
https://stackoverflow.com/questions/862051
-
21-08-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
나는이 두 가지 libs를 모두 평가하는 것을 발견했다. GraphicsMagick 비교가 말하는 것 외에도 Imagemagick이 여전히 업데이트를 받고 있으며 두 사람이 거의 동일하게 보입니다.
C ++에서 기본 이미지 조작을하고자합니다 (예 : 이미지로드, 필터, 디스플레이); 이 라이브러리를 선택할 때 알아야 할 차이점이 있습니까?
해결책
내가 읽은 내용에서 그래픽 스마크는 더 안정적이고 더 빠릅니다. 나는 비과학적인 테스트를 몇 번했고 GM이 IM보다 두 배 빠른 것으로 나타났습니다 (크기 조정).
다른 팁
TIFF Group-4 이미지 (B & W 문서 이미지)를 처리하는 데 imagemagick이 엄청나게 느리다는 것을 알았습니다. 주로 이미지 조작을 수행하기 위해 1 비트에서 1 비트에서 8로, 8로 다시 변환되기 때문입니다. GraphicsMagick Group은 버전 1.2로 TIFF 형식 지원을 정비했으며 원래 Imagemagick보다 이러한 유형의 이미지를 처리하는 데 훨씬 빠릅니다. 현재 GraphicsMagick 안정 릴리스는 1.3.5입니다.
속도가 요인이 아닌 경우 imagemagick을 사용합니다. 그러나 매일 수만 개의 이미지가 처리되는 서버 측면에서 그래픽 마법은 벤치 마크에서 최대 50% 더 빠르게 눈에 띄게 더 빠릅니다!
인생의 많은 것들과 마찬가지로, 다른 사람들은 가장 좋은 것에 대해 다른 아이디어를 가지고 있습니다. 세계 최고의 카메라 인 스코틀랜드 산에서 비가 내리는 조경 사진 작가에게 물어 보면 가벼운 날씨가 높아진 카메라를 알려줄 것입니다. 스튜디오 사진 작가에게 물어 보면 최상의 플래시 동기 속도로 최고 해상도를 알려줄 것입니다. 그리고 당신이 스포츠 사진 작가에게 물어 보면 그는 가장 빠른 자동 초점과 가장 높은 프레임 속도를 가진 사람을 알려줄 것입니다. 따라서 Imagemagick과 GraphicsMagick과 함께합니다.
지난 5 년 이상 Imagemagick에 대해 약 2,000 개의 Stackoverflow 질문에 답한 후 다음과 같은 관찰을합니다 ...
인기 측면에서 ...
- imagemagick은 12 : 1 (7,375 개의 질문 vs 611 vs 611), 및
- So Arednumber Graphicsmagick 팔로어에 대한 Imagemagick 추종자 15 : 1 (2019 년 5 월 25 일과 25 세)
성능 측면에서 ...
그래픽 스마크가 일부에게는 더 빠르지 만 모든 문제는 아닐 수 있음을 인정하게되어 기쁩니다. 그러나 속도가 가장 중요한 고려 사항이라면 아마도 libvips, 또는 오늘날의 멀티 코어 CPU 또는 OpenCV와 같은 심하게 SIMD-OPTIMASED (또는 GPU- 최적화 된) 라이브러리의 병렬 코드.
기능과 유연성 측면에서 ...
여기에는 매우 명확한 승자가 있습니다 -Imagemagick. 내 경험은 Imagemagick에 존재하는 GraphicsMagick에서 누락 된 많은 기능이 있으며,이 중 일부를 특별한 순서로 나열하지 않는다는 것입니다.
나는 Imagemagick과 마찬가지로 GraphicsMagick에 익숙하지 않다는 것을 자유롭게 인정하지만 가장 최근의 그래픽 마법 소스 코드에서 기능에 대한 언급을 찾기 위해 최선을 다했습니다. 따라서 Canny Edge Detector의 경우 GM 소스 코드에서 다음 명령을 실행했습니다.
find . -type f -exec grep -i Canny {} \;
그리고 아무것도 찾지 못했습니다.
캐니 엣지 탐지기
이것은 GM에서 완전히 누락 된 것으로 보입니다. 보다 -canny radiusxsigma{+lower-percent}{+upper-percent} IM에서.
예를 참조하십시오 여기 Lena 이미지에서 가장자리 감지 샘플 :
괄호 처리, 정교한 재 시퀀싱
이것은 GM을 사용할 때 자주 그리워하는 Imagemagick의 킬러 기능입니다. Im 전체 이미지를로드, 또는 작성 또는 복제하고 특정 이미지 및 재시험에 선택적으로 다른 처리를 적용하고 매우 간단하고 편리하게 복제하고 재로어를 적용 할 수 있습니다. 짧은 대답으로 당신에게 제공하는 놀라운 유연성을 전달하기는 어렵습니다.
로드 이미지 A와 같이 상당히 간단한 일을하고 흐리게하고 이미지 B를로드 한 다음 왼쪽에 이미지 B와 함께 이미지를 나란히 놓는다 고 상상해보십시오. Imagemagick과 같은 것처럼 보입니다.
magick imageA.png -blur x3 \( imageB.png -colorspace gray \) +swap +append result.png
당신은 GM을 시작할 수 없으며 괄호에 대해 불평 할 것입니다. 제거하면 이미지 순서 교환에 대해 불평합니다. 제거하면 괄호를 이해하지 못하고 Imagea를 왼쪽에 배치하기 때문에 그리스 스케일 변환이 두 이미지에 모두 적용됩니다.
IM의 다음 시퀀싱 명령을 참조하십시오.
-swap-clone-duplicate-delete-insert-reverse
FX DIY 이미지 처리 연산자
Im은 있습니다 -fx 엄청나게 정교한 이미지 처리를 만들고 실험 할 수있는 연산자. 이미지에서 모든 단일 픽셀에 대해 기능을 평가할 수 있습니다. 이 기능은 원하는만큼 복잡 할 수 있습니다 (원하는 경우 파일에 저장) 및 모든 수학 연산, 3 차 스타일을 사용하십시오. if 진술, 다른 이미지에서도 픽셀에 대한 참조 및 밝기 또는 채도 등.
다음은 몇 가지 예입니다.
magick rose: -channel G -fx 'sin(pi*i/w)' -separate fx_sine_gradient.gif
magick -size 80x80 xc: -channel G -fx 'sin((i-w/2)*(j-h/2)/w)/2+.5' -separate fx_2d_gradient.gif
이 기능을 사용하여 녹색 스크린 (크로마 키) 이미지를 처리하는 데 큰 영향을 미치는 stackoverflow 답변 여기.
푸리에 (주파수 도메인) 분석
GM의 순방향 또는 역 푸리에 분석에 대한 언급은 없거나 일반적으로 지원하는 데 필요한 높은 동적 범위 지원 (나중에 참조)이없는 것으로 보입니다. 보다 -fft IM에서.
연결된 구성 요소 분석 / 라벨링 / 블로브 분석
아니오가있는 것 같습니다 "연결된 구성 요소 분석" GM에서도 알려져 있습니다 "라벨링" 그리고 "블로브 분석". 보다 -connected-components connectivity 4- 및 8 연결 블로브 분석의 경우.
이 기능만으로 60 개 이상의 답변을 제공했습니다 여기.
허프 라인 탐지
GM에는 허프 라인 탐지가없는 것으로 보인다. 보다 -hough-lines widthxheight{+threshold} IM에서.
기능에 대한 설명을 참조하십시오 여기 및 감지 된 라인의 예제 :
순간과 지각 해시 (Phash)
이미지 모멘트 계산 (중심 및 더 높은 순서)이나 GM의 지각 해싱에 대한 지원이없는 것으로 보입니다. 보다 -moments IM에서.
형태
GM에서 형태 학적 처리에 대한 지원이없는 것으로 보인다. IM에는 다음에 대한 정교한 지원이 있습니다.
- 팽창
- 부식
- 형태 학적 개방 및 폐쇄
- 골격화
- 거리 형태
- 상단 모자와 하단 모자 형태
- 히트 앤 미스 형태 - 라인 끝, 라인 접합, 피크, 릿지, 볼록한 선체 등
당신이 할 수있는 모든 정교한 처리를보십시오 이 훌륭한 튜토리얼.
대비 제한된 적응 히스토그램 이퀄라이제이션 -Clahe
GM에서 대비 제한된 적응성 히스토그램 이퀄라이제이션에 대한 지원이없는 것으로 보인다. 보다 -clahe widthxheight{%}{+}number-bins{+}clip-limit{!} IM에서.
HDRI- 높은 동적 범위 이미징
8, 16 및 32 비트 정수 유형에서 GM에서 높은 동적 범위 이미징에 대한 지원이없는 것으로 보입니다.
회선
Imagemagick은 다양한 유형의 컨볼 루션을 지원합니다.
- 가우스 개 개의 차이
- 라플라시안
- 솜
- 나침반
- Prewitt
- 로버츠
- Frei-Chen
이들 중 어느 것도 GM 소스 코드에 언급되어 있지 않습니다.
Magick Persistent Register (MPR)
이것은 Imagemagick에 존재하는 귀중한 기능으로, 디스크에 쓰는 오버 헤드없이 처리 중에 명명 된 메모리 덩어리에 중간 처리 결과를 작성할 수 있습니다. 예를 들어, 텍스처 나 패턴을 준비한 다음 이미지 위로 타일을 타일하거나 마스크를 준비한 다음 디스크에 가지 않고도 동일한 처리에 나중에 적용 할 수 있습니다.
예는 다음과 같습니다.
magick tree.gif -flip -write mpr:tree +delete -size 64x64 tile:mpr:tree mpr_tile.gif
더 넓은 ColourSpace 지원
IM은 GM에서 찾을 수없는 다음 색상 스페이스를 지원합니다.
- 시엘 라브
- HCL
- HSI
- LMS
- 기타.
판고 지원
IM은 HTML과 유사한 Pango Text Markup 언어를 지원하며 변경되는 텍스트로 이미지를 주석을 달 수 있습니다.
- 글꼴, 색상, 크기, 무게, 이탤릭체
- 첨자, 슈퍼 스크립트, 스트라이크 스루
- 정당화
중간 문장과 훨씬 더. 좋은 예가 있습니다 여기.
JPEG로 수축 함
이 귀중한 기능을 사용하면 라이브러리가 디스크에서 읽을 때 JPEG 이미지를 축소 할 수 있으므로 필요한 계수 만 읽으므로 I/O가 줄어들고 메모리 소비가 최소화됩니다. 다운 스케일링 이미지를 크게 향상시킬 수 있습니다.
예를 참조하십시오 여기.
작성시 최대 JPEG 크기 정의
IM은 JPEG 파일을 작성할 때 최대 파일 크기를 지정하기 위해 많은 요청이있는 옵션을 지원합니다. -define jpeg:extent=400KB 예를 들어.
극지 좌표 변환
IM은 직교와 극지 좌표 사이의 전환을 지원합니다. -distort polar 그리고 -distort depolar.
맞춤형 영역에 대한 통계 및 운영
그것으로 -statistic MxN 운영자 인 Imagemagick은 많은 유용한 종류의 통계 및 효과를 생성 할 수 있습니다. 예를 들어, 각 픽셀을 이미지에서 5x3 인근의 그라디언트 (가장 밝은 것과 가장 어두운 차이)로 설정할 수 있습니다.
magick image.png -statistic gradient 5x3 result.png
또는 각 픽셀을 1x200 인근의 중앙값으로 설정할 수 있습니다.
magick image.png -statistic median 1x200 result.png
응용 프로그램의 예를 참조하십시오 여기.
이미지 시퀀스
Imagemagick은 일련의 이미지를 지원하므로 High ISO에서 촬영 한 매우 시끄러운 이미지 세트가있는 경우 전체 이미지 시퀀스를로드하고 예를 들어 모든 이미지의 중앙값 또는 평균을 취하여 노이즈를 줄일 수 있습니다. 참조 -evaluate-sequence 운영자. 나는 단일 이미지로 주변 지역의 중앙값을 의미하지는 않습니다. 각 픽셀 위치에서 모든 이미지의 중앙값을 찾는 것을 의미합니다.
위의 것은 어떤 식 으로든 철저한 목록이 아니며, 차이점에 대해 생각할 때 떠오른 첫 몇 가지 일에 불과합니다. 나는 HEIC (iPhone 이미지 용 Apple의 형식), Exr과 같은 점점 더 일반적인 높은 다이나믹 레인지 형식에 대한 지원을 언급하지 않았습니다. 실제로 두 제품이 지원하는 파일 형식을 비교하면 (gm convert -list format 그리고 magick identify -list format) IM이 261 형식을 지원하고 GM이 192를 지원한다는 것을 알게 될 것입니다.
내가 말했듯이, 다른 사람들은 다른 의견을 가지고 있습니다. 좋아하는 것을 선택하고 그것을 사용하는 것을 즐기십시오.
항상 그렇듯이, 나는 Anthony Thyssen에게 imagemagick에 대한 그의 훌륭한 통찰과 담론에 대해 빚을졌습니다. https://www.imagemagick.org/usage/ 그의 사례에 대해서는 Fred Weinhaus에게도 감사드립니다.
역사
GraphicsMagick은 창립 개발자 간의 분쟁으로 인해 2002 년 Imagemagick에서 포크되었습니다. 따라서 동일한 코드베이스를 공유합니다.
ref : https://en.wikipedia.org/wiki/graphicsmagick
목표
GraphicsMagick
- 단순하고 안정적이며 명확한 코드베이스 / 아키텍처에 중점을 둡니다.
Imagemagick
- 새로운 기능을 출시하고 더 넓은 도구베이스를 확장하는 데 중점을 둡니다.
속도 외에도 Imagemagick은 터미널 쉘에 여러 CLI 도구를 추가하는 반면 GraphicsMagick은 호출 할 수있는 단일 도구입니다.
CLI 인터페이스 디자인
GraphicsMagick
gm <command> <options> <file>
Imagemagick
convert <options> <file>
compare <options> <file>
IMHO, 나는 선호한다 (사실, 만 사용) imageMagick에 대한 GM (GraphicsMagick)은 후자가 도구 이름 충돌 가능성이 높기 때문에 특히 서버 측 자동화 작업 중에 특정 도구가 실행되지 않는 이유를 찾는 데 많은 문제가 발생합니다. 요약하면 GraphicsMagick은 훨씬 더 명확한 디자인을 가지고 있습니다.
프로젝트에서 Convert라는 바이너리를 상상해보십시오. Imagemagick의 Convert 또는 프로젝트에서 자신의 롤 도구입니까?
imagemagick 도구 목록 (변환, 비교, 디스플레이 포함) : https://imagemagick.org/script/command-line-tools.php
GraphicsMagick 명령 목록 :http://www.graphicsmagick.org/utilities.html
참고 : Mark S가 언급 한 V7과 같이 Imagemagick은 이제 단일 바이너리로 배포되며 구형 V6 명령을 지원합니다.
성능
간단한 메모리 소비 테스트는 여기에서 찾을 수 있습니다.https://coderwall.com/p/1l7h-a/imagemagick-bloat-graphicsmagick
의존성
GraphicsMagick은 36 개의 라이브러리에 의존하는 반면 ImageMagick은 64를 필요로합니다. http://www.graphicsmagick.org/1.3/faq.html
GraphicsMagick은 Imagemagick의 초기 포크였습니다. Imagemagick의 역사와 GraphicsMagick의 포크에 대해 읽을 수 있습니다. https://imagemagick.org/script/history.php. Imagemagick은 계속해서 광범위하게 개발 된 것으로 보이지만 GraphicsMagick은 포크 이후로 정체 된 상태로 유지되었습니다.
