That's good news.<br><br>Lincoln<br><br><div class="gmail_quote">On Mon, Jun 1, 2009 at 1:57 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;">
Thanks! I just checked that in to CVS -- the external repository<br>
should be updated by noon Pacific time. The light blue lines go away<br>
but at least the track image doesn't disappear into dark blue. :)<br>
<font color="#888888"><br>
Angie<br>
</font><div><div></div><div class="h5"><br>
On Mon, 1 Jun 2009, Lincoln Stein wrote:<br>
<br>
> Hi Angie,<br>
><br>
> Try this: if ($gd->isa('GD::SVG')) { # in high res mode }<br>
><br>
> Lincoln<br>
><br>
> On Mon, Jun 1, 2009 at 12:57 PM, Angie Hinrichs <<a href="mailto:angie@soe.ucsc.edu">angie@soe.ucsc.edu</a>> wrote:<br>
><br>
> > I took a look at the latest C source code for gdImageCopy()<br>
> > (<a href="http://cvs.php.net/viewvc.cgi/gd/libgd/src/gd.c?revision=1.83&view=markup" target="_blank">http://cvs.php.net/viewvc.cgi/gd/libgd/src/gd.c?revision=1.83&view=markup</a><br>
> > )<br>
> > and it looks like since gd version 2.0.10, if a pixel is transparent<br>
> > in the source, it is not copied to the destination. I can see how<br>
> > that might interact badly when copying into something other than<br>
> > another pixellated image.<br>
> ><br>
> > Is there a hook in GBrowse by which a plugin or glyph can tell that it<br>
> > is in high-res mode, so it can avoid using transparency?<br>
> ><br>
> > Thanks,<br>
> > Angie<br>
> ><br>
> > On Fri, 29 May 2009, Lincoln Stein wrote:<br>
> ><br>
> > > Ok. I'll poke around in GD::SVG to see what might be the problem with<br>
> > this<br>
> > > strategy. It ought to be ok.<br>
> > ><br>
> > > Lincoln<br>
> > ><br>
> > > On Fri, May 29, 2009 at 5:18 PM, Angie Hinrichs <<a href="mailto:angie@soe.ucsc.edu">angie@soe.ucsc.edu</a>><br>
> > wrote:<br>
> > ><br>
> > > > > Angie, is there any reason to call transparent()? The other tracks<br>
> > render<br>
> > > > > their background in a solid color.<br>
> > > ><br>
> > > > 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>
> > > > Angie<br>
> > > ><br>
> > > > On Fri, 29 May 2009, Lincoln Stein wrote:<br>
> > > ><br>
> > > > > Angie, is there any reason to call transparent()? The other tracks<br>
> > 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>><br>
> > > > wrote:<br>
> > > > ><br>
> > > > > > Mark, Do you see any error_log warnings like "ucsc_glyph: colors<br>
> > 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<br>
> > 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<br>
> > 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<br>
> > 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<br>
> > created<br>
> > > > > > OK but when I returned the new $im from a sub{}, perl crashed with<br>
> > a<br>
> > > > > > 'glibc detected double free or corruption'. Does that ring a bell<br>
> > 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 <<br>
> > <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<br>
> > or<br>
> > > > > > > > inkscape (depending on what sort of hi res image you are<br>
> > getting)?<br>
> > > > > > > > For example, I think that GD::SVG has a hard time with alpha<br>
> > > > channels.<br>
> > > > > > > ><br>
> > > > > > > > Scott<br>
> > > > > > > ><br>
> > > > > > > ><br>
> > > > > > > > On Fri, May 29, 2009 at 10:31 AM, mark meyer <<br>
> > > > <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<br>
> > looks<br>
> > > > like<br>
> > > > > > in<br>
> > > > > > > > > the<br>
> > > > > > > > > gbrowse, just fine as it looks in UCSC. The second is what<br>
> > > > happens<br>
> > > > > > when<br>
> > > > > > > > > you<br>
> > > > > > > > > click on high-res image.<br>
> > > > > > > > ><br>
> > > > > > > > > We are running gbrowse v1.69. The plugin code was<br>
> > implemented<br>
> > > > and<br>
> > > > > > > > > downloaded about 1 month ago, just recently ran into this<br>
> > issue<br>
> > > > since<br>
> > > > > > we<br>
> > > > > > > > > are<br>
> > > > > > > > > trying to make some publication figures from our Gbrowse<br>
> > data.<br>
> > > > > > > > ><br>
> > > > > > > > > I can access conf files, etc. if you need to see them and try<br>
> > to<br>
> > > > do<br>
> > > > > > my<br>
> > > > > > > > > best<br>
> > > > > > > > > to answer questions, but I may not be able to answer very<br>
> > > > 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 <<br>
> > > > <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<br>
> > recently<br>
> > > > did<br>
> > > > > > you<br>
> > > > > > > > > > grab the plugin code? I didn't get the screenshot<br>
> > attachment<br>
> > > > so if<br>
> > > > > > > > > > you wouldn't mind sending that to me, that would be<br>
> > helpful.<br>
> > > > 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.<br>
> > My<br>
> > > > guess<br>
> > > > > > is<br>
> > > > > > > > > > > that it is due some obscure interaction between the UCSC<br>
> > > > 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<br>
> > insight.<br>
> > > > > > > > > > ><br>
> > > > > > > > > > > Dave C.<br>
> > > > > > > > > > ><br>
> > > > > > > > > > ><br>
> > > > > > > > > > ><br>
> > > > > > > > > > > On Tue, May 26, 2009 at 2:25 PM, Bill Pulec <<br>
> > > > <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<br>
> > > > tracks<br>
> > > > > > but<br>
> > > > > > > > > > the<br>
> > > > > > > > > > > > background of these tracks in high-res is blue. This<br>
> > isn't<br>
> > > > the<br>
> > > > > > case<br>
> > > > > > > > > > > > when<br>
> > > > > > > > > > > > these tracks are displayed in gbrowse normally, it only<br>
> > > > happens<br>
> > > > > > when<br>
> > > > > > > > > > > > viewed<br>
> > > > > > > > > > > > as high-res. Also all the non-conservation tracks are<br>
> > fine<br>
> > > > in<br>
> > > > > > high<br>
> > > > > > > > > > > > res. Is<br>
> > > > > > > > > > > > there any reason why outputting these images in<br>
> > high-res<br>
> > > > would<br>
> > > > > > do<br>
> > > > > > > > > > > > this? Has<br>
> > > > > > > > > > > > anyone encountered other tracks doing this in high-res?<br>
> > Any<br>
> > > > > > insight<br>
> > > > > > > > > > > > would be<br>
> > > > > > > > > > > > appreciated. I have attached an example image of the<br>
> > 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>
> > > > > ><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>
> > > ><br>
> > ------------------------------------------------------------------------------<br>
> > > > > > > > > > Register Now for Creativity and Technology (CaT), June 3rd,<br>
> > > > 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<br>
> > heavyweights<br>
> > > > 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>
> > > ><br>
> > ------------------------------------------------------------------------<br>
> > > > > > > > Scott Cain, Ph. D. scott at<br>
> > > > scottcain<br>
> > > > > > dot<br>
> > > > > > > > net<br>
> > > > > > > > GMOD Coordinator (<a href="http://gmod.org/" target="_blank">http://gmod.org/</a>)<br>
> > > > 216-392-3087<br>
> > > > > > > > Ontario Institute for Cancer Research<br>
> > > > > > > ><br>
> > > > > > > ><br>
> > > > > ><br>
> > > ><br>
> > ------------------------------------------------------------------------------<br>
> > > > > > > > Register Now for Creativity and Technology (CaT), June 3rd,<br>
> > 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<br>
> > 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>
> > ><br>
> > ><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>