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

ValueError: Input data is not 2-dimensional on add_image_layer #288

Open
davidenitti opened this issue Feb 12, 2021 · 25 comments
Open

ValueError: Input data is not 2-dimensional on add_image_layer #288

davidenitti opened this issue Feb 12, 2021 · 25 comments

Comments

@davidenitti
Copy link

When I use layer = wwt.layers.add_image_layer(image=image_path) on an rgb fits (3D array) file I get the error:
ValueError: Input data is not 2-dimensional
is there a way to load rgb fits or a way to load the color channels separately and get an rgb image?

@pkgw
Copy link
Contributor

pkgw commented Feb 15, 2021

Hi Davide,

To load an individual channel, you'll have to open the FITS file yourself and be a bit more explicit about which data to use. Something like:

from astropy.io import fits
from astropy.wcs import WCS

with fits.open(image_path) as hdu_list:
    hdu = hdu_list[0]
    wcs = WCS(hdu.header)
    data = hdu.data[...,0]  # pick out the specific plane we want

layer = wwt.layers.add_image_layer((data, wcs))

Or you could average the three color channels together (data = hdu.data.mean(axis=2)), etc.

The WWT rendering engine does not support rendering FITS data into individual color RGB color channels into a single image. If you don't want or need to be able to adjust the stretch/colorscale on the fly, you could achieve that effect by pre-converting the data into a JPEG-type image and loading that image into WWT, probably using toasty to do that data processing.

Hopefully that answers your question, but please follow up here if you have any more!

@davidenitti
Copy link
Author

thanks, since is not possible to work with RGB directly, is it possible to render RGB images one channel at the time (e.g. calling 3 times add_image_layer) with WWT but still have a colored image in the end?
otherwise I have the jpeg file and I have the wcs header or fits file, so to load the image I should use toasty?
what do you mean with adjust the stretch/colorscale on the fly?
thanks for the help!

@pkgw
Copy link
Contributor

pkgw commented Feb 15, 2021

I suppose you could create three image layers, set them all to have partial opacity, and use different color maps for each. It would not be the same as proper RGB display, but it might be good enough depending on your goals.

Is your original data a JPEG file? If so, using toasty would probably be the best approach. JPEG images are treated a little differently than FITS files but I can walk you through how to display your image.

By adjusting the stretch and colorscale on the fly, I mean that you can dynamically adjust how the FITS data are turned into colors: so that you can emphasis light or dark regions, choose how values are turned into colors, etc. If you are using raw astronomical data with a high dynamic range, this is almost always necessary. If your original data is a JPEG file or similar, this is probably not something that you need to do.

@davidenitti
Copy link
Author

I have fits/tiff or jpeg, it's not a problem convert from one format to another. but I assume that in the fits I can integrate the coordinates.
do you have an example to use toasty to do this?
thank you very much!

@pkgw
Copy link
Contributor

pkgw commented Mar 24, 2021

Hi Davide,

Two questions for you:

  1. To use toasty for the conversion, I can show you an example based on using the toasty command-line tool, or running a short piece of Python code. The former is probably better unless you want to automate the conversion of a lot of images or learn more about how the conversion works "under the hood". Which would you like to see?
  2. I can show you an example that converts a three-channel FITS file, or one that takes an RGB image (JPEG, TIFF, whatever) for the data and uses FITS file just for the WCS. Do you have a preference? (It is possible to store the coordinates directly in RGB images using AVM tags but these are unfortunately still pretty rare.)

@davidenitti
Copy link
Author

for the first question, I prefer python, but if you have also the command line would be great as well.
for the second, I would go for a 3 channel FITS for the moment.
thanks!

@pkgw
Copy link
Contributor

pkgw commented Apr 5, 2021

Hi Davide,

Here's an example program along those lines:

#! /usr/bin/env python

"""
Convert a FITS file with three data planes, treated as R/G/B, into a "study"
format viewable in WWT.
"""

from astropy.io import fits
from astropy.visualization import make_lupton_rgb
from astropy.wcs import WCS
from toasty.builder import Builder
from toasty.image import Image
from toasty.pyramid import PyramidIO

