Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SVG/PNG export lacks protein sequence detail #4

Open
alexpreynolds opened this issue Oct 6, 2020 · 5 comments
Open

SVG/PNG export lacks protein sequence detail #4

alexpreynolds opened this issue Oct 6, 2020 · 5 comments

Comments

@alexpreynolds
Copy link
Contributor

Here is a zoomed-in view of a region (snapshot of a web browser view). At the bottom, there is a horizontal-transcripts track showing Gencode v28 annotations, and we are at a scale where the protein residues are shown:

screencapture-epilogos-altius-org-3001-1602003592682

When an SVG or PNG export is performed, the same region lacks the residue detail. Here is an example of PNG export from the same region:

epilogos hg38 15 S1 all chr3_71112472-chr3_71112695 (1)

Doing an SVG/PNG export from this test view also shows the same effect: http://3.123.173.56/transcripts.html

@alexander-veit
Copy link
Member

I am aware of this. Just did not have time to implement this, as this is quite a lot of work.

@alexpreynolds
Copy link
Contributor Author

No problem — I can take a stab at this.

@alexander-veit
Copy link
Member

Pete is doing something very simple in the pileup track: https://github.com/higlass/higlass-pileup/blob/471237ea50189f1f8a43eb64b867089837388807/src/PileupTrack.js#L725
Maybe we could use that here as well? It would simplfiy the whole svg export a lot.

@alexpreynolds
Copy link
Contributor Author

alexpreynolds commented Nov 2, 2020

I think that one advantage of SVG is that it is a vector-based format. The approach Pete uses appears to generate a bitmap figure, which would result in fuzzy images if used for publication with this track type.

(If I'm wrong about that, sorry — please let me know.)

A bitmap is probably okay for a pileup track type, which is (if I remember correctly?) a set of line elements that don't necessarily need to be rendered at arbitrary quality. Those should scale pretty well. For this track type, I suspect that the layout of non-rectangular elements in combination with text would make a vector format perhaps a better choice for figure-making.

I've been a bit quiet but have been working on some modifications to the track type (including for this issue). These will help us (my project lead and I) get away from complications in some bigBed support I once wanted to add to the core of higlass, to help us migrate instead to the higlass-transcripts track type for some of the data we want to render. That way, we can start to use Pete's resgen service to host some of our tracks. Some functionality will also help make a track that looks a little closer to what the UCSC Genome Browser displays, which would be familiar to those users.

There are a few more details to work out. I'm hoping to get a PR in soon, perhaps within the week.

@alexander-veit
Copy link
Member

Yeah, you might be right about the issues with the bitmap figure. I haven't thought about that. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants