compose blending different with cropped image, why?

[fmw42]

OK, I did my tests and get the same result as you. Then I looked at the verbose info: using IM (convert image -verbose info:). The differences are mainly two places (apart from color differences due to the different subsections selected)

First Preview adds a fully opaque alpha channel and PS does not. So I tried disabling the alpha channel. That did not work.

Second and more important. PREVIEW by default saves the image as generic RGB and PS saves it as sRGB. So in Preview, after cropping and before saving as PNG, I added an sRGB profile. Then saved as PNG. With that it works to give the same sort of looking compare image as the PS cropped image. The original image.jpg has no profile.

I am not sure whether this is a bug in compare or just the result of two different colorspaces. I suspect the latter, but am not sure.

The IM developers would have to comment on this.

[anthony]

I am not sure whether this is a bug in compare or just the result of two different colorspaces. I suspect the latter, but am not sure.

The IM developers would have to comment on this.

Compare does not do anything with colorspace (IM generally doesn't, at least in IMv6) As such to get any meaningfull comparision somehow the two images needs to be placed in the same colorspace.

ASIDE: for IMv7 I'd like some formats to 'assume' certain colorspaces (EG: GIF, PNG without any profiles, and JPEG without profiles). But that is another discussion topic.

Hmmm. Fred. you say for the 'preview' crop you added a sRGB profile before saving, and then "compare" was able to give meaningful reasults. Do you know when the color values were changed? That is was it by 'preview' when it was saving, or was it by IM "convert" as the coder was reading?

[fmw42]

Hmmm. Fred. you say for the 'preview' crop you added a sRGB profile before saving, and then "compare" was able to give meaningful reasults. Do you know when the color values were changed? That is was it by 'preview' when it was saving, or was it by IM "convert" as the coder was reading?

I believe it is when IM reads the image as the images looks the same when displayed. Here are the 3 crops from the watermarked image.

PS Crop (sRGB profile):


Preview Crop (RGB profile):


Preview Crop (sRGB profile):



Here is the pre-watermarked image so you can do your own compare.


See his commands and his results at the bottom of the previous page.

[glennrp]

identify -verbose tells me that copy.png doesn't have offset information,
but both of the out*.png have oFFs chunks containing the cropping offset.

[fmw42]

identify -verbose tells me that copy.png doesn't have offset information,
but both of the out*.png have oFFs chunks containing the cropping offset.

I expect that is coming from the way compare creates the first output image showing the differences in the small image relative to where it matches in the larger image