I’m trying to use ImageMagick to convert some tiffs from the embedded ICC profile to another ICC profile from disk. I’d prefer to use just about any command line program there is other than ImageMagick. But some of the tiffs are 32f which aren’t supported by cctiff. And as far as I can tell LCMS tificc requires that the input profile be included as part of the command (otherwise it defaults to sRGB), and the input tiffs don’t all have the same embedded ICC profile.
However, for black and white RGB images, where R=G=B everywhere, the above ImageMagick command makes the output tiff grayscale, at which point the actual color space information is completely lost. And then ImageMagick has the nerve to complain that RGB profiles can’t be embedded in grayscale images.
I’ve been searching the internet but so far haven’t found the answer. So I was hoping one of the pixls.us ImageMagick gurus might know how to keep ImageMagick from automatically making grayscale images out of black and white RGB tiffs.
In case anyone needs to work with pngs, the png equivalent to "-type TrueColor " is “-define png:color-type=2”.
The context of my question regarding imagemagick and tiffs (and pngs) is trying to export png or tiff sidecars for GIMP-2.9 sidecar files. So moving on to my next question, over in this thread - A script to open a GIMP 2.9 XCF file and export a png - #9 by houz - @houz suggested using “find” as a way to recurse through folders to execute a command.
Having exported the “sidecars”, I want to process them to make them smaller both in dimension and in file size. So here’s the “find” commands I want to use:
List the files output by the script to export tifs or pngs from XCF files - I modified the output name to distinguish between default GIMP XCF files and GIMP-CCE XCF files. This example uses tiffs: find . -name '*.CCE-xcf.tif' -exec ls -l '{}' \;
Before resizing, convert all the tiffs to a linear gamma color space that’s large enough to encompass all colors that your monitor can show: find . -name '*.CCE-xcf.tif' -exec mogrify -profile /usr/share/color/icc/ClayRGB-elle-V4-g10.icc -type TrueColor '{}' \;
Resize the tiffs to a convenient size for use in digiKam: find . -name '*.CCE-xcf.tif' -exec mogrify -resize 1024x1024\> -type TrueColor '{}' \;
Convert the tiffs to a perceptually uniform color space: find . -name '*.CCE-xcf.tif' -exec mogrify -profile /usr/share/color/icc/AdobeRGB-elle-V4-g22.icc -type TrueColor '{}' \;
To save disk space, convert the tiffs to 8-bits: find . -name '*.CCE-xcf.tif' -exec mogrify -depth 8 -type TrueColor '{}' \;
The first “find” comamnd is to make sure that the subsequent “find” commands will operation on the correct files. I suspect the last four “find” commands can be combined into one command - Suggestions regarding “how to” are very welcome!
@afre , @Morgan_Hardwood , or other imagemagick gurus - does my example resize command (3 above) completely bypass the imagemagick -resize option to apply a gamma “correction” of 0.45455? Because of course this gamma “correction” would be wrong given that I’ve already converted the image to a linear gamma RGB working space. Or do I need to add some other option to tell ImageMagick that the images are already in a linear gamma color space?
Yes, there is no point in using find multiple times. Also, writing to a non-native file format and leaving the processing environment multiple times would impact accuracy, etc. Lastly, I use magick (convert) instead of mogrify because I like to compare the results and make sure nothing went wrong.
Yes, you need to tell IM what you are doing in a very specific manner. In my experience, it is very easy to make mistakes or misunderstand what to do. When in doubt, I double check with someone in their forums. See ImageMagick – Color Management.
In case you are open to other options than imagemagick, you could combine all your steps into a single photoflow preset and use the program in batch mode to process your images.
The command for one tiff file would be rather simple:
photoflow --batch in.tif your_preset.pfp out.tif
The resulting TIFF will be in 32f format, so you will still need to convert it to 8-bit.
I have put a preset that does what you describe above here.
Hi @Carmelo_DrRaw and thank you! The pfp file works perfectly when run on one tif at a time, and saved under a new name. But what I’m trying to do is reiterate over all the tifs with a given pattern for the extension, in all the subfolders of a specified top-level folder. So I tried putting the command into “find” as follows:
does obligingly save to disk a tif named “piper-heidsieck-1.CCE-xcf.tif-1.tif”, which is nice to know, but I don’t want to deal with a new tif. Instead I want the original tif overwritten.
@afre’s advice to save the resized tif under a new name so the two files can be compared of course is very sound advice in general. But in the current use case I want to resize approximately 1000 tifs in a folder with a lot of subfolders. The original files for comparisons aren’t the tiffs but rather the XCF files from which the tiffs were exported using a GIMP python script.
Well, actually, reading through the php file, probably the php preset won’t work with anything except square input files, which my test file happened to be. My goal is to resize the images to have a maximum dimension of 1024px, but preserve their original aspect ratios. So I guess imagemagick will have to do. Sigh - back to testing to figure out how to convince imagemagick to not “gamma correct” the original tifs.
No, the scale operation takes maxW and maxH as parameters. Therefore, setting the size to 1024x1024 pixels means that the resized image will have the largest dimension equal to 1024 pixels at most, the other dimension being scaled proportionally. If the image is smaller than 1024px, it will not be resized.
Photoflow does not support reading and writing to the same image file. However, you could wrap your command inside a small $HOME/shrink.sh script, which could look like this:
Hi @Carmelo_DrRaw - the shrink.sh script works perfectly, and executes considerably faster than the imagemagick commands - for some reason the imagemagick command to convert from one profile to the next is very slow. So thank you thank you! I’ll be able to make the resized tiffs for digiKam much more quickly than I had anticipated.
If you are open to suggestions for the resizing algorithm that PhotoFlow uses - it seems to create what I would call “sharpening” artifacts - dark lines around lighter areas and the adjacent lighter areas get somewhat lighter.
It would be great to see GIMP’s nohalo also in PhotoFlow. GIMP’s (actually GEGL’s) “nohalo” rescaling is the best rescaling algorithm I’ve ever seen, imho, and the only rescaling algorithm I actually use on a regular basis.
FWIW, the ImageMagick rescaling (whatever the default is) is actually closer to GIMP’s nohalo than PhotoFlow’s, as measured using GIMP’s “difference” blend mode. But the PhotoFlow rescaled image also is a fractional pixel off from the other resizing algorithms, which makes the difference blend a bit difficult to interpret.
I’m guessing the default IM algorithm uses a variation on GIMP’s nohalo, which originated in coding and testing done by Nicolas Robidoux, which was done in connection with ImageMagick: http://www.imagemagick.org/Usage/filter/
I’m really glad to hear this! I wonder if ImageMagick is multi-threaded… the photoflow script makes use of all the CPU cores you have available.
PhotoFlow uses the default resize algorithm of the underlying VIPS library. If I remember correctly, VIPS used to provide also some version of the “nohalo” algorithm. I will check again if it is still available, and if yes will suggest you how to patch the code to use it. I’m very much interested in comparisons of resize methods!
IM can be slow at higher bit depths. As I implied in another thread, the only way around that is to compile your own custom commands. It makes up for the slowness by giving the user the option to define their own, or customize existing, filters on the fly if you know what you are doing. Don’t underestimate the VIPS library though. I am sure that it is just as capable , if not more so at higher bit depths.
Well, I did read the link, until I got to this paragraph:
Blockquote
Afterwards, the verbose information for the output file lists the colorspace as RGB. This only works on image types containing meta data that distinguishes between linear RGB and non-linear sRGB, such as PNG and GIF. Therefore, if the above command is run with a JPG or TIF output format, the verbose information for the colorspace still shows sRGB. In order to properly have the JPG output know that it is linear RGB, include an appropriate color profile.
Which left me wondering if/how/when the sRGB color space might be somehow associated by Imagemagick with my non-sRGB tiffs, and also wondering how to interpret “include an appropriate color profile”.
Speaking more generally, I don’t enjoy the process of trying to decipher what user manuals and documentation really mean in cases where there is no clear-cut example that gives clues about how to decipher the meaning. It’s OK for car repair manuals which are notorious for being indecipherable unless you already know what the manual means, because the car is right there providing clues as to how to decipher the manual and also clues regarding if/where the manual went completely off the tracks.
But for image processing, there’s just too many variables that might or might not be relevant to figuring out what the documentation really means, if indeed it still really means anything, though in this regard I think the IM devs actually do keep the manual updated with the code.
You can check using info: as you assemble your command. That is what I was trying to show in my previous (edited) post. Also see ImageMagick – Command-line Options.
I definitely agree with your sentiments. I find the IM documentation to be unwieldy as well. There is so much of it in various states of update or overlap, pieces that may not connect with one another and sections that aren’t well-indexed by search engines, etc. I guess you probably get to experience some of that first hand as your own website grows in size and sophistication. As a creator, it is not always easy to be in the shoes of the visitors. E.g., I may have read your articles, but I still ask you naive questions that were technically already answered .
I think that is why I tend not to touch IM nowadays except to experiment or kill time lol.
As for overwriting files, I suppose that if you accept the risks of making mistakes, or unforeseen command or file errors, then it is fine. In one of your articles, I see that you do in-place writing with exiftool as well. Nothing wrong with that.
, if not more so at higher bit depths.
.