def process_rgb_fits(fits_path, output_path):
    # Load fits image and coordinates

    with fits.open(fits_path) as hdu_list:
        hdu = hdu_list[0]
        wcs = WCS(hdu.header)
        data = hdu.data
        # The tuning parameters here are specific to my sample file:
        rgb = make_lupton_rgb(
            data[...,0], data[...,1], data[...,2],
            minimum = 1.6 * data.min(),
            stretch = 100,
        )

    # Now `rgb` is a 1000×1000×3 uint8 image, and `wcs` gives WCS coordinates
    # specifying its position on the sky. Convert to WWT "study" format using Toasty:

    wcs = wcs.dropaxis(2)  # drop non-sky axis from WCS

    # EDIT: XXX This is wrong! See comment below.
    rgb = rgb[::-1]  # vertical flip from FITS raster convention to JPEG-like
    # END EDIT

    img = Image.from_array(rgb, wcs=wcs, default_format='png')

    pio = PyramidIO(output_path, default_format='png')
    builder = Builder(pio)
    builder.make_thumbnail_from_other(img)
    builder.set_name('My RGB Image')
    builder.tile_base_as_study(img, cli_progress=True)
    builder.apply_wcs_info(img.wcs, img.width, img.height)
    builder.cascade(cli_progress=True)
    builder.write_index_rel_wtml()


if __name__ == '__main__':
    process_rgb_fits('w5_rgb.fits', 'tiled')

For the sake of convenience I've used the Astropy Lupton function to get the FITS data into 24-bit RGB color, but for that part you can use whatever suits your needs.

Running this program will create a directory named tiled containing the WWT data including a file named index_rel.wtml. You can preview this image in WWT using the command:

wwtdatatool preview tiled/index_rel.wtml

where the wwtdatatool command is provided by the helper Python package wwt_data_formats. If you want to publish the resulting "study", I can explain how to do that — this document gives some hints although it's aimed at a slightly different use case.

I hope this helps!

@davidenitti
Copy link
Author

thanks!
I generated the image from the fits, however the preview does not seem to show my image, even though it goes more or less on the right point of the sky.
the thumb generated seems empty:
thumb
am I doing something wrong?
thanks you very much for your time!

@davidenitti
Copy link
Author

davidenitti commented Apr 6, 2021

I found the error, there was a mistake in the channels dimension. the fixed part is

rgb = make_lupton_rgb(
            data[0], data[1], data[2],
            minimum = 1.6 * data.min(),
            stretch = 100,
        )

instead of

rgb = make_lupton_rgb(
            data[...,0], data[...,1], data[...,2],
            minimum = 1.6 * data.min(),
            stretch = 100,
        )

@davidenitti
Copy link
Author

davidenitti commented Apr 6, 2021

I have another issue, the image is not aligned correctly. the image seems to be flipped vertically, I had to remove the line:
rgb = rgb[::-1] # vertical flip from FITS raster convention to JPEG-like
but the image it's still not well aligned. (I'm sure the coordinates are correct in the fits file, I checked).
This is an example of the mismatch that shows the overlay between the background stars and the stars on my image (blue stars)
Screenshot from 2021-04-06 20-19-26
do you have an idea why? maybe with the command line solution I will be more lucky?
the resulting file is index_rel.wtml

<?xml version='1.0' encoding='UTF-8'?>
<Folder Browseable="True" Group="Explorer" MSRCommunityId="0" MSRComponentId="0" Name="My RGB Image" Permission="0" Searchable="True" Type="Sky">
  <Place Angle="0.0" AngularSize="0.0" DataSetType="Sky" Dec="47.300374835987064" Distance="0.0" DomeAlt="0.0" DomeAz="0.0" Lat="0.0" Lng="0.0" Magnitude="0.0" MSRCommunityId="0" MSRComponentId="0" Name="My RGB Image" Opacity="100.0" Permission="0" RA="12.28671511305029" Rotation="0.0" Thumbnail="thumb.jpg" ZoomLevel="15.449169574370567">
    <ForegroundImageSet>
      <ImageSet BandPass="Visible" BaseDegreesPerTile="3.0895925404568905" BaseTileLevel="0" BottomsUp="False" CenterX="184.3004672519" CenterY="47.30057525329" DataSetType="Sky" ElevationModel="False" FileType=".png" Generic="False" MeanRadius="0.0" MSRCommunityId="0" MSRComponentId="0" Name="My RGB Image" OffsetX="0.00018857376345562076" OffsetY="0.00018857376345562076" Permission="0" Projection="Tan" Rotation="-93.72163874386334" Sparse="True" StockSet="False" TileLevels="5" Url="{1}/{3}/{3}_{2}.png" WidthFactor="2">
        <ThumbnailUrl>thumb.jpg</ThumbnailUrl>
      </ImageSet>
    </ForegroundImageSet>
  </Place>
