GIF movies now have excess whitespace around image
Closed this issue · 19 comments
With the change in ddaee00 on feature/lightcurve_converter to make the GIF movies work on Matplotlib > 3.4, we now have an excess amount of whitespace at the top of movies compared to the older version (matplotlib<3.3) that is pinned on main. Screen shots of "old" (from 20220721/65803_2947583_framemovie.gif) and "new" (from 20221002/65803_3015270_framemovie.gif) attached
Look at that tail...
Look at that tail...
While I am not sure I should be encouraging this, there are deeper multicolor tail data in https://observe.lco.global/requests/3015287 when I put in a gri sequence to see if the scheduler was working when it was looking empty yesterday afternoon
How does this look?
I'm having issues getting pyslalib.slalib working so I can't do a proper test with lightcurve extraction, and not having it makes all of the
try:
import pyslalib.slalib as S
except:
pass
statements deceptively successful.
The method that sup_titles get applied and default axes scaling was changed.
The size is a little different, but I don't think it's bad. I can make it bigger if you like.
I also learned about the very interesting astropy.Time package...
Update:
the gca(projection=wcs) that applies the moving grid is also breaking in matplotlib 3.4.0.
Looking for a work around.
Update: the
gca(projection=wcs)that applies the moving grid is also breaking in matplotlib 3.4.0.Looking for a work around.
I fixed that in this commit: ddaee00
oh neat.
The method that sup_titles get applied and default axes scaling was changed. The size is a little different, but I don't think it's bad. I can make it bigger if you like.
That looks a lot better. What would help the most for the Didymos observations would if the secondary title include the frame number (the 0xyz out of the middle of the filename) as well. When clipping the output photometry, I only have a filename and JD available so matching with the frame in the animation is harder...
oh neat.
They did a bit of a dirty on us... If you remove the over-zealous warnings-ignoring in our code, it says what we were doing was deprecated in 3.4 and would fail after 2 minor releases. We're on 3.5.x something so within that, unless they meant 3.4.1 and 3.4.2 and then break...
I was not in the right branch for that test.
Results:
Could you make the frame reference an "always 4 digit, always zero prefixed" number (forget the right f-string needed) so it's (a little) more distinct from the "(1 of 8)" video frame </pedant>
easy:
Slightly different format. Maybe cleaner?
Like the frame number, don't like the non-ISO 8601 date, needs to be YYYY/MM/DD HH:MM:SS as 24hrs (unless that AM is something other than 'am and 'pm')
Oh that's interesting. That code is the same...
I know the %x and %X uses assumptions about local time formats, but I'm not sure why that would be different here.
I know the
%xand%Xuses assumptions about local time formats, but I'm not sure why that would be different here.
Probably server doesn't have a LOCALE set (or a generic one) and locally it has "America" or "Pacific/Los Angeles" timezone or some such . I think explicit setting of the format with a format string that can be re-used/altered in 1 place in the code would be best.
better to just be explicit.