[Gmod-gbrowse] [Gmod-help] Re: Hi-Res images of conservation tracks have the background turn blue.

Fri May 29 17:54:49 EDT 2009

Ok. I'll poke around in GD::SVG to see what might be the problem with this
strategy. It ought to be ok.

Lincoln

On Fri, May 29, 2009 at 5:18 PM, Angie Hinrichs <angie at soe.ucsc.edu> wrote:

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

-- 
Lincoln D. Stein
Director, Informatics and Biocomputing Platform
Ontario Institute for Cancer Research
101 College St., Suite 800
Toronto, ON, Canada M5G0A3
416 673-8514
Assistant: Renata Musa <Renata.Musa at oicr.on.ca>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://brie4.cshl.edu/pipermail/gmod-help/attachments/20090529/cdf7c6f3/attachment.html>