</Folder>

header of fits if relevant:

SIMPLE  =                    T / FITS header                                    
BITPIX  =                  -32 / Bits per entry                                 
NAXIS   =                    3 / Number of dimensions                           
NAXIS1  =                 6072 / length of x axis                               
NAXIS2  =                 4016 / length of y axis                               
NAXIS3  =                    3 / length of z axis (mostly colors)               
EQUINOX =               2000.0 / Equinox of coordinates                         
DATAMIN =                    0 / Minimum data value                             
DATAMAX =                16368 / Maximum data value                             
BZERO   =                    0 / Scaling applied to data                        
BSCALE  =                  1.0 / Offset applied to data                         
COMMENT 1   Written by ASTAP. www.hnsky.org                                     
DATE-OBS= '2021-04-03T00:13:02'                                                 
HISTORY   Converted from /media/davide/Seagate/Photos/deep_sky/2021_04_02/M106/2
OBJECT  = 'M'                                                                   
CBLACK  =                    0 / Indicates the black point used when displaying 
CWHITE  =                 5831 / indicates the white point used when displaying 
CTYPE1  = 'RA---TAN'           / first parameter RA  ,  projection TANgential   
CTYPE2  = 'DEC--TAN'           / second parameter DEC,  projection TANgential   
CUNIT1  = 'deg     '           / Unit of coordinates                            
CRPIX1  =  3.036500000000E+003 / X of reference pixel                           
CRPIX2  =  2.008500000000E+003 / Y of reference pixel                           
CRVAL1  =  1.843004672519E+002 / RA of reference pixel (deg)                    
CRVAL2  =  4.730057525329E+001 / DEC of reference pixel (deg)                   
CDELT1  =  3.771480845439E-004 / X pixel size (deg)                             
CDELT2  =  3.771469695774E-004 / Y pixel size (deg)                             
CROTA1  =  9.372163874386E+001 / Image twist of X axis        (deg)             
CROTA2  =  9.371936062797E+001 / Image twist of Y axis        (deg)             
CD1_1   = -2.446541028738E-005 / CD matrix to convert (x,y) to (Ra, Dec)        
CD1_2   =  3.763516327554E-004 / CD matrix to convert (x,y) to (Ra, Dec)        
CD2_1   = -3.763537184281E-004 / CD matrix to convert (x,y) to (Ra, Dec)        
CD2_2   = -2.448030195484E-005 / CD matrix to convert (x,y) to (Ra, Dec)        
PLTSOLVD=                    T / ASTAP internal solver                          
COMMENT 6  Solved in 0.6 sec. Offset was 0.000 deg.                             
CALSTAT = 'DFBS'                                                                
HISTORY 1   Stacking method SIGMA CLIP AVERAGE                                  
HISTORY 2   De-mosaic bayer pattern used RGGB                                   
HISTORY 3   Colour conversion: AstroC, colour for saturated stars. interpolation
EXPTIME =                    0 / Total luminance exposure time in seconds.      
LUM_EXP =                    0 / Average luminance exposure time.               
LUM_CNT =                   86 / Luminance images combined.                     
LUM_DARK=                   31 / Darks used for luminance.                      
LUM_FLAT=                  106 / Flats used for luminance.                      
LUM_BIAS=                   67 / Flat-darks used for luminance.                 
LUM_TEMP=                  999 / Set temperature used for luminance.            
END                                                                             

@pkgw
Copy link
Contributor

pkgw commented Apr 7, 2021

Hi Davide — hmm, what is the scale of the misalignment? There is a known (and very annoying!) astrometric error in the default DSS optical sky map at the level of ~1.5 arcsec ... but it looks like the issue you are seeing is a lot bigger than that, I think? If it's close, the "PanSTARRS 3pi" sky map has astrometry that is much more accurate.

When there's an image parity flip (i.e. the [::-1] flip of the Y axis) sometimes one also needs to change the CRPIXn values in the WCS data. If you don't need that flip I would think that you wouldn't need to do that either, but maybe there is an issue along those lines.

If your error is bigger than the known DSS error, would you mind sending me the file at pwilliams@cfa.harvard.edu? That will probably be the easiest path to identifying the problem.

