regression

[fmw42]

Well if you are using the same current version of IM 6.5.5.-9 and it is installed correctly and there are no other versions still on your system to confuse things, then something is odd.

At this point, then if you cannot use my command and generate the same result in Windows that I am in Unix (Mac), then you will have to take that up further with the IM folks. It is beyond me as it seems to work fine for me.

Perhaps some other Windows user can test it on their system to verify if it is a general Windows problem or just something odd with your install.

[perl@nevcal.com]

Presently using 6.5.5-8. I had also installed a couple other versions, until with your and Anthony's suggestions, I could figure out a simpler command to achieve my goals with the 6.5.5-8 version.

So I'll uninstall all versions, and grab this newest one, and see what happens.

[fmw42]

please post your final command line that works and the result you get, so we can see what now is the best solution.

[perl@nevcal.com]

I uninstalled every version of ImageMagick I had on the machine, and verified that there were no ImageMagick* directories in %ProgramFiles%. Then I installed version 6.5.5-9 Windows binary freshly downloaded.

I used the original command at the top of the thread:

convert.exe -density 150 -size 1159x1515 xc:white -compose multiply ( in.jpg -repage 1159x1515+0+0 ) -compose multiply -flatten ( in.jpg -repage 1159x1515+409+765 ) -compose multiply -flatten -compress zip out.tif

And still got the doubling effect, and the output as posted at http://nevcal.com/temporary/out.tif

So it seems that recent versions of ImageMagick have changed behavior with respect to -size and loading .jpg files. Anthony had a theory about that on the mailing list, but seemed to imply it was an old feature, but this seems like a new behavior to me, for this command works with older versions, and fails with the latest version. All Windows versions here. The fact that it works for you on Unix implies that there is some cross-platform difference.

Hopefully some IM developer can find and explain this phenomenon.

[fmw42]

I am puzzled as you continue to use the same potentially erroneous command. Did you not have discussions with Anthony on the Magick Users Forum about this and came up with a version that works. Or is someone else having the same problem. I thought from the discussion on the other forum and your message above that you found a command that now works the way you want it. Am I wrong? Please clarify.

