イラストレータなどで出力した
32bitのpng画像を埋め込もうとすると色がくすんだ色になります。
画像の中にアルファチャンネルがあってもなくてもこの現象は起こります。
コードが以下の通りです。
\begin{figure}[htb]
\section{\textcolor{blue}{\Large{yyyy}}}
\begin{boxedminipage}{0.52\hsize}
\includegraphics[width=7.10562414266118cm,bb=0 0 690.666666666667 740.390625]{.//xxx.png}
\end{boxedminipage}
\section{\textcolor{blue}{\Large{yyyy}}}
\begin{boxedminipage}{0.52\hsize}
\includegraphics[width=7.10562414266118cm,bb=0 0 690.666666666667 740.390625]{.//xxx.png}
\end{boxedminipage}
\end{figure}
8bitや24bit画像に変換すると正常な色で表示されます。
また、
\begin{figure}[htb]
\end{figure}
内に32bitと8bitや24bit画像を混在させると
他の8bitや24bit画像の色まで変になります。
また、 \section{\textcolor{blue}{\Large{yyyy}}}
で入れた文字の色も青色ではなく、紺色になります。
これはどうすれば良いでしょうか？
よろしくお願いいたします。
\documentclass{jarticle}
\usepackage{graphicx}
\usepackage{geometry}
\usepackage[usenames]{color}
\usepackage{boxedminipage}
\usepackage{lastpage}
\usepackage[dvipdfmx]{hyperref}
\usepackage{pxjahyper} %%hyperref読み込みの直後に
\geometry{left=15mm,right=15mm,top=10mm,bottom=18mm}
\makeatletter
\def\ps@plain{\let\@mkboth\@gobbletwo
\def\@oddfoot{\hfill ---\ \footnotesize{\thepage/\pageref{LastPage}}\ --- \hfill}
\def\@evenfoot{}\let\@evenfoot\@oddfoot}
\makeatother
\begin{document}
\pagestyle{plain}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\end{document}
\documentclass{jarticle}
\usepackage{graphicx}
\usepackage{geometry}
\usepackage[usenames]{color}
\usepackage{boxedminipage}
\usepackage{lastpage}
\usepackage[dvipdfmx]{hyperref}
\usepackage{pxjahyper} %%hyperref読み込みの直後に
\geometry{left=15mm,right=15mm,top=10mm,bottom=18mm}
\makeatletter
\def\ps@plain{\let\@mkboth\@gobbletwo
\def\@oddfoot{\hfill ---\ \footnotesize{\thepage/\pageref{LastPage}}\ --- \hfill}
\def\@evenfoot{}\let\@evenfoot\@oddfoot}
\makeatother
\begin{document}
\pagestyle{plain}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\end{document}
本題からはそれるが，ソースを見て思ったこと。
つまり，一般論として
\documentclass{jsarticle}
\usepackage[dvipdfmx]{graphicx}
\usepackage[dvipdfmx,usenames]{color}
あるいは
\documentclass[dvipdfmx]{jsarticle}
\usepackage{graphicx}
\usepackage[usenames]{color}
とすべき。
- platex + dvipdfmx を使うのなら，graphicx と color にも hyperref 同様に dvipdfmx ドライバオプションを付ける（TeX 以外のソフトが処理するから）。
- jarticle でなく jsarticle クラスを使うのが標準（jsarticle はJIS 組版規則に適合）。
つまり，一般論として
\documentclass{jsarticle}
\usepackage[dvipdfmx]{graphicx}
\usepackage[dvipdfmx,usenames]{color}
あるいは
\documentclass[dvipdfmx]{jsarticle}
\usepackage{graphicx}
\usepackage[usenames]{color}
とすべき。
http://fast-uploader.com/file/6987251016264/
24bitと32bitのpng画像とtex画像および変換したpdfファイルをアップロードしました。
何か解決策があれば教えてください。
よろしくお願いいたします。
同じ PNG でも，一度 convert を通すだけで正常になるみたいです．
identify で調べていたのですが，何が原因なのでしょうか．
$ convert 32bit{,_c}.png
$ identify -verbose 32bit.png > 32bit.info
$ identify -verbose 32bit_c.png > 32bit_c.info
$ diff -u 32bit{,_c}.info
--- 32bit.info 2015-05-15 23:11:58.061456419 +0900
+++ 32bit_c.info 2015-05-15 23:11:59.709456509 +0900
@@ -1,4 +1,4 @@
-Image: 32bit.png
+Image: 32bit_c.png
Format: PNG (Portable Network Graphics)
Mime type: image/png
Class: DirectClass
@@ -60,7 +60,7 @@
entropy: 0.297493
Alpha: srgba(255,255,255,0) #FFFFFF00
Rendering intent: Perceptual
- Gamma: 0.454545
+ Gamma: 0.45455
Chromaticity:
red primary: (0.63999,0.33001)
green primary: (0.3,0.6)
@@ -79,9 +79,11 @@
Compression: Zip
Orientation: Undefined
Properties:
- date:create: 2015-05-15T22:24:16+09:00
- date:modify: 2015-05-15T22:07:38+09:00
+ date:create: 2015-05-15T23:11:54+09:00
+ date:modify: 2015-05-15T23:11:54+09:00
+ png:bKGD: chunk was found (see Background color, above)
png:cHRM: chunk was found (see Chromaticity, above)
+ png:gAMA: gamma=0.45454544 (See Gamma, above)
png:IHDR.bit-depth-orig: 8
png:IHDR.bit_depth: 8
png:IHDR.color-type-orig: 6
@@ -90,14 +92,15 @@
png:IHDR.width,height: 696, 261
png:pHYs: x_res=2835, y_res=2835, units=1
png:sRGB: intent=0 (Perceptual Intent)
+ png:text: 2 tEXt/zTXt/iTXt chunks were found
signature: 827b4e6441c0bb017a23458752154a3d5ddad5225f652b90f018e853d81c0756
Artifacts:
- filename: 32bit.png
+ filename: 32bit_c.png
verbose: true
Tainted: False
- Filesize: 74.1KB
+ Filesize: 75.8KB
Number pixels: 182K
- Pixels per second: 0B
+ Pixels per second: 90.828GB
User time: 0.000u
Elapsed time: 0:01.000
Version: ImageMagick 6.9.0-3 Q16 x86_64 2015-01-05 http://www.imagemagick.org
identify で調べていたのですが，何が原因なのでしょうか．
$ convert 32bit{,_c}.png
$ identify -verbose 32bit.png > 32bit.info
$ identify -verbose 32bit_c.png > 32bit_c.info
$ diff -u 32bit{,_c}.info
--- 32bit.info 2015-05-15 23:11:58.061456419 +0900
+++ 32bit_c.info 2015-05-15 23:11:59.709456509 +0900
@@ -1,4 +1,4 @@
-Image: 32bit.png
+Image: 32bit_c.png
Format: PNG (Portable Network Graphics)
Mime type: image/png
Class: DirectClass
@@ -60,7 +60,7 @@
entropy: 0.297493
Alpha: srgba(255,255,255,0) #FFFFFF00
Rendering intent: Perceptual
- Gamma: 0.454545
+ Gamma: 0.45455
Chromaticity:
red primary: (0.63999,0.33001)
green primary: (0.3,0.6)
@@ -79,9 +79,11 @@
Compression: Zip
Orientation: Undefined
Properties:
- date:create: 2015-05-15T22:24:16+09:00
- date:modify: 2015-05-15T22:07:38+09:00
+ date:create: 2015-05-15T23:11:54+09:00
+ date:modify: 2015-05-15T23:11:54+09:00
+ png:bKGD: chunk was found (see Background color, above)
png:cHRM: chunk was found (see Chromaticity, above)
+ png:gAMA: gamma=0.45454544 (See Gamma, above)
png:IHDR.bit-depth-orig: 8
png:IHDR.bit_depth: 8
png:IHDR.color-type-orig: 6
@@ -90,14 +92,15 @@
png:IHDR.width,height: 696, 261
png:pHYs: x_res=2835, y_res=2835, units=1
png:sRGB: intent=0 (Perceptual Intent)
+ png:text: 2 tEXt/zTXt/iTXt chunks were found
signature: 827b4e6441c0bb017a23458752154a3d5ddad5225f652b90f018e853d81c0756
Artifacts:
- filename: 32bit.png
+ filename: 32bit_c.png
verbose: true
Tainted: False
- Filesize: 74.1KB
+ Filesize: 75.8KB
Number pixels: 182K
- Pixels per second: 0B
+ Pixels per second: 90.828GB
User time: 0.000u
Elapsed time: 0:01.000
Version: ImageMagick 6.9.0-3 Q16 x86_64 2015-01-05 http://www.imagemagick.org
> cHRM も gAMA もキャリブレーションに使われる情報ですが、gAMA が指定されていなかった場合のデフォルト値をどうするかというところでおかしくなります。
なるほど．大体わかったように思います．詳しい解説ありがとうございました．
ただ，一番最初の質問の
> また、
> \begin{figure}[htb]
> \end{figure}
> 内に32bitと8bitや24bit画像を混在させると
> 他の8bitや24bit画像の色まで変になります。
> また、 \section{\textcolor{blue}{\Large{yyyy}}}
> で入れた文字の色も青色ではなく、紺色になります。
>
> これはどうすれば良いでしょうか？
は再現できなくて，よくわからない私です．
なるほど．大体わかったように思います．詳しい解説ありがとうございました．
ただ，一番最初の質問の
> また、
> \begin{figure}[htb]
> \end{figure}
> 内に32bitと8bitや24bit画像を混在させると
> 他の8bitや24bit画像の色まで変になります。
> また、 \section{\textcolor{blue}{\Large{yyyy}}}
> で入れた文字の色も青色ではなく、紺色になります。
>
> これはどうすれば良いでしょうか？
は再現できなくて，よくわからない私です．
昨晩の話は
http://www.libpng.org/pub/png/book/chapter10.html#png.ch10.div.2
のあたりですね．
ちなみに，dvipdfmx ではなくて pdflatex を使う場合には正常なようです．
xelatex は xdvipdfmx を使うのでだめ．
dvipdfmx のソースを取ってきて試してみましたが，添付のようにデフォルト値の 1.0 を
2.2 に修正すると 32bit.png でも正常に取り込めることが確認できました．
pdftex の writepng.c も見てみましたが，こちらは libpng の png_get_gAMA() などに
丸投げで，cHRM があって gAMA がない場合は考慮していないように見えます．
2.2 に修正するのが正しいのかどうかよくわからないので，とりあえず実験結果だけご報告です．
http://www.libpng.org/pub/png/book/chapter10.html#png.ch10.div.2
のあたりですね．
ちなみに，dvipdfmx ではなくて pdflatex を使う場合には正常なようです．
xelatex は xdvipdfmx を使うのでだめ．
dvipdfmx のソースを取ってきて試してみましたが，添付のようにデフォルト値の 1.0 を
2.2 に修正すると 32bit.png でも正常に取り込めることが確認できました．
pdftex の writepng.c も見てみましたが，こちらは libpng の png_get_gAMA() などに
丸投げで，cHRM があって gAMA がない場合は考慮していないように見えます．
2.2 に修正するのが正しいのかどうかよくわからないので，とりあえず実験結果だけご報告です．
ご回答ありがとうございます。
詳細はまだ理解できていないのですが
とりあえず添付してくださったdvipdfmx_pngimage_gAMA.patchを使えばうまくいくということでしょうか？
このファイルはどのようにして使えば良いか教えていただけないでしょうか？
http://www.koikikukan.com/archives/2006/01/22-235056.php
パッチの当て方は見つかったのですが
これをソースに対して実行した後
どのようにexe形式にビルドすれば良いのでしょうか？
ご回答ありがとうございます。
うまく表示されない理由は理解できたのですがdvipdfmxへのパッチの当て方を教えていただけないでしょうか？
http://archive.debian.net/ja/source/sarge/dvipdfmx
このページでソースをDLし、そのフォルダーでパッチを実行し、
それからどうすれば良いですか？
C言語か何かでビルドする必要があるのでしょうか？
パッチを上げたのは，確かに dvipdfmx のその部分が原因のようだということを伝える意図であって，
これを myu myo さんが使うことを推奨しているわけではないです．
独自ビルドを作ってもあまり根本的な解決にはならないと思いますので，
convert か pngcrush を使うことをおすすめいたします．
色化けするかの判定法ですが，問題は cHRM があって gAMA がないときに起こりますので，
identify -verbose の出力に png:cHRM を含む行がありかつ png:gAMA を含む行がないときに
処理をするようにすればよいのではないでしょうか．
これを myu myo さんが使うことを推奨しているわけではないです．
独自ビルドを作ってもあまり根本的な解決にはならないと思いますので，
convert か pngcrush を使うことをおすすめいたします．
色化けするかの判定法ですが，問題は cHRM があって gAMA がないときに起こりますので，
identify -verbose の出力に png:cHRM を含む行がありかつ png:gAMA を含む行がないときに
処理をするようにすればよいのではないでしょうか．
先にも書かれていた通り，この場合に 1.0 にするか 2.2 にするかは「未定義」というわけですかね．
（ごめんなさい，関連文書をちゃんと読むべきなのですが……．）
ただ，手元の Web ブラウザや画像ビューワ，pdflatex による取り込みでは表示が全部同じなのに，
dvipdfmx だけが色が変わってしまうので，結果だけを見ると dvipdfmx に問題があるように思えてしまいます．
> PNGの仕様書の9.3 Encoder color handling ではcHRMを書くんだったらgAMAも書くべきとなっています。
見ましたが，
> ... then the encoder is strongly encouraged to output the cHRM chunk. If it does so,
> the gAMA chunk should also be written; decoders can do little with cHRM if gAMA is missing.
とありますね．cHRM があっても gAMA がなかったら何もしない，というのでは解決しないのだろうか．
あと，少し疑問なのですが，pngimage.c には
> If sRGB chunk is present, cHRM and gAMA chunk must be ignored.
という記述があって，一方で identify -verbose 32bit.png の結果を見ると
> png:sRGB: intent=0 (Perceptual Intent)
とあるのですが，intent=0 だと sRGB チャンクは含まれていない，ということになるのですかね．
（自分でも調べます……．）
（ごめんなさい，関連文書をちゃんと読むべきなのですが……．）
ただ，手元の Web ブラウザや画像ビューワ，pdflatex による取り込みでは表示が全部同じなのに，
dvipdfmx だけが色が変わってしまうので，結果だけを見ると dvipdfmx に問題があるように思えてしまいます．
> PNGの仕様書の9.3 Encoder color handling ではcHRMを書くんだったらgAMAも書くべきとなっています。
見ましたが，
> ... then the encoder is strongly encouraged to output the cHRM chunk. If it does so,
> the gAMA chunk should also be written; decoders can do little with cHRM if gAMA is missing.
とありますね．cHRM があっても gAMA がなかったら何もしない，というのでは解決しないのだろうか．
あと，少し疑問なのですが，pngimage.c には
> If sRGB chunk is present, cHRM and gAMA chunk must be ignored.
という記述があって，一方で identify -verbose 32bit.png の結果を見ると
> png:sRGB: intent=0 (Perceptual Intent)
とあるのですが，intent=0 だと sRGB チャンクは含まれていない，ということになるのですかね．
（自分でも調べます……．）
どうしてもやりたいならば止めはしませんが，convert を使った方が楽だと思いますが……．
とは言ったものの，おそらく Windows をお使いだと思うのですが，Windows の場合は
どうやってビルドするのが正しいのでしょうね（私は Linux ユーザです）．
MSYS2 で試しに一度だけビルドしてみたことはありますが，詳しくは知らないです．
VC++ とかだとどうやるんでしょう……．
Linux ならば以下のような感じです．Windows でも MinGW, MSYS2 などの
Unix ライクな環境を準備して必要なツールを入れれば同じような要領でできるはずです．
（ただし，途中で何か予期せぬハマリポイントがある可能性あり．何か起こっても一切保証いたしませんので，自力でなんとかして下さい．）
まず，dvipdfmx の最新ソースは TeX Live のレポジトリにあるので，それを全て取得してきます．
https://www.tug.org/texlive/svn/
にある通り，適当なディレクトリで
$ rsync -a --delete --exclude=.svn tug.org::tldevsrc/Build/source .
とやります．
これで source というディレクトリ中に TeX Live のソースコードが入ります．
とりあえず dvipdfmx だけが欲しいので
$ cd source
$ ./configure --enable-build-in-source-tree --disable-all-pkgs --enable-dvipdfm-x
$ make -j3
とします．これでしばらく待っていると texk/dvipdfm-x/ に dvipdfmx のバイナリができると思います．
ここまで正常に行けば，パッチをあてて make しなおしましょう．
$ cd texk/dvipfmx-x
（ここで，この移動先のディレクトリにパッチを置いて下さい．wget だとログイン情報がなくて取れなかった……．）
$ patch < dvipdfmx_pngimage_gAMA.patch
$ make
これで make を実行したディレクトリ中にパッチ適用済みの dvipdfmx.exe ができると
思うので，現在お使いの dvipdfmx.exe と置き換えます．
念のため，元々ある dvipdfmx.exe はリネームして保存しておいて下さい．
とは言ったものの，おそらく Windows をお使いだと思うのですが，Windows の場合は
どうやってビルドするのが正しいのでしょうね（私は Linux ユーザです）．
MSYS2 で試しに一度だけビルドしてみたことはありますが，詳しくは知らないです．
VC++ とかだとどうやるんでしょう……．
Linux ならば以下のような感じです．Windows でも MinGW, MSYS2 などの
Unix ライクな環境を準備して必要なツールを入れれば同じような要領でできるはずです．
（ただし，途中で何か予期せぬハマリポイントがある可能性あり．何か起こっても一切保証いたしませんので，自力でなんとかして下さい．）
まず，dvipdfmx の最新ソースは TeX Live のレポジトリにあるので，それを全て取得してきます．
https://www.tug.org/texlive/svn/
にある通り，適当なディレクトリで
$ rsync -a --delete --exclude=.svn tug.org::tldevsrc/Build/source .
とやります．
これで source というディレクトリ中に TeX Live のソースコードが入ります．
とりあえず dvipdfmx だけが欲しいので
$ cd source
$ ./configure --enable-build-in-source-tree --disable-all-pkgs --enable-dvipdfm-x
$ make -j3
とします．これでしばらく待っていると texk/dvipdfm-x/ に dvipdfmx のバイナリができると思います．
ここまで正常に行けば，パッチをあてて make しなおしましょう．
$ cd texk/dvipfmx-x
（ここで，この移動先のディレクトリにパッチを置いて下さい．wget だとログイン情報がなくて取れなかった……．）
$ patch < dvipdfmx_pngimage_gAMA.patch
$ make
これで make を実行したディレクトリ中にパッチ適用済みの dvipdfmx.exe ができると
思うので，現在お使いの dvipdfmx.exe と置き換えます．
念のため，元々ある dvipdfmx.exe はリネームして保存しておいて下さい．
先ほどファイルをアップしてくださった方（kakutoさん）ありがとうございます。
試してみたのですが
私の環境ではkpathsea621.dllではなく
kpathsea600.dllが入っています。
dvipdfmx.dllとkpathsea621.dllの二つのファイルをコピーしてコンパイルしたところ、
前よりは色が薄くなる量は少なくなったのですが
やはりまだ、元の画像と比べて色が変です。
また、出力されたpdfのバージョンは2.2ではなく1.4になっています。
TeX Liveの最新版を入れる必要がありますか？
できれば、TeX全体をアップデートせずに
この部分だけ改善したいのですが、
何か解決策があれば教えてください。
試してみたのですが
私の環境ではkpathsea621.dllではなく
kpathsea600.dllが入っています。
dvipdfmx.dllとkpathsea621.dllの二つのファイルをコピーしてコンパイルしたところ、
前よりは色が薄くなる量は少なくなったのですが
やはりまだ、元の画像と比べて色が変です。
また、出力されたpdfのバージョンは2.2ではなく1.4になっています。
TeX Liveの最新版を入れる必要がありますか？
できれば、TeX全体をアップデートせずに
この部分だけ改善したいのですが、
何か解決策があれば教えてください。
前に添付したものは return NULL;
としたものですが，G = 2.2;
でもこちらでは同じように見えます。
若干薄く見えますが，それが限度のようです。
convert で変換した場合とも同じように見えます。
TeX Live 2015(pretest) は G = 1.0; で変更不可
です。
将来，開発者の方により，何等かの変更がされるかも
知れません。
バージョン 2.2 の pdf はありません。形式的に
出力 pdf のバージョンを変更するには
-V number
オプションを使います。(number = 3, 4, 5, 6, 7)。
現在は 1.5 (number = 5) がデフォルトですが，
古い myu myo さんの場合は 1.4 がデフォルトになっています。
としたものですが，G = 2.2;
でもこちらでは同じように見えます。
若干薄く見えますが，それが限度のようです。
convert で変換した場合とも同じように見えます。
TeX Live 2015(pretest) は G = 1.0; で変更不可
です。
将来，開発者の方により，何等かの変更がされるかも
知れません。
バージョン 2.2 の pdf はありません。形式的に
出力 pdf のバージョンを変更するには
-V number
オプションを使います。(number = 3, 4, 5, 6, 7)。
現在は 1.5 (number = 5) がデフォルトですが，
古い myu myo さんの場合は 1.4 がデフォルトになっています。
角藤先生，お試しいただきありがとうございます．
> TeX Live 2015(pretest) は G = 1.0; で変更不可
> です。
そうですか．return NULL; がリーズナブルなのかな，とも思いましたが……．
myu myo さん，既に何度か書かれている通り，色の変化がどうしても気になるならば
sRGB チャンクを付けるか ICC プロファイルを埋め込め，ということになるのだと思います．
ところで，
> 前よりは色が薄くなる量は少なくなったのですが
> やはりまだ、元の画像と比べて色が変です。
というのは，どの程度薄くなるのでしょうか？
私の環境では，Evince という PDF ビューワで見る限り，パッチを当てれば
32bit.png と 24bit.png の差はわからなくなります．convert でも同様です．
スクリーンショットや出力された PDF を上げていただけるとありがたいです．
（ただ，今週は急な用事が入ってしまって，すぐには返信ができないかもしれません．）
> TeX Live 2015(pretest) は G = 1.0; で変更不可
> です。
そうですか．return NULL; がリーズナブルなのかな，とも思いましたが……．
myu myo さん，既に何度か書かれている通り，色の変化がどうしても気になるならば
sRGB チャンクを付けるか ICC プロファイルを埋め込め，ということになるのだと思います．
ところで，
> 前よりは色が薄くなる量は少なくなったのですが
> やはりまだ、元の画像と比べて色が変です。
というのは，どの程度薄くなるのでしょうか？
私の環境では，Evince という PDF ビューワで見る限り，パッチを当てれば
32bit.png と 24bit.png の差はわからなくなります．convert でも同様です．
スクリーンショットや出力された PDF を上げていただけるとありがたいです．
（ただ，今週は急な用事が入ってしまって，すぐには返信ができないかもしれません．）
私のところでもコンパイルして手元の Mac 標準の Preview.app（OS X 10.7.5）と Acrobat X で表示してみましたが…
上の2つが Preview.app（左：24bitのみ、右：24bitと32bit-convert）
下の2つが Acrobat X（左：24bitのみ、右：24bitと32bit-convert）
です。すべてまとめてスクリーンショットしました。32bit-convert というのは
convert 32bit.png 32bit_c.png
で作った PNG を取り込んだものです。
Acrobat の 24bitと32bit-convert がくすんでいますね…どうやら PDF ビューアのせいもありそうです。
http://tex.stackexchange.com/questions/9261/using-opacity-in-tikz-causes-strange-rendering-in-acrobat
https://forums.adobe.com/thread/1021559
ここらへんが解決策になるんじゃないでしょうか。
dvipdfmx でこれをやるには
\special{pdf:put @thispage << /Group <</S /Transparency /I true /CS /DeviceRGB >> >>}
を画像を挿入するページに入るようにする。
https://forums.adobe.com/thread/1021559
ここらへんが解決策になるんじゃないでしょうか。
dvipdfmx でこれをやるには
\special{pdf:put @thispage << /Group <</S /Transparency /I true /CS /DeviceRGB >> >>}
を画像を挿入するページに入るようにする。
> 魔法の呪文のようで内容は
> 全く理解できていませんが
匿名さんがリンクして下さった Adobe のフォーラムを見てみた限りだと，
ページ中に透明度の設定されたオブジェクトが存在する場合は，
色の合成をどの色空間で行うかを明示的に指定する必要があって，
指定がない場合はビューアのデフォルトのものが使用される．
多くのビューアでは RGB が使われるが，古い Acrobat では CMYK が
使われるため，色が変わってきてしまう，ということのようです．
だから，1つでもアルファチャンネルを持つ画像があると，そのページの
他の画像も影響を受けるわけです．
\special で埋め込んだ命令は，そのページの色合成に RGB を使うように
指定しているのだと思います．
> 全く理解できていませんが
匿名さんがリンクして下さった Adobe のフォーラムを見てみた限りだと，
ページ中に透明度の設定されたオブジェクトが存在する場合は，
色の合成をどの色空間で行うかを明示的に指定する必要があって，
指定がない場合はビューアのデフォルトのものが使用される．
多くのビューアでは RGB が使われるが，古い Acrobat では CMYK が
使われるため，色が変わってきてしまう，ということのようです．
だから，1つでもアルファチャンネルを持つ画像があると，そのページの
他の画像も影響を受けるわけです．
\special で埋め込んだ命令は，そのページの色合成に RGB を使うように
指定しているのだと思います．