@davidenitti
Copy link
Author

thanks! I sent you an email

@pkgw
Copy link
Contributor

pkgw commented Apr 8, 2021

Thanks! Sorry, I gave some wrong advice — I need to tighten up my thinking about image parity. We need to flip the WCS, not the data. The code in the middle should be like this:

    wcs = wcs.dropaxis(2)  # drop non-sky axis from WCS

    # Flip parity of the projection
    h = wcs.to_header()
    h['PC1_2'] *= -1
    h['PC2_2'] *= -1
    h['CRPIX2'] = rgb.shape[0] + 1 - h['CRPIX2']
    wcs = WCS(h)

    img = Image.from_array(rgb, wcs=wcs, default_format='png')

When I try this, it lines up perfectly!

The conversion of the FITS data to a nice RGB will require some manual exploration — check out the astropy.visualization package for some helpful routines.

@davidenitti
Copy link
Author

thanks! yes the image was original not stretched.
just few questions, if I can!
how can I do the same with multiple images? can I use wwtdatatool with multiple images?
is there a way to have a local version of it? maybe using wwt in python?
and final question is there a way to remove the background? I want a black background and show only my images.
thank you very much!

@pkgw
Copy link
Contributor

pkgw commented Apr 9, 2021

@davidenitti Sure, I'm happy to answer questions!

how can I do the same with multiple images? can I use wwtdatatool with multiple images?

The core processing only works one image at a time, and writes out a separate index_rel.wtml for each image. You can then use wwtdatatool wtml merge to merge those descriptions into a multi-image collection, and preview them as a folder.

is there a way to have a local version of it? maybe using wwt in python?

Do you mean, is there a way to view your images using local software, not through the worldwidetelescope.org webclient? Yes. For example, if you're using Python and pywwt, I think that the following should work:

  1. Serve your data locally using wwtdatatool serve
  2. Create a WWT widget and use the load_image_collection() to load your data into the viewer, using the URL for the index file given by your server
  3. Set the foreground value of your widget to the name of the image you want to view.

is there a way to remove the background?

WWT does have a "Black Sky Background" choice that is, well, just black. In pywwt I believe that you can just set the background attribute to "black".

@davidenitti
Copy link
Author

thanks!
so I managed to merge the images, have a local server with wwtdatatool serve
is this correct?
wwtdatatool serve --port 7005 PATH
I don't know which PATH I should put there.
but I don't know how to do the rest, I tested some code but is probably wrong e.g.:

from pywwt.qt import WWTQtClient
wwt = WWTQtClient(block_until_ready=True)
url_path = 'http://127.0.0.1:7005/index_rel.wtml'
wwt.load_image_collection(url_path)
wwt.background = 'Black Sky Background' 
wwt.wait()

with wwt.background = 'Black Sky Background' I have this error:

Access to image at 'http://black/' from origin 'http://127.0.0.1:46621' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. (level=2, line_number=0, source_id=http://127.0.0.1:46621/data/wwt.html)

if I put black I get:

Traceback (most recent call last):
  File "/home/davide/MEGA/python_projects/astrophotography/wwt.py", line 10, in <module>
    wwt.background = 'black' # Black does not work either
  File "/usr/local/lib/python3.8/dist-packages/traitlets/traitlets.py", line 604, in __set__
    self.set(obj, value)
  File "/usr/local/lib/python3.8/dist-packages/traitlets/traitlets.py", line 578, in set
    new_value = self._validate(obj, value)
  File "/usr/local/lib/python3.8/dist-packages/traitlets/traitlets.py", line 612, in _validate
    value = self._cross_validate(obj, value)
  File "/usr/local/lib/python3.8/dist-packages/traitlets/traitlets.py", line 618, in _cross_validate
    value = obj._trait_validators[self.name](obj, proposal)
  File "/usr/local/lib/python3.8/dist-packages/traitlets/traitlets.py", line 975, in __call__
    return self.func(*args, **kwargs)
  File "/usr/local/lib/python3.8/dist-packages/pywwt/core.py", line 434, in _validate_background
    raise TraitError('background is not one of the available layers')
traitlets.traitlets.TraitError: background is not one of the available layers

Process finished with exit code 1

regardless the background, I don't see the images in the wwt.
the code is probably wrong.

@davidenitti
Copy link
Author

do you have an idea how to solve the issue?

@pkgw
Copy link
Contributor

pkgw commented Apr 19, 2021

Sorry for the delay replying here. I think you're close!

First, for the black background, that CORS error with 'Black Sky Background' should be spurious. I think you can ignore it.

For the wwtdatatool serve command, I think that you are running it correctly, but just to be clear, you should replace PATH with the directory containing your index_rel.wtml file.

Once you have done that, try something like this:

from pywwt.qt import WWTQtClient
from astropy.coordinates import SkyCoord

url_path = 'http://127.0.0.1:7005/index.wtml' # NOTE: remove the `_rel` in the filename here
image_name = 'My RGB Image'  # this should be the "Name" of the image in the WTML file (which is just XML text)
image_pos = SkyCoord.from_name('M82')  # this can be any SkyCoord. `from_name()` looks up a position from SIMBAD/NED

wwt = WWTQtClient(block_until_ready=True)
wwt.load_image_collection(url_path)
wwt.background = 'Black Sky Background' 
wwt.foreground = image_name
wwt.foreground_opacity = 1
wwt.center_on_coordinates(image_pos)
wwt.wait()

Commentary:

  • The default pywwt configuration uses H-alpha as the "background", the DSS color map as the "foreground", and has the foreground at 80% opacity. So if you set the background to the "black sky" without changing anything else, you won't see much of an effect.
  • Setting the "foreground" to your image will load it up, but won't center the view on your image. To do that right now, we need to use a center_on_coordinates() call, which takes any AstroPy SkyCoord object.
  • Above I randomly chose M82 for the position but this will need to be customized for your actual data. There a variety of other ways to get a SkyCoord if needed.

I hope this helps!

@davidenitti
Copy link
Author

davidenitti commented Apr 19, 2021

thanks for the reply, but it does not work.
it runs without errors but I only see the deep sky background and I don't see my images.
I run wwtdatatool serve --port 7005 '/media/davide/Seagate/Photos/deep_sky/tiles/' and it seems to work properly:

127.0.0.1 - - [20/Apr/2021 00:10:48] "GET /index.wtml HTTP/1.1" 200 -
127.0.0.1 - - [20/Apr/2021 00:11:28] special WTML: local /media/davide/Seagate/Photos/deep_sky/tiles/index_rel.wtml, baseurl http://127.0.0.1:7005/index.wtml
127.0.0.1 - - [20/Apr/2021 00:11:28] "GET /index.wtml HTTP/1.1" 200 -
127.0.0.1 - - [20/Apr/2021 00:11:28] special WTML: local /media/davide/Seagate/Photos/deep_sky/tiles/index_rel.wtml, baseurl http://127.0.0.1:7005/index.wtml

on python the code you suggested runs without errors, but I only see the unwanted deep sky background, so the background is not black as expected and I also don't see my images. I get a black background only with wwt.foreground_opacity = 0, even though I still see the planets/moon (and I don't see my images). it's really weird.

note that wwtdatatool preview /media/davide/Seagate/Photos/deep_sky/tiles/index_rel.wtml works correctly, so the tiles are correct.

maybe there is an error here?