I am sorry if no one can make your old command work the way you want, but I think it is erroneous (having an extra -compose multiply with only one image before it and no -composite or -flatten after it. Perhaps I am missing something, but I don't see how that can possibly work. If it did, it was because with the very old version of IM, you just got lucky. It may have skipped things that were in error and just processed what it could. IM is a work in progress and the IM folks work very hard to improve things and to fix problems. Sometimes that means that things are deprecated or get fixed to work the way the really should.

I gave you a solution that worked for me on the current IM version. If my solution or Anthony's does not work for you then you should take that up with Anthony or Magick as perhaps there is something wrong with your environment. I am no system expert on unix or windows. So I cannot help much here. But to insist on using your original approach when others such as Anthony have given you a solution that works, seems pointless to me. I suggest you work to find an optimal solution that works properly on your current environment and possibly even on your old environment and give up your current command. There are many ways to 'skin the cat'.

I apologize if this is not what you want to hear or if my information regarding the Magick User's Forum is erroneous. But I guess at this point I cannot help any further and will leave it up to you and the IM folks.

[perl@nevcal.com]

Hi Fred,

I do appreciate your help, but I would like someone to help that can actually fix the bug.

I agree that my (old) command contains extraneous items that could be eliminated, and thanks to you and Anthony, I will be using more streamlined commands in my actual software. My software no longer encounters this issue, but the bug still exists.

You seem to believe that there is something "wrong" with my command... if there is, then it should produce an error. However, since instead it produces one output when you and Anthony run it on Unix, and a different output when I run it on Windows, then there is a bug, somewhere.

I may not understand fully, but the things you described as being wrong with my command, Anthony seemed to refute them as being wrong. The most serious thing "wrong" with my command was an extraneous -compose multiply. Another inefficiency is the creation of the background canvas, when that could be done implicitly... but inefficient command should still function correctly.... but this one doesn't, on Windows.

You may not be interested in having that bug found and fixed, but it seems to me that if I encountered it, and had problems with it, that others might also... so I like to see the bugs found and fixed.

Clearly there is a difference between Unix and Windows output, for the same command in the same version, and clearly there is a difference between Windows 6.4.x and 6.5.5 for the same command. That makes it seem like 6.5.5 has introduced a bug, or fixed a bug that hasn't yet been fixed on Unix.

If this is a feature, it is a very obscure feature, because portable software should function the same on all of its platforms.

Since you are the only one that has responded on this thread, no one on the development team has, I'm not sure what else to do. This is the bugs forum, and I've reported what appears to be a bug, and I will continue to be the "last responder" in this thread to make it clear that the bug exists, and has not yet been resolved, until it is resolved.

[fmw42]

Well I will leave it to you to take this up further with the IM folks as a bug. And you can repeat your note following this message. But I will suggest one other thing to try on a new command to see if that works in Windows and helps your problem. On my Mac it produces the same (good?) result as your original command (which I do not understand) and my previous commands which seemed to work for me but not you. So if you want try this.

convert -respect-parenthesis \( -size 1159x1515 xc:white \) \
\( -page +0+0 in.jpg \) \( -page +409+765 in.jpg \) \
-compose multiply -flatten -density 150 -compress zip out3.tif

As I recall, -size can affect the reading of jpeg files. So perhaps using -respect-parenthesis (which won't be available for your old system) and parens with -size, might restrict it so that it reads your jpgs properly.

The other thing to suggest is, just for testing, if you convert your jpg files to png or tif and see if your original command has problems. that will tell if it has to do with -size affecting the reading of the jpgs vs other formats that it is not tuned for.

It would also be nice if someone on Windows could test your original command and my commands to see what they get to verify that it some change or difference between Windows and other Unix systems. That would help the IM folks verify this as a bug or not.

[magick]

This command produces the correct identical output under Linux:

• convert -density 150 -size 1159x1515 xc:white +size -compose multiply \( in.jpg -repage 1159x1515+0+0 \) -compose multiply -flatten \( in.jpg -repage 1159x1515+409+765 \) -compose multiply -flatten -compress zip out.tif

and Windows:

• convert -density 150 -size 1159x1515 xc:white +size -compose multiply ( in.jpg -repage 1159x1515+0+0 ) -compose multiply -flatten ( in.jpg -repage 1159x1515+409+765 ) -compose multiply -flatten -compress zip out.tif

The -size option is a global setting. The +size option removes the previous setting of 1159x1515 which is required so it does not affect the size of the JPEG image. The -size option permits the JPEG delegate library to subsample the image for us, however in this case it is super-sampling.

Its certainly possible that in the past the +size option was not required. However, we would consider that a bug and believe that recent releases of ImageMagick is behaving as it should.

[perl@nevcal.com]

Thanks Fred, and Magick. I lost a big response to Fred because this forum timed me out and made me login in again... and lost my post on the way

But with the additional information by Magick (I also discovered the command he suggested while writing my reply to Fred), it seems that it would be extremely helpful to enhance the documentation in one or more of these areas:

This page: http://www.imagemagick.org/script/comma ... essing.php mentions that -size is an image setting that persists until reset. But it doesn't explain there (or anywhere I could find) how to reset them.

This page http://www.imagemagick.org/script/comma ... ptions.php describes the -size option in particular. It doesn't, however, mention its effect on reading JPEG files, nor does it mention how to reset it, nor is there a separate entry for +size, which is mentioned at http://www.imagemagick.org/Usage/formats/#jpg_read

Is there a way to submit patches to the documentation, that doesn't take hours to learn, or is the above description sufficient?

I can consider that the change in behavior between earlier versions and current versions of ImageMagick on Windows could be a bug fix, but I am still surprised that Fred and Anthony couldn't produce the same results with my originally posted command. It seems that there must still be a bug or deficiency on the Unix side, because of the discrepancy.

[anthony]

In the IM Mailing list where this discussion also rages. The problem was discovered.


It is the use of -size by the JPEG reading code that is causing the problems.

-size give a hint to the JPEG reading library, causing it to produce a image of a different size than expected.

I think it may be time to remove this effect of -size as it continually pops up and causes confusion. Even to me!!!! I suggest the JPEG input size hinting be
relegated to a codec '-define' option, instead.

[magick]

Done. Look for a patch in ImageMagick 6.5.6-0 Beta by sometime tomorrow.

[anthony]

Okay I see the change.

JPEG image size hint is now handled by -define jpeg:size={size} and NOT by -size.

this change will be as from the release of IM version 6.5.6-0