Page 1 of 1

Version 7 comments

Posted: 2013-09-18T13:28:22-07:00
by Alan Hadley
I am still developing my Windows program that exposes most of the functionality of IM 7 (and some other libraries two, VTK and open CV). I hope to release a test version when the IM beta is available. I have managed to static link my program, to avoid having to distribute dozens of .dll files.

IM 7 compiles easily with the free Microsoft Visual C++ for windows Desktop 2012, I have it running at 64 bits high dynamic range, Microsoft even lets you use the Open MP library in this version of the compiler. You just can not compile programs that need MFC.

My first problem with IM 7 is a minor annoyance. Using the 'Draw' function the 'stroke-opacity' is set to zero by default, so to draw say a white line you need to do something like "stroke white stroke-opacity 1 line 0,0 50,50" when I would have thought it more natural to do "stroke white line 0,0 50,50".

My second problem is a bit more tricky to pin down. There seems to be an issue when resizing a small image when there are more than 4 channels which also shows up in the clear areas of a copy where a mask was in an original image. It shows up as not quite random patterns of dots and lines.

I am sorry for bothering you if you know about these things.

BTW the various speed ups you have done so far are appreciated I can zoom in and out and move around on two images simultaneously and smoothly. I just get a bit of jitter when freehand drawing with a big brush with feathered edges etc. but I am asking the pc to do a lot with that one.

Alan

Re: Version 7 comments

Posted: 2013-09-18T23:48:32-07:00
by Alan Hadley
Since writing my original post I think I have worked out what is going on with the random pixels.

When a new image is created from a source image that has a Read mask first a memory buffer is allocated for the destination image, this is not initialized so may contain anything. Actually in debug mode all buffers are initialized, I do not see any problem in this mode only in Release mode.

Now the pixel source is the unmasked area of the source image, these pixels are manipulated then placed in the destination image. This still leaves areas of the destination which have not been initialized, i.e. those corresponding to the masked areas of the source.

there are three possible solutions:-

1. Initialize the whole destination image to zero or the background colour before copying.

2. When copying fill every pixel either with one derived from the source or a background/zero value.

3. Copy the whole source, modified if necessary, then reset pixels that correspond to the masked areas in the source.

I have not looked at the code so I do not know which method would be best.

p.s. ignore the bit about small images I realize that small images will probably be allocated small areas of memory that have been used before, while larger images will be placed in fresh areas which were set to zero when the program started up.

Alan

Re: Version 7 comments

Posted: 2013-09-19T00:02:28-07:00
by dlemstra
Your first problem sounds like a bug to me, the stroke-opacity should default to 1 in IMv7. I will look into it.

Re: Version 7 comments

Posted: 2013-09-23T16:41:22-07:00
by dlemstra
I just committed a fix for the issue with the stroke color. Can you post an example of the command you are executing for your second problem? And an input image so we can reproduce your problem?

Re: Version 7 comments

Posted: 2013-09-24T07:50:19-07:00
by Alan Hadley
I am using the Magick Core functions so I do not have a script but I have done a bit of digging in the IM code, and tried a very crude patch to test my theory and it seems to work.

in the file "transform.c" is the function I tested "ExcerptImage", several other functions have a similar problem.

Code: Select all

      if (GetPixelReadMask(image,p) == 0)
        {
          p+=GetPixelChannels(image);
          q+=GetPixelChannels(excerpt_image);
          continue;
        }
the above code skips writing anything to the output image when there is a Read Mask. But I believe this function and others such as "CropImage" start with an uninitialized canvas so that what ever rubbish is at the skipped locations will be retained in the output image. I tried writing zeros to the skipped locations and the problem went away, but a better solution might be to use the source image background colour.

I hope this helps.

Alan Hadley

Re: Version 7 comments

Posted: 2013-10-09T04:47:04-07:00
by Alan Hadley
I have downloaded and linked to a recent version of IM7 and both of my problems seem to have gone away, thank's.

Alan

Re: Version 7 comments

Posted: 2013-10-09T06:33:36-07:00
by magick
We can reproduce the problem you posted and will have a patch in ImageMagick 7.0.0-0 Alpha within a few days. Thanks.