<?xml version='1.0' encoding='UTF-8'?>
<Folder Browseable="True" Group="Explorer" MSRCommunityId="0" MSRComponentId="0" Name="Folder" Permission="0" Searchable="True" Type="Sky">
  <Place Angle="0.0" AngularSize="0.0" DataSetType="Sky" Dec="47.30039931620193" Distance="0.0" DomeAlt="0.0" DomeAz="0.0" Lat="0.0" Lng="0.0" Magnitude="0.0" MSRCommunityId="0" MSRComponentId="0" Name="M106" Opacity="100.0" Permission="0" RA="12.286678115431538" Rotation="0.0" Thumbnail="M106/thumb.jpg" ZoomLevel="15.449169574370567">
    <ForegroundImageSet>
      <ImageSet BandPass="Visible" BaseDegreesPerTile="3.0895925404568905" BaseTileLevel="0" BottomsUp="False" CenterX="184.3004672519" CenterY="47.30057525329" DataSetType="Sky" ElevationModel="False" FileType=".png" Generic="False" MeanRadius="0.0" MSRCommunityId="0" MSRComponentId="0" Name="M106" OffsetX="0.00018857376345562076" OffsetY="0.00018857376345562076" Permission="0" Projection="Tan" Rotation="-86.27836125613668" Sparse="True" StockSet="False" TileLevels="5" Url="M106/{1}/{3}/{3}_{2}.png" WidthFactor="2">
        <ThumbnailUrl>M106/thumb.jpg</ThumbnailUrl>
      </ImageSet>
    </ForegroundImageSet>
  </Place>
  <Place Angle="0.0" AngularSize="0.0" DataSetType="Sky" Dec="-11.509704341723817" Distance="0.0" DomeAlt="0.0" DomeAz="0.0" Lat="0.0" Lng="0.0" Magnitude="0.0" MSRCommunityId="0" MSRComponentId="0" Name="Sombrero" Opacity="100.0" Permission="0" RA="12.665742400702774" Rotation="0.0" Thumbnail="sombrero/thumb.jpg" ZoomLevel="15.517410766714411">
    <ForegroundImageSet>
      <ImageSet BandPass="Visible" BaseDegreesPerTile="3.091692058140695" BaseTileLevel="0" BottomsUp="False" CenterX="189.9858915743" CenterY="-11.50982196023" DataSetType="Sky" ElevationModel="False" FileType=".png" Generic="False" MeanRadius="0.0" MSRCommunityId="0" MSRComponentId="0" Name="Sombrero" OffsetX="0.0001887019078455014" OffsetY="0.0001887019078455014" Permission="0" Projection="Tan" Rotation="108.86448118682021" Sparse="True" StockSet="False" TileLevels="5" Url="sombrero/{1}/{3}/{3}_{2}.png" WidthFactor="2">
        <ThumbnailUrl>sombrero/thumb.jpg</ThumbnailUrl>
      </ImageSet>
    </ForegroundImageSet>
  </Place>
</Folder>

@pkgw
Copy link
Contributor

pkgw commented Apr 20, 2021

@davidenitti If that's your WTML, are you setting image_name to either "M106" or "Sombrero"? It must match the Name="..." bit for one of the <Place> records in the WTML file. (Unfortunately the way things work right now, we can't provide very good diagnostics if a name is unmatched in the internal database.)

As a test, if you set wwt.foreground to "Black Sky Background", you should see the sky go black without needing to set the opacity — that will confirm that changing the foreground image is working at least some of the time.

@davidenitti
Copy link
Author

yes I set the name properly, that's not the problem I think.
of course if I set wwt.foreground to a name that does not exist I get an error.
if I set wwt.foreground = 'Black Sky Background' everything is black so it works (actually I see the planets that I don't know how to remove).
instead wwt.foreground = "Sombrero" or "M106" runs (I have no errors) but it does not show the image, I only see the deep sky background (even though www.background is set to Black Sky Background).
If I use wwtdatatool preview /media/davide/Seagate/Photos/deep_sky/tiles/index_rel.wtml I see the images.
I also tried to upgrade pywwt, but with no change.
I don't understand

@pkgw
Copy link
Contributor

pkgw commented Apr 29, 2021

My apologies, I've been tied up with a proposal this week, but next week I'll have some more time. I'm sure that this is very close to working the way that you want.

@davidenitti
Copy link
Author

thanks for the support!

@pkgw
Copy link
Contributor

pkgw commented Jun 10, 2021

Hi Davide,

I apologize that it took so long to follow up here. But I think I have a solution for you, if you're still looking for one!

I finally figured out the core issue here. The problem is that the wwt.load_image_collection() call triggers an asynchronous activity — WWT needs to go download the WTML file in the background. But the way that our Python layer currently works, the function returns immediately. So when you run the code all in one block, the attempt to set the foreground fails because the WTML hasn't been loaded yet.

This is a weakness in our Python API, since what you were doing (the code that I wrote!) is totally sensible but doesn't actually work.

When using Qt, one can work around this with a manual delay:

wwt = WWTQtClient(block_until_ready=True)
wwt.load_image_collection(url_path)
wwt.wait(duration=1) # NEW CODE: manual delay, duration measured in seconds
wwt.background = 'Black Sky Background' 
wwt.foreground = image_name
wwt.foreground_opacity = 1
wwt.center_on_coordinates(image_pos)
wwt.wait()

This is itself imperfect because it assumes that the WTML will take less than 1 second to load, but it should be "good enough" in many cases.

I feel foolish for not thinking of this sooner. And we also need to provide a better API here since the behavior is very surprising and not helpful for our users.

@davidenitti
Copy link
Author

thanks! I'll test it soon!

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