Ok. I'll poke around in GD::SVG to see what might be the problem with this strategy. It ought to be ok.<br><br>Lincoln<br><br><div class="gmail_quote">On Fri, May 29, 2009 at 5:18 PM, Angie Hinrichs <span dir="ltr"><<a href="mailto:angie@soe.ucsc.edu">angie@soe.ucsc.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">> Angie, is there any reason to call transparent()? The other tracks render<br>
> their background in a solid color.<br>
<br>
</div>In a nutshell, to avoid hiding the vertical light blue ruler lines in<br>
the background by drawing white on top of them.<br>
<br>
Currently, ucsc_glyph::draw gets a colormap+pixelmap representation of<br>
an image with a white background (from UCSC C code by way of<br>
UcscConservation plugin), creates a GD::Image $im as described below<br>
and uses $gd->copy to plop that on top of the GBrowse image:<br>
<br>
$gd->copy($im, $x-$leftLabelWidth, $y, 0, 0, $width, $height);<br>
<br>
-- so it bypasses all of the usual glyph draw() infrastructure, and<br>
renders the entire allocated space in the main image. Using<br>
transparency preserves the light blue lines and whatever else might be<br>
in the background... is it not worth the trouble? Is there a better<br>
way?<br>
<br>
Thanks,<br>
<font color="#888888">Angie<br>
</font><div><div></div><div class="h5"><br>
On Fri, 29 May 2009, Lincoln Stein wrote:<br>
<br>
> Angie, is there any reason to call transparent()? The other tracks render<br>
> their background in a solid color.<br>
><br>
> Lincoln<br>
><br>
> On Fri, May 29, 2009 at 3:56 PM, Angie Hinrichs <<a href="mailto:angie@soe.ucsc.edu">angie@soe.ucsc.edu</a>> wrote:<br>
><br>
> > Mark, Do you see any error_log warnings like "ucsc_glyph: colors will<br>
> > be out of sync ($i --> $index)!" ?<br>
> ><br>
> > Wherever the bad interaction is taking place, it is definitely an<br>
> > alpha-channel problem. To construct the GD::Image using the colormap<br>
> > and pixelmap returned by the UCSC C code,<br>
> > Bio/Graphics/Glyph/<a href="http://ucsc_glyph.pm" target="_blank">ucsc_glyph.pm</a> uses these calls:<br>
> ><br>
> > my $im = GD::Image->new($width, $height);<br>
> > $im->transparent( <UCSC colormap's white index> );<br>
> ><br>
> > ... loop on UCSC colormap calls $im->colorAllocate(),<br>
> > ** hoping that calling $im->colorAllocate() in the same order<br>
> > results in same colormap indices<br>
> ><br>
> > ... loop on UCSC pixelmap calls $im->setPixel()<br>
> ><br>
> > ** Here is where something could go wrong. It looks like I should<br>
> > call $im->transparent *after* the call to $im->colorAllocate() for<br>
> > white, making sure that I pass $im's actual white index to<br>
> > $im->transparent. However, when I call transparent after<br>
> > colorAllocate, the white pixels are shaded light gray instead of being<br>
> > transparent, even in the default display. Calling $im->transparent<br>
> > first was just a hack that worked, and then I forgot about it. I will<br>
> > try updating GD too, to see if that makes any difference.<br>
> ><br>
> > FWIW I am constructing the GD::Image one color and pixel at a time<br>
> > because when I used GD::Image->newFromGdData(), the image was created<br>
> > OK but when I returned the new $im from a sub{}, perl crashed with a<br>
> > 'glibc detected double free or corruption'. Does that ring a bell for<br>
> > anybody?<br>
> ><br>
> > Angie<br>
> ><br>
> > On Fri, 29 May 2009, Todd W. Harris wrote:<br>
> ><br>
> > > Mark -<br>
> > ><br>
> > > Try upgrading your GD::SVG to the most current version on CPAN.<br>
> > ><br>
> > > Todd<br>
> > ><br>
> > ><br>
> > > On May 29, 2009, at 9:42 AM, mark meyer wrote:<br>
> > ><br>
> > > > We use the GD::SVG and was never able to get the inkscape (pdf<br>
> > generation)<br>
> > > > operational, if that helps any.<br>
> > > ><br>
> > > > On Fri, May 29, 2009 at 9:52 AM, Scott Cain <<a href="mailto:scott@scottcain.net">scott@scottcain.net</a>><br>
> > wrote:<br>
> > > > Hi all,<br>
> > > ><br>
> > > > Could this be a bad interaction between the plug in and GD::SVG or<br>
> > > > inkscape (depending on what sort of hi res image you are getting)?<br>
> > > > For example, I think that GD::SVG has a hard time with alpha channels.<br>
> > > ><br>
> > > > Scott<br>
> > > ><br>
> > > ><br>
> > > > On Fri, May 29, 2009 at 10:31 AM, mark meyer <<a href="mailto:mmeyerposting@gmail.com">mmeyerposting@gmail.com</a>><br>
> > > > wrote:<br>
> > > > > Hi Angie,<br>
> > > > ><br>
> > > > > Bill is out of the office today, but I can try to answer your<br>
> > questions.<br>
> > > > > Attached are the two screen shots, one is what the plugin looks like<br>
> > in<br>
> > > > > the<br>
> > > > > gbrowse, just fine as it looks in UCSC. The second is what happens<br>
> > when<br>
> > > > > you<br>
> > > > > click on high-res image.<br>
> > > > ><br>
> > > > > We are running gbrowse v1.69. The plugin code was implemented and<br>
> > > > > downloaded about 1 month ago, just recently ran into this issue since<br>
> > we<br>
> > > > > are<br>
> > > > > trying to make some publication figures from our Gbrowse data.<br>
> > > > ><br>
> > > > > I can access conf files, etc. if you need to see them and try to do<br>
> > my<br>
> > > > > best<br>
> > > > > to answer questions, but I may not be able to answer very detailed<br>
> > > > > questions<br>
> > > > > in Bill's absence since he has been the one configuring this.<br>
> > > > ><br>
> > > > > Thanks for checking into this for us,<br>
> > > > ><br>
> > > > > Mark<br>
> > > > ><br>
> > > > > On Thu, May 28, 2009 at 5:29 PM, Angie Hinrichs <<a href="mailto:angie@soe.ucsc.edu">angie@soe.ucsc.edu</a>><br>
> > > > > wrote:<br>
> > > > > ><br>
> > > > > > Dave - yes, that sounds likely.<br>
> > > > > ><br>
> > > > > > Bill, what version of GBrowse are you running? How recently did<br>
> > you<br>
> > > > > > grab the plugin code? I didn't get the screenshot attachment so if<br>
> > > > > > you wouldn't mind sending that to me, that would be helpful. If<br>
> > your<br>
> > > > > > GBrowse is on a public server, can you send the URL?<br>
> > > > > ><br>
> > > > > > Angie<br>
> > > > > ><br>
> > > > > > On Thu, 28 May 2009, Dave Clements, GMOD Help Desk wrote:<br>
> > > > > ><br>
> > > > > > > Hi Bill,<br>
> > > > > > ><br>
> > > > > > > I have no particular insight on why this is happening. My guess<br>
> > is<br>
> > > > > > > that it is due some obscure interaction between the UCSC plugin<br>
> > and<br>
> > > > > > > core GBrowse, but I don't actually know.<br>
> > > > > > ><br>
> > > > > > > I've CC'd Angie at UCSC to see if she may have any insight.<br>
> > > > > > ><br>
> > > > > > > Dave C.<br>
> > > > > > ><br>
> > > > > > ><br>
> > > > > > ><br>
> > > > > > > On Tue, May 26, 2009 at 2:25 PM, Bill Pulec <<a href="mailto:wpulec@gmail.com">wpulec@gmail.com</a>><br>
> > wrote:<br>
> > > > > > > > Hi All,<br>
> > > > > > > > I am attempting to view high-res images of conservation tracks<br>
> > but<br>
> > > > > > the<br>
> > > > > > > > background of these tracks in high-res is blue. This isn't the<br>
> > case<br>
> > > > > > > > when<br>
> > > > > > > > these tracks are displayed in gbrowse normally, it only happens<br>
> > when<br>
> > > > > > > > viewed<br>
> > > > > > > > as high-res. Also all the non-conservation tracks are fine in<br>
> > high<br>
> > > > > > > > res. Is<br>
> > > > > > > > there any reason why outputting these images in high-res would<br>
> > do<br>
> > > > > > > > this? Has<br>
> > > > > > > > anyone encountered other tracks doing this in high-res? Any<br>
> > insight<br>
> > > > > > > > would be<br>
> > > > > > > > appreciated. I have attached an example image of the track<br>
> > below.<br>
> > > > > > > ><br>
> > > > > > > > Thanks,<br>
> > > > > > > > Bill<br>
> > > > > > > ><br>
> > > > > > > ><br>
> > > > > > > ><br>
> > > > > > ><br>
> > > > > > > Was this helpful? Let us know at<br>
> > > > > > > <a href="http://gmod.org/wiki/Help_Desk_Feedback" target="_blank">http://gmod.org/wiki/Help_Desk_Feedback</a><br>
> > > > > > ><br>
> > > > > > > Learn more about GMOD at:<br>
> > > > > > > SMBE:<br>
> > > > > > ><br>
> > <a href="http://ccg.biology.uiowa.edu/smbe/symposia.php?action=view&sym_ID=27" target="_blank">http://ccg.biology.uiowa.edu/smbe/symposia.php?action=view&sym_ID=27</a><br>
> > > > > > > Arthropod Genomics:<br>
> > <a href="http://www.k-state.edu/agc/symp2009/seminar.html" target="_blank">http://www.k-state.edu/agc/symp2009/seminar.html</a><br>
> > > > > > > AGA Next Gen Seq in Non-Models:<br>
> > > > > > > <a href="http://www.regonline.com/Nextgeneration" target="_blank">http://www.regonline.com/Nextgeneration</a><br>
> > > > > > ><br>
> > > > > ><br>
> > > > > ><br>
> > > > > ><br>
> > > > > ><br>
> > ------------------------------------------------------------------------------<br>
> > > > > > Register Now for Creativity and Technology (CaT), June 3rd, NYC.<br>
> > CaT<br>
> > > > > > is a gathering of tech-side developers & brand creativity<br>
> > professionals.<br>
> > > > > > Meet<br>
> > > > > > the minds behind Google Creative Lab, Visual Complexity,<br>
> > Processing, &<br>
> > > > > > iPhoneDevCamp as they present alongside digital heavyweights like<br>
> > > > > > Barbarian<br>
> > > > > > Group, R/GA, & Big Spaceship.<br>
> > <a href="http://p.sf.net/sfu/creativitycat-com" target="_blank">http://p.sf.net/sfu/creativitycat-com</a><br>
> > > > > > _______________________________________________<br>
> > > > > > Gmod-gbrowse mailing list<br>
> > > > > > <a href="mailto:Gmod-gbrowse@lists.sourceforge.net">Gmod-gbrowse@lists.sourceforge.net</a><br>
> > > > > > <a href="https://lists.sourceforge.net/lists/listinfo/gmod-gbrowse" target="_blank">https://lists.sourceforge.net/lists/listinfo/gmod-gbrowse</a><br>
> > > > ><br>
> > > > ><br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > > --<br>
> > > ><br>
> > ------------------------------------------------------------------------<br>
> > > > Scott Cain, Ph. D. scott at scottcain<br>
> > dot<br>
> > > > net<br>
> > > > GMOD Coordinator (<a href="http://gmod.org/" target="_blank">http://gmod.org/</a>) 216-392-3087<br>
> > > > Ontario Institute for Cancer Research<br>
> > > ><br>
> > > ><br>
> > ------------------------------------------------------------------------------<br>
> > > > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT<br>
> > > > is a gathering of tech-side developers & brand creativity<br>
> > professionals.<br>
> > > > Meet<br>
> > > > the minds behind Google Creative Lab, Visual Complexity, Processing, &<br>
> > > > iPhoneDevCamp as they present alongside digital heavyweights like<br>
> > Barbarian<br>
> > > > Group, R/GA, & Big Spaceship. <a href="http://p.sf.net/sfu/creativitycat-com" target="_blank">http://p.sf.net/sfu/creativitycat-com</a><br>
> > > > _______________________________________________<br>
> > > > Gmod-gbrowse mailing list<br>
> > > > <a href="mailto:Gmod-gbrowse@lists.sourceforge.net">Gmod-gbrowse@lists.sourceforge.net</a><br>
> > > > <a href="https://lists.sourceforge.net/lists/listinfo/gmod-gbrowse" target="_blank">https://lists.sourceforge.net/lists/listinfo/gmod-gbrowse</a><br>
> > ><br>
> ><br>
><br>
><br>
><br>
><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Lincoln D. Stein<br>Director, Informatics and Biocomputing Platform<br>Ontario Institute for Cancer Research<br>101 College St., Suite 800<br>Toronto, ON, Canada M5G0A3<br>
416 673-8514<br>Assistant: Renata Musa <<a href="mailto:Renata.Musa@oicr.on.ca">Renata.Musa@oicr.on.ca</a>><br>