 |
| GimpChat Member |
 |
Joined: Mar 15, 2014
Posts: 115
Location: Brooklyn, NY
|
A perennial problem: the G'MIC command line interpreter has no training wheels. It will do as told even when that is not what you want. The command line interpreter will dutifully produce out-of-band data because, for all it knows, that is what you want. This is an old post, but the problem is frequent enough to warrant a reply, if only for the benefit of those stumbling in from search engines. Details in these links: 1. G'MIC Basics2. Images as DatasetsKudos to the original poster for providing the command that raised the dust. Let's run it - but with a twist. Lets insert the -display command just before the -outputand see what G'MIC furnishes for diagnostics ( -display and -print are your friends. They print the diagnostics): gosgood@bertha ~/git_repositories/gmic-community $ gmic sample lena,earth +transfer_pca[0] [1] -display output[2] test.png
[gmic]-0./ Start G'MIC interpreter.
[gmic]-1./ Input sample image 'lena' (1 image 512x512x1x3).
[gmic]-2./ Input sample image 'earth' (1 image 500x500x1x3).
[gmic]-1./ Transfer mean vector and covariance matrix from image [1] to image [0], for channels 'all'.
[gmic]-3./ Display images [0,1,2] = 'lena, earth, lena_c1', from point (256,256,0).
[0] = 'lena':
size = (512,512,1,3) [3072 Kio of floats].
data = (225,225,223,223,225,225,225,223,225,223,223,223,(...),78,78,78,77,91,80,79,89,77,79,79,82).
min = 8, max = 251, mean = 128.241, std = 58.9512, coords_min = (457,60,0,1), coords_max = (425,20,0,0).
[1] = 'earth':
size = (500,500,1,3) [2929 Kio of floats].
data = (0,0,0,0,0,0,0,0,0,0,0,0,(...),0,0,0,0,0,0,0,0,0,0,0,0).
min = 0, max = 251, mean = 88.101, std = 69.4635, coords_min = (0,0,0,0), coords_max = (302,262,0,1).
[2] = 'lena_c1':
size = (512,512,1,3) [3072 Kio of floats].
data = (140.796,140.796,136.765,136.765,140.796,134.542,140.796,135.207,140.796,135.207,136.765,135.207,(...),25.6989,25.6989,25.6989,32.2462,60.2642,44.7455,45.8603,63.4888,49.3811,55.3046,55.3046,61.011).
min = -69.4026, max = 272.318, mean = 88.101, std = 69.4635, coords_min = (457,60,0,0), coords_max = (289,76,0,2).
With G'MIC's processing log in hand, some technical aspects of the output have been given to us. The most salient one is the minimum and maximum values of the last image's pixels - lena_c1. There are some pixels with values less than zero - "blacker than black!" Neither .jpg nor .png nor most of the popular image formats can deal with negative numbers. The output is not empty, but it is not right either, at least with respect to popular image formats. Depending on what software is used to view the file, it may show up as black - seemingly empty - or strangely posterized. So why is G'MIC so lame? Doesn't it know anything about JPEG?? It does. But it is not going to attempt to second guess you. People involved in image processing HATE - I mean, really, REALLY, HATE - software second guessing their purposes and injecting unasked for behavior into their workflows, and that is the crowd that G'MIC has been designed for. Because G'MIC does not regard itself as competent to hold your hand in any way, you will need to spend a good deal of time thinking your way through image processing problems. Get past that, and you find yourself with a package that does not limit you in any way - especially with poorly timed, misdirected "help." Fortunately, there is help. It's years away from being complete help, but it is a start. Follow the Basics link for an introduction to G'MIC - and why it has the attitude it does. Good luck and have fun.
|
|
Login
Register
Tweets
FAQ
Advanced Search
