Using the command line version of G’Mic (gmic-cli-2.4.1-win64) on Windows 7 to read a file, resize it using the scale_dcci2x option, and output a new file:
Resizing using a jpeg for input and output works as expected.
Resizing using a tif for input and output, something bizarre happens. While Irfanview shows the file as I expect it to be, both GIMP and Rawtherapee show a bastardized version of the image - as shown below.
If I open the tif with IrfanView and then save it, all is good and both GIMP and Rawtherapee correctly read the file.
So does anyone know what it is about G’Mic and tifs that causes programs (RT, GIMP, Photoshop, Vueprint, Windows Photo Viewer,) to not like the tif? Note that LibreOffice Draw won’t even open the file throwing an unknown image format error.
What is your G’MIC command? Could you tell me the properties of your input TIF? It could be a number of things including the ICC (which G’MIC ignores), bit depth, datatype, etc.
Maybe some info about this.
I don’t know what version of G’MIC you are using, but for a long time, G’MIC has saved .tiff files by default in the float-valued format (this is possible to do that in TIFF).
Unfortunately, some software assume that in the case of float-valued TIFF files, the value range is normalized in [0,1], which makes TIFF files saved with a range [0,255] (as G’MIC does) very bright when opened.
G’MIC does not renormalize the pixel values before saving into a TIFF file (it wouldn’t really make sense, as G’MIC just deal with an array of number, it does not even know what the numbers represent, and it could be something else than RGB values).
The good news, is that in more recent versions, G’MIC tries to automatically guess what is the best datatype it can use to save a TIFF, so if your image values stay integers in [0,255], it will save the TIFF in the uchar8 format (which is read correctly by GIMP if this is a RGB image).
I believe that David’s reply about G’MIC operations is the key. Recall that with the original command the tif that was produced showed as almost pure white while LibreOffice Draw generated an unknown image format error and wouldn’t open the image.
Using either of the above two commands created a tif that LO Draw opened and which displayed correctly in GIMP, Photoshop, etc.
Just note that, if you’re using tiff to retain bit depth, uchar is only giving you 8-bit values. ushort should give you 16-bit values, and still be readable by most softwares.
@ggbutcher, well in that case also it’s a bit tricky, because G’MIC is able to output a 16bits-integer TIFF file, but if you have an image (float-valued) in G’MIC, with values in range [0,255], and save it directly with -output file16bits.tiff,ushort, then the pixel values will be rounded to integers and keep the same value range of [0,255], resulting in a very dark image when the file is opened in GIMP
Here again, there are no reasons G’MIC should normalize the pixel values automatically, it just see the TIFF file as a container to store the array of pixel values, and keep thus the same value range.
If the user knows he is dealing with RGB images in range [0,255], then he has to multiply the pixel values by 257 before saving to a 16bits TIFF with values that will be read as “correct” RGB colors in other programs.
$ gmic sp lena blur 2 mul 257 o file16bits.tiff,ushort
Ah, caught me in another bad assumption about data ranges. Can’t fault the logic.
It took me a bit to find out the 0.0-1.0 convention for floating point images, seemed to me most felt all should just know that. Now that I do know that, I’m assuming it should be standard…
The artifacts are not present if the output is to a jpeg file. I’m guessing this has something to do with how the pixel values are processed when writing out to the tiff file.
