Print

[brynn]

Hi Friends,
During the investigation and resolution of this topic:  http://forum.coppermine-gallery.net/index.php/topic,77019.0.html, I've come across another issue, and have been advised to start a new topic.  I hope this is the proper board to post in, but I'm sure you'll move it if necessary 

Background:  I use CPG to display both raster and vector (SVG) images. (my gallery)  CPG's SVG plugin is outdated, and has some display issues (http://forum.coppermine-gallery.net/index.php/topic,76674.0.html).  However, I recently discovered that SVGs can be uploaded and displayed (full size only) without the SVG plugin, and that apparently the purpose of the plugin is entirely to create and display thumbnails and intermediates.  (Some of my example links in the svg topic are probably no good.  Some images may have been deleted, or maybe because I've now uninstalled the plugin, they can't be seen.  Just fyi.)

Once I realized that SVGs can still be uploaded without the plugin, immediately the Custom Thumbnails plugin came to mind (which seems to have been designed to provide thumbnails for uploaded video files).  I wondered if it would work for my SVG issues.  And after some investigation and support in the referenced topic (http://forum.coppermine-gallery.net/index.php/topic,77019.0.html) my gallery now can display custom thumbs and intermeds for SVG images.  Yay! 

Current issue (described by topic title):  However, there still are 1 or 2 issues, and the issue up for discussion (and hopefully investigation) here, is that at least 1 of the PNGs I've uploaded as a custom thumb/intermed shows a black background, when the PNG actually has a transparent background.  So far, that's the only PNG uploaded as a custom thumb, that shows this display problem.  Some PNGs which also have transparent bg, used as custom thumbs, are displayed properly, with transparent bg.  But I can't find anything about that PNG (or its parent SVG) which might account for the problem.

Whoa!!  Well, during my preparation to provide links for you to look at examples, I may have uncovered an important clue!

Please refer to this album:  http://inkscapecommunity.com/ic_gallery/thumbnails.php?album=18.  First, I uploaded mand2.svg, then using Custom Thumbnail button, uploaded mand2.png for the thumb/intermed.  The resulting custom thumb showed a black background, while the original PNG is transparent bg.  The resulting custom intermed showed correctly the transparent bg.

Next, I uploaded mand2.png, to show you that it indeed has a transparent background.  However, the moment mand2.png was uploaded, the custom thumbnail for mand2.svg immediately showed the proper transparent background.  So at the moment, you can't see the problem in the "just for testing" album.  But you can see that mand2.png has a transparent bg.

Then, I created a temporary new album called temp test (http://inkscapecommunity.com/ic_gallery/thumbnails.php?album=27).  There I uploaded mand2.svg again, and again uploaded mand2.png as the custom thumb.  In this "temp test" album, you CAN still see the inappropriate black background.  I assume that if I were to upload mand2.png as a separate image, it would probably fix the black bg, as it did in the other album.

For the record, I would not consider it to be an acceptable "workaround" to always have to upload the custom thumb as a separate image, just to fix the thumb display.  I hope you can understand why, but I can't explain, if not 

Ok then, let me know if I can provide any further info, and/or whatever I can do to help you solve this   

PS -- I used Firefox 26.0 for upload, but this display issue is also apparent in IE 11.  Idk if uploading using IE would make any difference.

[phill104]

Your manual upload is a 64bit PNG but the one uploaded by the plugin was converted to a 24bit PNG with no alpha channel. I am not sure the plugin supports the alpha without some investigation. As a quick test, have you tried switching libraries in the CPG config from GD2 to imageMagik?

[brynn]

Looks like it's set on ImageMagick already.  Assuming the setting you mean is "Method for resizing images".

The last few posts in this topic may address your question about whether the plugin supports alpha:  http://forum.coppermine-gallery.net/index.php/topic,77019.0.html.  I don't know why Andre would investigate the issue, if the plugin wasn't supposed to support transparency.

[phill104]

Andre has already answered this here.

Sorry, I overlooked the word "thumbs". I just re-checked and you are correct, all thumbnails of that picture have a black background. The reason can be found in the known issues docs:
So you either need to add a background color of your choice before using the custom thumbnail plugin, or use the following workaround. At first, upload the custom thumbnail while creating also an intermediate-sized picture like before. Then, export your PNG a second time from Inkscape, but use a smaller resolution which fits your Coppermine settings, so the plugin doesn't need to resize the image. Upload this file as custom thumbnail while not creating an intermediate sized picture.

Or am I confusing something here?

[gmc]

From my testing/usage, GD doesn't properly handle transparent backgrounds - converting them to black...
I don't use many of these (just for category thumbs typically) - so the one's GD doesn't handle, I resize and upload the thumb_ version - overlaying the CPG created image...

From brynn's comment, it appears ImageMagick has same issue...  I had not tested that yet.

The custom intermediate I expect is as desired as it didn't need to be resized - so wash't touched by GD/ImageMagick

Not much can be done here from CPG standpoint... Unless new(er) support in GD or Imagemagick has options we can exploit. Not an area I've looked at recently - so I'll defer to others if they know.

I can see the issue if dealing with a large number of images... Just don't see a good answer.

[phill104]

imagemagick does support the alpha channel but is seems somewhere we do not with this particular 64bit png. I cannot test right now though.

[brynn]

It's more likely that I'm confused!

But when Andre referred to known issues doc, the issue was "Resizing gif/png with transparent background doesn't preserve alpha info".  But by his last post in that topic (http://forum.coppermine-gallery.net/index.php/topic,77019.msg372593.html#msg372593), he said it had been fixed already, and if I have further problems, to start a new topic.  So that's what I've done. 

Note, when referring to that last post, I don't have a problem with the transparent bg in that image that he tested (Kal-1-P.png) either.  It displays correctly to me, too.  For some reason, it seems to be, at least so far, just the mand2.png image.  I just can't figure out why.  So I don't know if it might happen on other PNGs too.  Clearly it doesn't happen to all, but it seems to with some PNGs.

And for the record, everyone adjusting their PNGs to the CPG resolution/dimensions, isn't realistic.  It's bad enough we have to upload an SVG and a PNG, in order to have a thumbnail that's not the grayscale transparent cube default image (and still be able to upload SVGs).  But if we have to export a 2nd PNG at perfect dimensions, and upload a 3rd image, then why bother uploading an SVG at all, in the first place.  The whole point of me trying to make my gallery able to upload SVGs at all, is to help urge the internet community to make wares that are more conducive to SVGs.  It's a relatively new, and growing technology, which does not have much support around the internet community yet.  It needs to grow.  And I see my ability to at least upload and display (at least full size) SVGs to be a stepping stone along the way to fuller use of SVG around the internet.  Ultimately, I hope it will urge someone to create a gallery designed to support primarily SVG and vector images, and raster secondarily, (and we haven't even started talking about EPS, AI, or PDF vector images yet).  But if we have to create 2 PNG exports from 1 SVG, and one of them specific resolution/dimensions, and upload 3 images in all, for 1 gallery display, then what's the point?

[brynn]

From my testing/usage, GD doesn't properly handle transparent backgrounds - converting them to black...
I don't use many of these (just for category thumbs typically) - so the one's GD doesn't handle, I resize and upload the thumb_ version - overlaying the CPG created image...

From brynn's comment, it appears ImageMagick has same issue...  I had not tested that yet.

The custom intermediate I expect is as desired as it didn't need to be resized - so wash't touched by GD/ImageMagick

Not much can be done here from CPG standpoint... Unless new(er) support in GD or Imagemagick has options we can exploit. Not an area I've looked at recently - so I'll defer to others if they know.

I can see the issue if dealing with a large number of images... Just don't see a good answer.

imagemagick does support the alpha channel but is seems the plugin does not

I don't quite understand the above 2 posts.  Should I test with some non-square images?

[phill104]

No, but can you test with a 32bit or 24bit png please. Not sure it understands a 64bit png which is what that particular problematic image seems to show as.

[phill104]

Here is mand2.png converted to 24bit plus alpha. Can you test with this please.

[brynn]

Well yes, I'll test.  But all the PNGs I have are made by exporting SVGs from Inkscape.  They should all be the same bits (not that I'm really sure what the "bits" mean, in this case)(but I think I have an idea).  I'll test and brb 

[brynn]

Ok, you can see the results in this album:  http://inkscapecommunity.com/ic_gallery/thumbnails.php?album=27.  Or....actually, I assumed that you meant for me to use that 24 bit image as the custom thumbnail.  I used the same original mand2.svg.  Or did you mean for me to upload by itself?

[gmc]

A little late for Phill...
Are both images in that album Phill's image? The first as normal upload, and second as custom thumb?
If so, then the lower bit image made no difference....
(if that isn't what you did, would you please?)

Uploading as normal image that size shouldn't alter the intermediate image at all (which still has transparent background) - but does create the thumbnail using ImageMagick (which has the black background..

Greg

[gmc]

One more question... What version of ImageMagick are you using?
To check - logged in Admin, select phpinfo from menu or go to phpinfo.php.
You will need to still down a bit, and find:

Code: [Select]

imagick
imagick module enabled
imagick module version 3.1.0b1
imagick classes Imagick, ImagickDraw, ImagickPixel, ImagickPixelIterator
ImageMagick version ImageMagick 6.6.0-4 2012-05-03 Q16 http://www.imagemagick.org

I found an interesting post at http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=20847

Re: Color information lost during resize operation
by anthony » 2012-04-26T22:03:12+00:00

THIS IS NOT A BUG

The reason for the loss of color when resizing, is that resize (and many other operators) treat alpha as a 'blending' channel.

That is a fully-transparent pixel is transparent and thus the values in the color channels has no (or lesser) meaning, and should not contribute (or contribute less) to the overall resulting color. As a consequence alpha is used to weight alpha during convolutions (like resize) to ensure fully-transparent pixels do not take part in the resize.

This is to prevent halo effects that existed early in IMv6 history
http://www.imagemagick.org/Usage/bugs/resize_halo/

IMv7 will see the ability to turn off 'alpha blending' completely, and thus just treat all channels, including alpha, as a normal image data channel, without any special meaning. In IMv6 it is necessary to separate alpha from the image and handle the channels as separate entities.

Simple way, just separate ALL channels!
CODE: SELECT ALL
   convert image  -channel RGBA -separate  -resize 100x100  -combine  result
Anthony Thyssen -- Webmaster for ImageMagick Example Pages
http://www.imagemagick.org/Usage/

Phill - seems to suggest a way to separate alpha, resize, and combine under v6... And new option in v7...
I'll do some looking at the code.. But your day starts before mine..

[brynn]

A little late for Phill...
Are both images in that album Phill's image? The first as normal upload, and second as custom thumb?
If so, then the lower bit image made no difference....
(if that isn't what you did, would you please?)

Uploading as normal image that size shouldn't alter the intermediate image at all (which still has transparent background) - but does create the thumbnail using ImageMagick (which has the black background..

Greg

I'm not sure what you're asking.  Both images in the temp test album, if you click through to the full size, are mand2.svg.  The first (with no title) uses my original mand2.png for the custom thumb.  The 2nd (titled "to test w/PL's png as custom thumb") uses Phill's lower bit PNG for the custom thumbnail.

It sounds like you might be asking me to upload Phill's lower bit PNG for the original image, and then again as its custom thumbnail?  The reason I'm not going to go ahead and do that for you, just in case, is because when I uploaded the PNG separately in "just for testing" album, it seems to have fixed the display problem.  So you won't be able to see the problem anymore.  So since I'm not sure what you're asking, I think it would be better to wait and make sure that's what you're asking.  So if you could just confirm, I'll be glad to do that

imagick module:  enabled
imagick module version:  3.1.2
imagick classes:  Imagick, ImagickDraw, ImagickPixel, ImagickPixelIterator
imagick version:     ImageMagick 6.2.8 04/25/12 Q16

I'm pretty sure there's no way to separate channels during Inkscape's PNG export.  I've never heard anything about that.  So hopefully you all will find some good news somewhere.  I just find it odd that it happens sometimes, and not every time, a PNG with transparency is used for custom thumb.

Also, last bit of info.  I won't be online tomorrow (Thursday) (Mountain Standard Time) due to previous commitment.  And I've just upgraded my internet connection speed, which required switching ISPs, so my connection is due to go down Friday morning, when the new service goes into effect.  Hopefully I can get the proper new modem/router settings without delay, and I'll be back in business late Friday morning.  And I'm just about to log out for tonight, and get some sleep.  Sorry for delay.

[brynn]

I'm not sure what you're asking.  Both images in the temp test album, if you click through to the full size, are mand2.svg.  The first (with no title) uses my original mand2.png for the custom thumb.  The 2nd (titled "to test w/PL's png as custom thumb") uses Phill's lower bit PNG for the custom thumbnail.

It sounds like you might be asking me to upload Phill's lower bit PNG for the original image, and then again as its custom thumbnail?  The reason I'm not going to go ahead and do that for you, just in case, is because when I uploaded the PNG separately in "just for testing" album, it seems to have fixed the display problem.  So you won't be able to see the problem anymore.  So since I'm not sure what you're asking, I think it would be better to wait and make sure that's what you're asking.  So if you could just confirm, I'll be glad to do that

Sorry for 2nd reply, can't edit (argh).  Hoping to clarify what I'm saying.

In "just for testing" album (http://inkscapecommunity.com/ic_gallery/thumbnails.php?album=18) you can see image titled "mand2.svg" which uses my original mand2.png as custom thumbnail.  Then right next to it, titled "mand2.png", I uploaded the same original mand2.png.  Immediately when the PNG was uploaded, the display problem using the exact same PNG as custom thumb, was corrected.  I expect that would happen in "temp test" album, where I've already used Phill's lower bit image as a custom thumbnail.  Once I upload it as the main image, and possibly whether I assign it a custom thumb or not, the display problem for the image "to test w/PL's png as custom thumb" will be corrected.

I hope that makes sense to you, and sorry it will be a day or so before I can clarify, if needed.

Thanks again for your help 

[Αndré]

If it works as expected when uploading PNG files, then it's definitely an issue with the plugin. When I said it has already been fixed and the know issues page was outdated I obviously forgot that we talked about the plugin and not the stock Coppermine upload. I'll have a look soon.

[Αndré]

I just tested to upload the attached PNG files and also used them as custom thumbnails. The transparent background is always preserved while using GD2.

[brynn]

I had a few minutes tonight to check in.  As we learned in the referenced topic, for some reason, the Custom Thumbnail plugin works, or at least worked differently when the original image was an SVG.

Rather than apply those PNGs as custom thumbnails to original images which are also PNGs, I wonder if testing using an SVG as original might not be prudent?  I can't attach one here, so you'll have to grab one from my gallery, if you think it's worthwhile to test with SVG as original.  Oh -- I'll bet I could zip one and attach it!  You can use attached if necessary

[Αndré]

It shouldn't matter if we apply a custom thumbnail to an SVG file, an PNG file or whatever file. I currently don't know what exactly works and what doesn't work as expected. Could you (or someone else) please summarize, preferably with example files (added to a zip file if you cannot attach them all separately)? Thanks.