Big deletion shifts the plot to the right

[Mohamed-HAMICI]

Description

Hello,

I don't know if I am missing something when doing my plots, but when I plot any track for a prediction on a big deletion, the tracks of the ALT allele always seem to shift to the left.
This makes reading the tracks very hard, especially if we are trying to visually detect any difference between the REF and ALT allele tracks.

Here is an examples of an output of track type "rna_seq" on a approximately 1800 bp deletion.

As you can see, the expression of the last three exons is similar between REF and ALT, but it is all shifted to the left, and therefore not overlapping.

Thank you for your help and for your amazing work.

longest_transcripts = transcript_extractor.extract(interval)

plot_components.plot(
    [
        plot_components.TranscriptAnnotation(longest_transcripts),
        plot_components.OverlaidTracks(
            tdata={
                'REF': variant_output.reference.rna_seq,
                'ALT': variant_output.alternate.rna_seq,
            },
            colors={'REF': 'blue', 'ALT': 'red'},
        ),
    ],
    interval=gene_annotation.get_gene_interval(gtf, "ITPA"),
    annotations=[plot_components.VariantAnnotation([variant], alpha=0.8)],
)
plt.show()

System info (python version, alphagenome version, etc.)

Python 3.12.2
AlphaGenome 0.4.0

[tomwardio]

Hi @Mohamed-HAMICI, thanks for the bug report!

Yes we're aware of this frameshift (see this community post) but it hasn't yet been fixed.

As mentioned in the post above, you can somewhat mitigate the issue by manually padding/trimming the predictions to do the alignment, but it's rather awkward to do.

[Mohamed-HAMICI]

Hello @tomwardio ,

Sorry for the late response.

I tried the solution in the community post, but as it is mentioned there, the solution shifts the left part of the plot to the right, instead of completely correcting the error.

I wrote a correction based on that, where I basically replace the length of the deletion by zeros, and then remove a part of the prediction of the same size at the end to keep the correct interval. That looks like this for 1bp resolution outputs:

def correct_1bp_res(alt_assay, variant): # Works for all but chip_histone, chip_tf and contact_maps
    """
    alt_assay : Should be like this 'variant_output.alternate.rna_seq' . replace 'rnaseq' with your output of interest
    variant : Variant object of AlphaGenome
    """
    try:
        interval = alt_assay.interval
        modified_alt_assay = track_data.TrackData(
            np.concatenate([
                alt_assay.values[:(variant.start - interval.start)],
                np.zeros((len(variant.reference_bases), alt_assay.values.shape[1])),
                alt_assay.values[(variant.start - interval.start):-(len(variant.reference_bases))],
            ]),
            metadata=alt_assay.metadata,
            interval=interval,
            resolution=1 #TODO: what about uns? should I add it?
        )
        return modified_alt_assay
    except Exception as e:
        print(f"Error: {e}")
        return False

Feel free to tell me if the correction seems wrong to you.

I tested it and it works fine for me. The problem is for other tracks with a resolutions > 1bp. Even when I take into consideration the resolution when I splice the np array, I still get a tiny shift on the right side of the deletion.

I tried this:

def find_in_intervals(value, intervals):
    for i, (start, end) in enumerate(intervals):
        if start <= value <= end:
            return i
    return None

def correct_128bp_res(alt_assay, variant):
    try:
        step = 128
        interval = alt_assay.interval
        intervals = [
            (i, i + step - 1)
            for i in range(interval.start, interval.end, step)
        ]
        interval_start = find_in_intervals(variant.start, intervals) + 1
        interval_end = find_in_intervals(variant.end, intervals) - 1

        variant_interval_size = interval_end - interval_start + 1

        modified_alt_assay = track_data.TrackData(
            np.concatenate([
                alt_assay.values[:interval_start],
                np.zeros((variant_interval_size, alt_assay.values.shape[1])),
                alt_assay.values[interval_start:-variant_interval_size]
            ]),
            metadata=alt_assay.metadata,
            interval=interval,
            resolution=step #TODO: what about uns? should I add it?
        )
        return modified_alt_assay

    except Exception as e:
        print(f"Error: {e}")
        return False

As the correction didn't work for 128bp resolution, I tried another workaround that seems to do the trick: When declaring my variant, I declare "alternate_bases" as a sequence of "N"s of a length equivalent to that of the deleted sequence like this:

#Using pysam I fetch the deleted sequence and define it as 'deleted_seq'
filler_seq = len(deleted_seq)*"N"

# Defining the variant:
variant = genome.Variant(
    chromosome=contig_val',
    position=position,
    reference_bases=deleted_seq,
    alternate_bases=filler_seq,
    name="test_del"
)

It seems to work well this way, no need for any type of correction to get a correct graphical representation, but I am not sure if it changes the rest of the prediction.

Do you think this a valid way to declare deletions? Does the prediction differ when declaring the alternate_bases as an empty string vs "N"s?

Thanks in advance for your time.

[KumarADITHYA123]

Hi @Mohamed-HAMICI, @tomwardio

I’ve just opened a PR (linked above) that solves this alignment issue natively in alphagenome.visualization.

This solution works for any resolution (1bp, 128bp, etc.) without needing manual array slicing or padding with zeros. Instead of hacking the variant with "N"s—which might affect the model's actual coordinates—this new utility mathematically maps the ALT track's coordinates onto the REF grid for plotting purposes only.

Key features:

Accurate Alignment: It uses interpolation, so it handles the "tiny shifts" you saw at lower resolutions automatically.

Clear Visuals: It marks deleted regions as gaps (NaN) instead of zeros, so you can clearly distinguish "deleted sequence" from "zero value."

Safe: It doesn't touch the underlying model inputs or predictions.