[bash] Problem when overlaying two images : result is darker

[swiss_knight]

Hi everybody,

I'm trying to overlay two *.jpg images;
The first one is a photo.
The second is created within IM by using a convert command with -sparse-color over a series of RGB values and X,Y coordinates.
This second image is bigger (higher and wider).

Using bash, I tried to place the photo over the second image (and store the results in the same file as the photo), with this command :

Code: Select all

composite -gravity northwest -geometry +20+20 "${photo_path}" "${sparse_color_image_path}" "${photo_path}"

but the result is significantly "darker" than the original picture.

And when using Dst_over ;

Code: Select all

composite -compose Dst_over -gravity northwest -geometry +20+20 "${sparse_color_image_path}" "${photo_path}" "${photo_path}"

the photo is OK (it looks exactly the same as the original), but, as the bigger image is no more the destination image, the result image is cropped to the size of the "smallest", i.e. the photo. Which is not what I want.
But the colours look right with this method.

I can't figure what is wrong with such a simple composite command, neither why there is a difference between these two methods.
(And as I don not know if this is a bug, I posted this message in the main user cat)

Any help would be appreciated.
Thanks a lot !

(I am using Ubuntu 12.04 with ImageMagick 6.6.9-7 2012-08-17 Q16 (simply, the repository version) ).

[snibgo]

Without seeing the images, it's hard to diagnose.

Ubuntu uses an ancient version of IM. An upgrade might cure the problem.

[swiss_knight]

Hi Snibgo,
thanks for the answer.
Before uploading all the pics, do you have any clue on "how" I can upgrade IM ?
Is there any official PPA that I missed, somewhere ? Or any deb package ?

Thanks again.

[snibgo]

I no longer use Ubuntu. Try:

http://www.imagemagick.org/script/binary-releases.php
http://www.imagemagick.org/script/install-source.php

[fmw42]

Just post a link to your two input images and the resulting output. It is likely a colorspace issue. Your version was right in the middle of all the colorspace changes. Often the correct placement of -set colorspace RGB or -set colorspace sRGB will help. You also should use convert and not composite.

see
http://www.imagemagick.org/Usage/compose/#compose

[swiss_knight]

Hello again.
(Minimal working example below)

Ok, so, I have removed the installed IM version with :

Code: Select all

$ sudo remove --purge imagemagick 

before re-installing it, after downloading it from a mirror here : http://www.imagemagick.org/script/download.php , with these commands on the extracted files :

Code: Select all

$ cd IMDirectory
$ ./configure -disable-shared
$ sudo make
$ sudo checkinstall
$ cd ..
$ sudo rm -rf ImageMagick-6.8.5-6/
$ sudo reboot

And the problem persists.

Here are some small example pictures :
1. The original image ( test.jpg ):
http://image.noelshack.com/fichiers/201 ... 6-test.jpg
2. The "created" image with -sparse-color ( sparse_color.jpg ) that will serve as background :
http://image.noelshack.com/fichiers/201 ... -color.jpg

I ran exactly this simple command from the directory where the two previous images are stored :

Code: Select all

composite -gravity northwest -geometry +10+10 test.jpg sparse_color.jpg test2.jpg

3. And it gave me this result image ( test2.jpg ) :
http://image.noelshack.com/fichiers/201 ... -test2.jpg

4. And if I run this :

Code: Select all

 composite -compose Dst_over -gravity northwest -geometry +10+10 sparse_color.jpg test.jpg test3.jpg

test3.jpg is just exactly the same image as the original test.jpg.

I am not 100% sure that it is strictly related to IM, because even the thumbnail of the original image ( test.jpg ) in Nautilus ( i.e. the default files explorer in Ubuntu ) seems to be as dark as the result image ( test2.jpg ).
But if I open this picture ( test.jpg ) in the gnome image viewer or in The Gimp, it's ok ; colours are clearer. As I hope you can also see it.
I guess there must be an issue somewhere regarding some kind of "embedded colours informations" ( I am not very comfy with these notions yet )...

Thanks again for your precious advices !

[snibgo]

"identify -verbose test.jpg" tells me your test.jpg contains a profile named "Darktable linear RGB".

I can convert it to sRGB with:

Code: Select all

convert test.jpg -profile sRGB.icc tx.png

(where sRGB.icc is a file in my current directory).

Thus:

Code: Select all

convert sparse_color.jpg ( test.jpg -profile sRGB.icc ) -gravity NorthWest -geometry +20+20 -composite st.jp

[fmw42]

Your green image has a Dark RGB profile that is causing the trouble. I do not have that profile to be able to convert to sRGB (which is the colorspace of the sparce-color image), so I have to do an approximation, by removing the profile, tell the image that it is RGB and then converting to sRGB. So the following works for me on my IM 6.8.5.6 Q16

convert 1368998895-sparse-color.jpg \( 1368998776-test.jpg -strip -set colorspace RGB -colorspace sRGB \) -gravity center -compose over -composite result.jpg

On my 6.6.9.10 system, you have to do the opposite since RGB was really sRGB and vice-versa, prior to the colorspace change. So this works for me


convert 1368998895-sparse-color.jpg \( 1368998776-test.jpg -strip -set colorspace sRGB -colorspace RGB \) -gravity center -compose over -composite result.jpg

[snibgo]

Your green image has a Dark RGB profile that is causing the trouble. I do not have that profile ...

You can easily get it...

Code: Select all

convert test.jpg xx.icc

... although I don't think it's needed for a conversion to sRGB, at least on modern versions of IM.

[snibgo]

I am not 100% sure that it is strictly related to IM, because even the thumbnail of the original image ( test.jpg ) in Nautilus ( i.e. the default files explorer in Ubuntu ) seems to be as dark as the result image ( test2.jpg ).
But if I open this picture ( test.jpg ) in the gnome image viewer or in The Gimp, it's ok ; colours are clearer. As I hope you can also see it.
I guess there must be an issue somewhere regarding some kind of "embedded colours informations" ( I am not very comfy with these notions yet )...

Yes, many image viewers ignore embedded profiles.

To test this, I use an image with an extreme profile, such as:



https://dl.dropboxusercontent.com/s/w7i ... DrXz14BlvA

This image has the word "red" in red and the word "blue" in blue, on a white background. If "red" is green and "blue" is dark red, your viewer (or browser, etc) is ignoring the embedded profile.

[anthony]

Nice test.

Web browsers display it using the embedded profile, but many simplier image display programs do not.

Note IM "display" program does not, and this is on purpose as by default we need to see image data as-is, without
profile or other interference.

however doing...

Code: Select all

display -profile ..../sRGB.icm   redBlue.png

does make it display correctly.


Note however that this probably does not work for a gamma defined linear-grayscale image!

[swiss_knight]

Hi again,

Ok, thanks for all your answers ! I had a great time...
Now working with IM : Version: ImageMagick 6.8.5-6 2013-05-19 Q16

So...
1. Snibgo :

Code: Select all

convert test.jpg -profile sRGB.icc tx.png

This command seems to need a file called sRGB.icc.
I haven't found such a file on my Ubuntu, so I picked one from an old Windows installation with almost the same name, but with an icm extension.
Then I tried... The result image is clearly clearer, good !
But it's a bit more "yellowish" than the original. I hope you understand and agree that one cannot afford such colour deviation on photos, except maybe on a field of dandelions...

2. fmw42 :
Exactly the same here : a yellowish tint appears on the result image.

3. Snibgo again :
By doing this :

Code: Select all

convert test.jpg xx.icc

