When the virtualpixel is transparent for displace operator, Image pixels are transparent and virtual pixels are black. The correct result should have virtual pixels transparent and image pixels showing the image pixels.
I expect that the complaint is about ugly black fringing around the displaced image content. The 'transparent' color is transparent black so it does have a color. I believe the problem is due to how the existing InterpolateViewColor() code (which creates a blended target pixel based on the relative contribution of four source pixels) is functioning. Some other similar algorithms have received changes so that transparent pixels do not contribute any color. This algorithm should have similar updates.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually problem is not the black fringing around image content. There is no image content at all. Did you compare Expected result (CorrectResult.png) and current output (CurrentResult.bmp). I attached them here in this bug report. In the current output all image pixels are transparent and there is no image content at all.
I will attach them here again:
Firefox, GraphicsMagick, and ImageMagick, are displaying your CurrentResult.bmp just fine. Probably it is a problem with some readers not knowing how to read BMPv3 format. Obviously Firefox 26 does but the software SourceForge uses for creating a thumbnail does not.
Try this (prefix output filename with 'bmp2:') and see if it works better for you:
You are right. It was something to do with the format. I was using preview on Mac to see the Image. I saved in to png that solved the problem.
Now, I can see the black fringing around the image. You said this algorithm is going to have update. Just wondering, when you are planning to fix this.
Firefox, GraphicsMagick, and ImageMagick, are displaying your CurrentResult.bmp just fine. Probably it is a problem with some readers not knowing how to read BMPv3 format. Obviously Firefox 26 does but the software SourceForge uses for creating a thumbnail does not.
Try this (prefix output filename with 'bmp2:') and see if it works better for you:
Status: open
Created: Mon Feb 10, 2014 04:18 PM UTC by sara shafaei
Last Updated: Tue Feb 11, 2014 03:46 PM UTC
Owner: Bob Friesenhahn
When the virtualpixel is transparent for displace operator, Image pixels are transparent and virtual pixels are black. The correct result should have virtual pixels transparent and image pixels showing the image pixels.
The contents of this message, together with any attachments, are intended only for the use of the individual or entity to which they are addressed and may contain information that is confidential and exempt from disclosure. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this message, or any attachment, is strictly prohibited. If you have received this message in error, please notify the original sender immediately by telephone or by return E-mail and delete this message, along with any attachments, from your computer. Thank you.
This seems to be a problem with the reader used to look at the BMP output file. Using BMPv2 seems likely to fix the problem with the broken reader. Closing this issue as not actually a bug. We can re-open if there is somehow a bug.
Thank you very much for helping to educate me on the displace displace algorithm.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You are right. It was something to do with the format. I was using preview on Mac to see the Image. I saved in to png that solved the problem.
Now, I can see the black fringing around the image. You said this algorithm is going to have update. Just wondering, when you are planning to fix this.
Thank you so much,
~Sara
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You are right. It was something to do with the format. I was using preview on Mac to see the Image. I saved in to png that
solved the problem.
Now, I can see the black fringing around the image. You said this algorithm is going to have update. Just wondering, when you
are planning to fix this.
I have a demanding day job which has nothing to do with image
processing. It will get fixed when I have the time and mental energy
to work on it. Luckily the algorithm is well isolated to just one
small function.
Status: closed-invalid
Created: Mon Feb 10, 2014 04:18 PM UTC by sara shafaei
Last Updated: Wed Feb 12, 2014 05:43 PM UTC
Owner: Bob Friesenhahn
When the virtualpixel is transparent for displace operator, Image pixels are transparent and virtual pixels are black. The correct result should have virtual pixels transparent and image pixels showing the image pixels.
The contents of this message, together with any attachments, are intended only for the use of the individual or entity to which they are addressed and may contain information that is confidential and exempt from disclosure. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this message, or any attachment, is strictly prohibited. If you have received this message in error, please notify the original sender immediately by telephone or by return E-mail and delete this message, along with any attachments, from your computer. Thank you.
The issue with pixel interpolation is similar to the previous issue with image shear/rotation. I have attached a patch to remove the black artefacts generated from images with fully transparent backgrounds that are transformed with an operator requiring pixel interpolation such as displace.
The approach is to compute the pixel area for each of the four pixels that form the interpolated pixel but use an area of zero for any pixel that is fully transparent as a fully transparent pixel must not contribute colour information regardless of its red, green or blue values. If all pixels are fully transparent then set the red, green and blue colours to zero. Otherwise, sum the percentages of red, green and blue components that make up the interpolated pixel. Percentages are computed as the individual pixel area over the total pixel area.
I have attached the displaced bird image before and after the interpolation fix. An image compare shows only differences at the edges of the displaced image.
I had a close look at the changes to InterpolateViewColor() from the head of the mercurial repository and I can see that the patch doesn't fix the issue. Indeed generating the bird displacement image with that version of gm yielded the same image as before the patch. This is what I would expect because setting a fully transparent pixel's primary contribution to zero is the equivalent of treating it as a black pixel which is what was happening in the first place.
Consider the following example where p[0] is white and not fully transparent, and p[1], [2] and p[3] are fully transparent (assume Q16):
Since the only pixel that isn't fully transparent is p[0] you would expected the interpolated pixel to be the colour of p[0] with the opacity interpolated as per the current calculation in the code.
The solution is to make a pixel's contribution equal to its area divided by the total area of all non-fully transparent pixels. Take a look at the patch I posted above. That patch doesn't have the check for matte that your patch does and isn't as cleanly written but gives the general idea.
Cheers,
Troy Patteson
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, I was not terribly happy with my fix, which is why I said "May
not be the final solution" in the ChangeLog.
The solution is to make a pixel's contribution equal to its area divided by the total area of all non-fully transparent
pixels. Take a look at the patch I posted above. That patch doesn't have the check for matte that your patch does and isn't as
cleanly written but gives the general idea.
A patch did not make it through via email and I am not sure how to
find it. Where can I find your patch?
Bob
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Glad you asked as I just discovered an issue with bracket placement in my patch. Attached is another version. At the very least you will need to add the check for matte which it doesn't include and perhaps there is a better way to format it.
Glad you asked as I just discovered an issue with bracket placement in my patch. Attached is another version. At the very
least you will need to add the check for matte which it doesn't include and perhaps there is a better way to format it.
Ok. I found your patch. I had to go to a second page.
I will look at your patch tomorrow.
There is perhaps a bit more jaggies on the edges but without the
darker fringing.
I replaced my temporary implementation with Troy's patch plus improvements to deal with when the image does not support transparency or the opacity channel contains something else such as Black. The results look really stellar now.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here is the command:
gm composite map.bmp bird.bmp -matte -background transparent
-virtual-pixel constant -displace 100x100 out.png
map.bmp and bird.bmp are attached
I expect that the complaint is about ugly black fringing around the displaced image content. The 'transparent' color is transparent black so it does have a color. I believe the problem is due to how the existing InterpolateViewColor() code (which creates a blended target pixel based on the relative contribution of four source pixels) is functioning. Some other similar algorithms have received changes so that transparent pixels do not contribute any color. This algorithm should have similar updates.
Actually problem is not the black fringing around image content. There is no image content at all. Did you compare Expected result (CorrectResult.png) and current output (CurrentResult.bmp). I attached them here in this bug report. In the current output all image pixels are transparent and there is no image content at all.
I will attach them here again:
Firefox, GraphicsMagick, and ImageMagick, are displaying your CurrentResult.bmp just fine. Probably it is a problem with some readers not knowing how to read BMPv3 format. Obviously Firefox 26 does but the software SourceForge uses for creating a thumbnail does not.
Try this (prefix output filename with 'bmp2:') and see if it works better for you:
~~~~~~~~~
gm composite map.bmp bird.bmp -matte -background transparent -virtual-pixel constant -displace 100x100 bmp2:output.bmp
~~~~~~~~~~~
Bob
You are right. It was something to do with the format. I was using preview on Mac to see the Image. I saved in to png that solved the problem.
Now, I can see the black fringing around the image. You said this algorithm is going to have update. Just wondering, when you are planning to fix this.
Thank you so much,
~Sara
On Feb 11, 2014, at 9:20 PM, Bob Friesenhahn bfriesen@users.sf.netamp#98;amp#102;amp#114;amp#105;amp#101;amp#115;amp#101;amp#110;amp#64;amp#117;amp#115;amp#101;amp#114;amp#115;amp#46;amp#115;amp#102;amp#46;amp#110;amp#101;amp#116; wrote:
Firefox, GraphicsMagick, and ImageMagick, are displaying your CurrentResult.bmp just fine. Probably it is a problem with some readers not knowing how to read BMPv3 format. Obviously Firefox 26 does but the software SourceForge uses for creating a thumbnail does not.
Try this (prefix output filename with 'bmp2:') and see if it works better for you:
gm composite map.bmp bird.bmp -matte -background transparent -virtual-pixel constant -displace 100x100 bmp2:output.bmp
Bob
[bugs:#263]http://sourceforge.net/p/graphicsmagick/bugs/263/ transparent virtualpixelmethod
Status: open
Created: Mon Feb 10, 2014 04:18 PM UTC by sara shafaei
Last Updated: Tue Feb 11, 2014 03:46 PM UTC
Owner: Bob Friesenhahn
When the virtualpixel is transparent for displace operator, Image pixels are transparent and virtual pixels are black. The correct result should have virtual pixels transparent and image pixels showing the image pixels.
Sent from sourceforge.nethttp://sourceforge.net because you indicated interest in https://sourceforge.net/p/graphicsmagick/bugs/263/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
The contents of this message, together with any attachments, are intended only for the use of the individual or entity to which they are addressed and may contain information that is confidential and exempt from disclosure. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this message, or any attachment, is strictly prohibited. If you have received this message in error, please notify the original sender immediately by telephone or by return E-mail and delete this message, along with any attachments, from your computer. Thank you.
Related
Bugs:
#263I notice that the GIMP on Linux also reads the BMPv3 output just fine.
This seems to be a problem with the reader used to look at the BMP output file. Using BMPv2 seems likely to fix the problem with the broken reader. Closing this issue as not actually a bug. We can re-open if there is somehow a bug.
Thank you very much for helping to educate me on the displace displace algorithm.
You are right. It was something to do with the format. I was using preview on Mac to see the Image. I saved in to png that solved the problem.
Now, I can see the black fringing around the image. You said this algorithm is going to have update. Just wondering, when you are planning to fix this.
Thank you so much,
~Sara
On Wed, 12 Feb 2014, sara shafaei wrote:
I have a demanding day job which has nothing to do with image
processing. It will get fixed when I have the time and mental energy
to work on it. Luckily the algorithm is well isolated to just one
small function.
Bob
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Thank you for your effort. I appreciate it.
I put in a fix for the background color fringing problem. It may not
be the final solution but the result looks much better with the fix.
Thank you so much! I will try it.
On Feb 16, 2014, at 8:59 PM, Bob Friesenhahn bfriesen@users.sf.netamp#98;amp#102;amp#114;amp#105;amp#101;amp#115;amp#101;amp#110;amp#64;amp#117;amp#115;amp#101;amp#114;amp#115;amp#46;amp#115;amp#102;amp#46;amp#110;amp#101;amp#116; wrote:
I put in a fix for the background color fringing problem. It may not
be the final solution but the result looks much better with the fix.
[bugs:#263]http://sourceforge.net/p/graphicsmagick/bugs/263/ transparent virtualpixelmethod
Status: closed-invalid
Created: Mon Feb 10, 2014 04:18 PM UTC by sara shafaei
Last Updated: Wed Feb 12, 2014 05:43 PM UTC
Owner: Bob Friesenhahn
When the virtualpixel is transparent for displace operator, Image pixels are transparent and virtual pixels are black. The correct result should have virtual pixels transparent and image pixels showing the image pixels.
Sent from sourceforge.nethttp://sourceforge.net because you indicated interest in https://sourceforge.net/p/graphicsmagick/bugs/263/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
The contents of this message, together with any attachments, are intended only for the use of the individual or entity to which they are addressed and may contain information that is confidential and exempt from disclosure. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this message, or any attachment, is strictly prohibited. If you have received this message in error, please notify the original sender immediately by telephone or by return E-mail and delete this message, along with any attachments, from your computer. Thank you.
Hi Bob,
The issue with pixel interpolation is similar to the previous issue with image shear/rotation. I have attached a patch to remove the black artefacts generated from images with fully transparent backgrounds that are transformed with an operator requiring pixel interpolation such as displace.
The approach is to compute the pixel area for each of the four pixels that form the interpolated pixel but use an area of zero for any pixel that is fully transparent as a fully transparent pixel must not contribute colour information regardless of its red, green or blue values. If all pixels are fully transparent then set the red, green and blue colours to zero. Otherwise, sum the percentages of red, green and blue components that make up the interpolated pixel. Percentages are computed as the individual pixel area over the total pixel area.
I have attached the displaced bird image before and after the interpolation fix. An image compare shows only differences at the edges of the displaced image.
Cheers,
Troy Patteson
Oops. I didn't realise you had already fixed this issue. My Bad.
Cheers,
Troy Patteson
Hi Bob,
I had a close look at the changes to InterpolateViewColor() from the head of the mercurial repository and I can see that the patch doesn't fix the issue. Indeed generating the bird displacement image with that version of gm yielded the same image as before the patch. This is what I would expect because setting a fully transparent pixel's primary contribution to zero is the equivalent of treating it as a black pixel which is what was happening in the first place.
Consider the following example where p[0] is white and not fully transparent, and p[1], [2] and p[3] are fully transparent (assume Q16):
Since the only pixel that isn't fully transparent is p[0] you would expected the interpolated pixel to be the colour of p[0] with the opacity interpolated as per the current calculation in the code.
But calculating the pixel colour yields:
which equates to
A very dark grey pixel indeed!
The solution is to make a pixel's contribution equal to its area divided by the total area of all non-fully transparent pixels. Take a look at the patch I posted above. That patch doesn't have the check for matte that your patch does and isn't as cleanly written but gives the general idea.
Cheers,
Troy Patteson
On Wed, 26 Feb 2014, Troy Patteson wrote:
Yes, I was not terribly happy with my fix, which is why I said "May
not be the final solution" in the ChangeLog.
A patch did not make it through via email and I am not sure how to
find it. Where can I find your patch?
Bob
Glad you asked as I just discovered an issue with bracket placement in my patch. Attached is another version. At the very least you will need to add the check for matte which it doesn't include and perhaps there is a better way to format it.
Cheers,
Troy
On Wed, 26 Feb 2014, Troy Patteson wrote:
Ok. I found your patch. I had to go to a second page.
I will look at your patch tomorrow.
There is perhaps a bit more jaggies on the edges but without the
darker fringing.
Bob
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
The second version of the patch produces a much nicer image. See the attached displaced bird image. There are no black fringes that I can seen now.
Cheers,
Troy
I replaced my temporary implementation with Troy's patch plus improvements to deal with when the image does not support transparency or the opacity channel contains something else such as Black. The results look really stellar now.
Thanks Troy and Bob! I tried the new code and results are gorgeous!
Thanks again!