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 (http://inkscapecommunity.com/ic_gallery/index.php)) 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! ;D
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 :D
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.
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?
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.
Andre has already answered this here.
Quote from: Αndré on January 23, 2014, 03:58:46 PM
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?
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 somewhere we do not with this particular 64bit png. I cannot test right now though.
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?
Quote from: gmc on January 29, 2014, 08:10:13 PM
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.
Quote from: Phill Luckhurst on January 29, 2014, 08:24:03 PM
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?
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.
Here is mand2.png converted to 24bit plus alpha. Can you test with this please.
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 :)
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?
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
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:
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
Quote
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.. :)
Quote from: gmc on January 30, 2014, 12:57:47 AM
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.
Quote from: brynn on January 30, 2014, 04:44:35 AM
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 :)
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.
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.
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 :)
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.
I don't know how to summarize my problem any better than in my op.
I don't understand some of the discussion from Phill Lockhurst and gmc, so it's hard for me to clearly understand what they might or might not be on to. So I apologize, but I can't clarify their discussion for you.
Maybe you could read through my op again, and for the moment, ignore their discussion. Maybe it will be more clear that way? If you don't understand my op, please feel free to ask.
(Still waiting for my new isp to take over. Good chance I'll lose my connection any time now. But hopefully I'll be back soon, whenever it happens :o :o)
____________
In case it matters. And for the part of their discussion that I do understand:
For gmc, I've created a 2nd temporary album (http://inkscapecommunity.com/ic_gallery/thumbnails.php?album=28) and uploaded Phill's lower bit PNG as both the original and the custom thumb. The original appropriately displayed the bg, before the custom thumb was applied. And it still is correct bg after custom thumb is applied.
However, it looks like Phill had taken a thumbnail from my album, rather than the full size PNG. I'm not sure if it makes for a fair test, to use a thumbnail. I guess if he took it from my PNG original, it should be fine. But if he took it from one with the black bg, it might not be good to use for testing.
Even though Andre said it should not matter whether the original image is an SVG or not, I still wonder, based on my first experience (memorialized in the linked reference topic above). So in this 2nd temporary album, I uploaded again, my original mand2.svg. Then I applied Phill's low bit PNG as the custom thumbnail.
You can see, that even though I used the same PNG (Phill's low bit) as the custom thumb, on both images, Phill's low bit PNG as the original shows a correct bg for the custom thumb, and my mand2.svg as the original shows the black background.
So I learn 2 things from this:
1 -- The Custom Thumbnail plugin does behave differently when the original is an SVG.
and
2 -- The low bit color does not fix the problem.
This is only valid if Phill's low bit PNG came from my original PNG upload. If he took it from one with the black bg, might not be fair test.
Quote from: brynn on January 31, 2014, 04:21:40 PM
So I learn 2 things from this:
1 -- The Custom Thumbnail plugin does behave differently when the original is an SVG.
and
2 -- The low bit color does not fix the problem.
This is only valid if Phill's low bit PNG came from my original PNG upload. If he took it from one with the black bg, might not be fair test.
Re: 1 -- The Custom Thumbnail plugin
does behave differently when the original is an SVG.
Edit:
BUT it only is happening with THIS mand2.svg using mand2.png as the custom thumbnail.
Note in this album: http://inkscapecommunity.com/ic_gallery/thumbnails.php?album=18, the image titled kal-2.svg. For it's custom thumb, I used kal-2.png. And you can see that there is no black bg there.
Attached are the same files I did the above tests with. (zipped)
So let me get this straight, with the PNG I supplied it works OK. With the PNG from your SVG file it does not correct?
Quote from: Phill Luckhurst on January 31, 2014, 06:08:34 PM
So let me get this straight, with the PNG I supplied it works OK. With the PNG from your SVG file it does not correct?
No.
Is there something wrong with my English? I'm sorry, it's all I know. I'm not sure how many different ways I can explain the same thing. If I'm using the wrong terminology somewhere, please tell me what the correct terminology is. After all, I do want to make it as easy as possible for you :)
If I upload your low bit PNG as the original image, (which looks ok) and then I use your same low bit PNG as the custom thumbnail, it looks ok.
If I upload my SVG (mand2.svg) as the original, and then I use your same low bit PNG as the custom thumbnail, it gets a black background. (It also gets a black bg if I use my mand2.png as the custom thumb.)
You can see the results here: http://inkscapecommunity.com/ic_gallery/thumbnails.php?album=28
Note that so far, the problem is only happening when mand2.svg is used as the original and mand2.png is used as the custom thumbnail.
Quote from: brynn on January 31, 2014, 04:30:10 PM
Note in this album: http://inkscapecommunity.com/ic_gallery/thumbnails.php?album=18, the image titled kal-2.svg. For it's custom thumb, I used kal-2.png. And you can see that there is no black bg there.
Quote from: brynn on January 31, 2014, 07:12:51 PM
Note that so far, the problem is only happening when mand2.svg is used as the original and mand2.png is used as the custom thumbnail.
Edit:
It happened with another SVG, when I first posted the other topic, but I thought the problem was solved and deleted it. And now, I can't remember which one it was. But I could try uploading all the images that I remember using, and maybe I will find it. If that would be helpful for you to have 2 examples, I don't mind trying. Lmk :)
Quote from: brynn on January 31, 2014, 07:12:51 PM
If I upload my SVG (mand2.svg) as the original, and then I use your same low bit PNG as the custom thumbnail, it gets a black background. (It also gets a black bg if I use my mand2.png as the custom thumb.)
I just downloaded your
test_files.zip file. Then, I uploaded
mand2.svg and used the custom thumbnail plugin to apply first
brynns_original_mand2.png and then
PLs_lowbit_mand2.png as custom thumbnail, while creating an intermediate-sized version each time. All created files have a transparent background.
Can somebody confirm that behavior please? Thanks.
Yes, I get the same as Andre.
brynn, please test again with exactly the same steps I just posted. To avoid any unexpected file name collisions, please upload the test SVG file to a separate directory in your albums directory and add it via batch-add. I assume you'll get the same result as Phill and me. If so, I already have an idea what may happened.
Ok, glad to :)
Couple questions.
QuoteThen, I uploaded mand2.svg and used the custom thumbnail plugin to apply first brynns_original_mand2.png and then PLs_lowbit_mand2.png as custom thumbnail, while creating an intermediate-sized version each time.
Do you mean that you applied brynns_original_mand2.png, as custom thumb, to mand2.svg, and then applied PLs_lowbit_mand2.png, as custom thumb, to the same mand2.svg? Or did you upload mand2.svg twice, applying brynns_original_mand2.png, as custom thumb, to one, and PLs_lowbit_mand2.png, as custom thumb, to the other?
Since I've never used batch-add, I had to read up on it in the manual. Do you mean that you want me to upload the images from test_files.zip using my SFTP, and then perform the batch-add? Or do you mean to upload via html (which is how I have been doing it all along) and then perform the batch-add?
Quote from: brynn on February 06, 2014, 03:09:59 AM
Do you mean that you applied brynns_original_mand2.png, as custom thumb, to mand2.svg, and then applied PLs_lowbit_mand2.png, as custom thumb, to the same mand2.svg?
Yes, I did exactly as I wrote.
Quote from: brynn on February 06, 2014, 03:09:59 AM
Do you mean that you want me to upload the images from test_files.zip using my SFTP, and then perform the batch-add?
Yes.
Quote from: brynn on February 06, 2014, 03:09:59 AM
upload via html (which is how I have been doing it all along) and then perform the batch-add?
That's not possible, at least not with Coppermine's built-in features.
Ok, bearing in mind that I don't clearly understand what you're thinking and why I'm doing these steps, I've done my best to follow instructions.
I uploaded mand2.svg, brynns_original_mand2.png, and PLs_lowbit_mand2.png to a new folder (created using Bitvise SFTP) in public_html/ic_gallery/albums called testftp. Then I used Batch-Add and added them to brand new album "3rd_temporary_test" album. Success so far.
The next part I might not have done right. I opened the intermediate page of mand2.svg, and used Custom Thumbnail button to apply brynns_original_mand2.png. The reason I'm not sure that's right, is because that custom thumbnail uploads the PNG from my computer, and not from the batch-added PNG. I don't know how to get it from the ftp uploaded PNGs.
But leaving aside my doubts for the moment, the result of that was a black background on the new custom thumbnail, and correctly sized and background intermediate. Next I clicked Custom Thumbnail button again, and applied the other PNG.
And I apologize, but I might have forgotten to check intermediate for the 2nd PNG. I can do this all again tomorrow, if necessary, if not checking intermediate has ruined the test. But I have to log off right after I post this, and won't be back until tomorrow night or Friday.
So anyway, after applying the 2nd custom thumb, I have a custom thumbnail with a black background, and and intermediate that's the size of a thumbnail, and also has a black background. (That's what makes me think I might have forgotten to check intermediate. Actually, I thought I did check it. But the thumb sized intermediate makes me wonder.)
And you can see the final result here: http://inkscapecommunity.com/ic_gallery/thumbnails.php?album=29
Oh! I can find out if I checked intermediate by looking in the server for it, right? Hhmm, actually, I'm not sure what I'm looking at, on the server. There are 3 new images that start with thumb_, but only 1 that starts with normal_. I would have expected 2 of each, so that's why I'm confused. But maybe it makes more sense to you?
Anyway, let me know if you want me to do it again. And again, I apologize for that. Thanks for all your help, and I'll be back online maybe 18 hours from now (if plans don't change).
All best :)
Quote from: brynn on February 06, 2014, 11:16:57 AM
I uploaded mand2.svg, brynns_original_mand2.png, and PLs_lowbit_mand2.png
This was already wrong.
My bad. I'll delete and start over.
Rather than delete files, I made a new folder using my SFTP (in albums dir) and uploaded only mand2.svg. Then I made another new album (fourth_temp_test) and batch added just that 1 file.
Then I clicked Custom Thumbnail button, selected brynns_original_mand2.png, checked intermediate and clicked Upload. Result: thumbnail has black background, intermediate is correct.
Then I clicked Custom Thumbnail button again, selected PLs_lowbit_mand2.png, checked intermediate, and clicked Upload. Result: thumbnail with black background and intermediate same size and bg of thumbnail.
You can see the result here: http://inkscapecommunity.com/ic_gallery/thumbnails.php?album=31.
Please upload a different file type (e.g. a JPG file or PDF file, or even better: both) with a different file name than "mand2" and try again to apply both images as custom thumbnail. I don't see a reason how this should be related to the file type the custom thumbnails are applied to.
Do you mean for me to convert mand2.svg to a JPG and also a PDF, change the name, and upload those? Or do you mean for me to use 2 entirely different images?
Still using ftp and batch-add?
A totally different file type as per Andre above. Any PDF will do.
I'm sorry that I have to ask so many questions. I just don't understand what's causing the problem, or even what might be causing it. So sketchy requests which might be clear to people with more advanced understanding of how CPG works, are not necessarily clear to me.
For example, I don't understand why me having uploaded 3 images via ftp and batch-add, instead of just 1, should make the test invalid. So when something like that is so important, I want to make sure exactly what:
"Please upload a different file type (e.g. a JPG file or PDF file, or even better: both) with a different file name than "mand2"...."
means. I'm also not sure if I should make a new album. But since he didn't say so, I'll use an existing one.
Ok, I've uploaded a file "tulips.jpg" (which is titled "testing JPG as original") in this album: http://inkscapecommunity.com/ic_gallery/thumbnails.php?album=31. Applying "brynns_original_mand2.png" as first custom thumbnail, I get a thumbnail with a black background, which is the correct width but incorrect height. So the thumbnail is out of proportion and has black background, while the intermediate is correct size and bg.
Next, applying "PLs_lowbit_mand2.png" as custom thumb, "on top of" the first custom thumb, there is no change in the thumbnail. It still is out of proportion and has a black bg. And now, the intermediate is a correctly proportioned thumbnail size, with a black bg.
Uh-oh....oops :-[ I uploaded tulips.jpg via html. Did you mean for me to use ftp/batch-add? Just in case, I'll do it that way too.
Ok, you can see the 3rd thumbnail, which is the 2nd mis-proportioned thumbnail, which has no title, (because I didn't see a way to add a title) (except by later editing file info) for "tulips.jpg" which I uploaded via ftp (to brand new folder) and batch-add, in this album: http://inkscapecommunity.com/ic_gallery/thumbnails.php?album=31. Then I went through the same routine with custom thumbnails. No difference in results. Exactly the same results as html upload.
And now for PDF.....
Well it looks like I haven't configured properly for PDF. When I tried to upload a PDF, I got an error message:
"The file you have uploaded is not a valid image!"
So I'll have to figure out how to fix that, if you really need this test with PDF. Please let me know if you need it right away.
This thread took and is already too long to re-read it again every time. However, If I remember correctly you said the transparent background is lost if you apply a picture with transparent background as custom thumbnail, but just for SVG files. You just disproved that, as you got the same result for a JPG file (that's why I asked you to test with different file types than SVG).
Which settings do you use for Method for resizing images (http://documentation.coppermine-gallery.net/en/configuration.htm#admin_picture_thumb_advanced_resize_method)? GD2 oder ImageMagick? If you use ImageMagick, does it work as expected if you switch to GD2?
Please also provide a test user account (no admin account!), so we can exclude any client side issues.
It was Image Magick. After confirming it was available, I switched to GD2. That seems to have solved the problem! http://inkscapecommunity.com/ic_gallery/thumbnails.php?album=32 Will there be any consequences to switching that resizing method, that I should know about? Do you still need a test member account?
There should not be any problem remaining with GD2 although some plugins work better with Imagemagic. The latter actually has more functionality than GD2 so it would be interesting to know why this particular problem arises.
Transparent background issue for PNG files has been fixed here (http://forum.coppermine-gallery.net/index.php/topic,62286.0.html). I'm sure there's an option for ImageMagick that does the same.
As this thread is solved, we should start a new thread in the bugs board, if anyone can reproduce the issue.
QuoteTransparent background issue for PNG files has been fixed here. I'm sure there's an option for ImageMagick that does the same.
I don't know what you mean about ImageMagick option that does the same thing. But maybe you didn't mean that comment for me?
Yes, I'll mark it solved.
I can probably produce another image which shows this same problem, if that comes under the heading of "reproduce the issue". Although perhaps you would prefer that it comes from someone else?
I don't think I should be the one to start a topic on the bugs board, but I'd be glad to provide another image, if you like. Let me know :)
And thank you very much for your patience and persistence in helping me find a solution to this problem. I really appreciate it :)
Quote from: brynn on February 11, 2014, 06:03:20 PM
maybe you didn't mean that comment for me?
Correct ;)
I've currently no ImageMagick ready to test, so I asked if someone else can confirm the issue while using ImageMagick.
I can confirm the problem with Imagemagic. I can setup a test install on our server if you wish Andre.
I just downloaded ImageMagick to my local testbed and confirmed the issue with the custom thumbnail plugin. As it's a plugin related issue, we don't need a thread in the bugs board.
It seems that ImageMagick automatically considers the alpha channel if you create a PNG file. This worked for me immediately:
Open plugins/custom_thumb/codebase.php, find
$row['filename'] = str_replace($row['filename'], basename($row['filename'], '.'.$path_parts['extension']).'.jpg', $row['filename']);
and replace with
$row['filename'] = basename($row['filename'], '.'.$path_parts['extension']).'.png';
I just noticed that the custom thumbnail plugin doesn't check if it will overwrite existing files. E.g. if there are already pictures like cat.jpg and cat.png and you now apply a custom thumbnail to cat.avi, the plugin will (probably) overwrite the existing thumbnail pictures. But that's another issue which shouldn't be discussed here.
Does this mean if I edit the code as you explained, I could go back to using ImageMagick?
At least it worked for me with ImageMagick and that code change. Please report if it also works for you.
Success!
http://inkscapecommunity.com/ic_gallery/thumbnails.php?album=35
Unless anyone has an objection, I'll be deleting all the extra images and albums I created in my gallery, during this troubleshooting process. I realize that might make it difficult for anyone who may search out this topic to help with their own problem. And so I apologize that many of the links I made to my results, along the way, will be dead. But this isn't a test gallery, it's my forum's gallery.
Also, thanks again for Phill's and Andre's help, and everyone else who helped along the way :)