I have extract "something" called xx.icc
(I really don't know what kind of information is contained in an ICC profile, nor "how" one can "see" these informations, anyway...)
After that I have tried using this icc profile as before :

Code: Select all

convert sparse_color.jpg \( test.jpg -profile "xx.icc" \) -gravity northwest -geometry +10+10 -composite test22.jpg

and the image is as dark as with no profile specified. I don't get it.

I have several questions on my mind at this stage ...
- I understand IM is treating pictures without looking if it really contains some profile or not...
Thus, as Anthony said, we are dealing with the original raw data.

Ok, knowing that, I have 2 ideas in mind :
1. Using the Dst_Over option. As told in my first post.
But as the "source" image is no more the the original photo but the sparse_color.jpg file, I lose all the metadata (EXIFS, etc). (And by losing the embedded ICC informations, the colours are fine on the result image, if I'm not wrong).
So, is it possible to "copy" all the metadata from the original photo to the sparse_color.jpg file before overlaying them (or to the final output file after execution of the overlaying) ?
And how do I tell the photo to get a transparent border to reach exactly the same size as the sparse_color.jpg file so that I do not lose the borders in the result ?

or 2. Trying to find out what's is "wrong**" (maybe it's before using IM, I don't know yet) to make IM taking into consideration the right profile so that the script stays universal. I.e. I need to treat several pictures taken with different cameras, or post-processed within different softwares... Without having to tweak the script for each different users files...

Any other good ideas are of course welcome, if any.

** I have observed several strange behaviours within different images viewers and images sources.
For example ; when viewing a "directly-out-of-a-Nikon-camera" jpeg file with "Eye of gnome" (default viewer in Ubuntu) and the same image but "exif-cleared" (with exiftool -all= imagename.jpg) ; the two images are exactly the same in the viewer. But their thumbnails aren't in Nautilus (the Ubuntu files explorer). Their differences are also shown when these images are opened with : The Gimp, Firefox and the display command if IM for example. This was on a Nikon picture...
This behaviour seems to be inverted with a Canon picture... For example, with a such a picture, the display command does not show any differences, but the image viewer does.
It's kinda puzzling... I really have to do some more testing to understand all that clearly...

[fmw42]

IM will use the profile imbedded and convert to any other profile if you use the -profile arguments and the actual profile file. There are many versions of sRGB profiles so it is possible that you might get different results from different profiles. See

http://www.color.org/srgbprofiles.xalter
http://ninedegreesbelow.com/photography ... rison.html

[snibgo]

Code: Select all

convert sparse_color.jpg \( test.jpg -profile "xx.icc" \) -gravity northwest -geometry +10+10 -composite test22.jpg

and the image is as dark as with no profile specified. I don't get it.

Your image already has xx.icc profile applied. Your command would convert it to exactly the same profile, with no effect whatsoever.

There might be mileage in using "SrcOver" instead of "DstOver", and reversing the order of the input files.

or 2. Trying to find out what's is "wrong**" (maybe it's before using IM, I don't know yet) to make IM taking into consideration the right profile so that the script stays universal. I.e. I need to treat several pictures taken with different cameras, or post-processed within different softwares... Without having to tweak the script for each different users files...

You could use the general formula:

Code: Select all

convert in.tif -profile sRGB.icc -strip out.tif

If the input has no profile (presumably because it is already in sRGB space), then "-profile sRGB.icc -strip" will apply sRGB.icc, then immediately remove it, so there is no effect. But if it does have a profile, it will be converted to sRGB.icc, then this profile will be removed. So, in either case, the image should end up in sRGB space.

[anthony]

A copy is installed with ImageMagick

On my system it is at /etc/ImageMagick/sRGB.icc
Another one I found is at /usr/share/color/icc/sRGB.icc, but I can't find the package that installed that, but a google search found a package (fedora) called "shared-color-profiles"

Try using "locate sRGB.icc"

and yes while there are many different types of RGB color profiles. sRGB is defined specifically by the Web Consortium and should be standard.

Other profiles... AppleRGB CIE-RGB NTSC-RGB.icc PAL-RGB
and some that reverses image channel order (like in the above redBlue.png image) : FakeRBG FakeBRG

One that I would like to know more about was called... x11-colors