One of the simplest ways to use JS9 locally is by means of the file:// URI scheme, e.g., point your browser to file:///home/me/js9/js9.html.
This does not work in Google Chrome because Chrome does not permit a local HTML file to read other local files. You can read a relatively emotional argument about this restriction at:
https://code.google.com/p/chromium/issues/detail?id=37586
The workaround is to start Chrome with the --allow-file-access-from-files switch. On Linux:
chrome --allow-file-access-from-files
On a Mac:
open /Applications/Google\ Chrome.app --args --allow-file-access-from-files
It also does not work on Firefox starting with version 68. See:
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Errors/CORSRequestNotHttpfor details. The workaround (as discussed in that security page) is to turn off the privacy.file_unique_origin preference in about:config.
It also doesn't work with Safari for some versions of JS9, i.e., it seems to work with v3.3 and v3.4 but not v3.3.1. No idea why, but if you have enabled the Develop menu in Safari, you can choose Disable Local File Restrictions. (For Develop menu: choose Safari -> Preferences, click Advanced, then select "Show Develop menu in menu bar").
You can bypass the whole file:// CORS problem by using a Python web server instead. For example, if you start the server in the js9 directory:
python3 -u -m http.server 8000you then can load the js9.html page at:
http://localhost:8000/js9.html
When the js9 script is run with the -b (start a browser) switch on a Mac:
js9 -b --webpage js9.html
we would like to use Safari as the target browser. But executing this command
under the hood:
open -a Safari --webpage js9.html
causes both Safari and your default browser to start up. We therefore use
Chrome instead. If you really want to use Safari, you can run:
js9 -b safari --webpage js9.html
or set the JS9_BROWSER environment variable to "safari". In either case,
try to ensure that Safari is actually running before running js9 with -b,
as this seems to work properly.
The Electron.js-based JS9 desktop app has some limitations when a second instance is started up. The most obvious concerns the Preferences plugin, which uses localStorage to save parameters between sessions. Unfortunately, Electron.js apps do not properly return localStorage values for the second (and subsequent) instance. We therefore have disabled the ability to load and store preferences via localStorage in all but the first running instance of the JS9 app.
Chrome's memory restrictions remain more stringent than those of Firefox or Safari. On a Macbook Pro, it is possible to reproject a 4096x4096 32-bit image in Firefox and Safari, whereas Chrome gets the "snap" error for 32-bit images larger than approximately 3800x3800. We will continue to try to reduce memory usage, while hoping for less restrictive limits (or even full support for unlimited memory via mmap()).
One of the simplest ways to use JS9 locally is by means of the file:// URL scheme, e.g., point your browser to file:///home/me/js9/js9basics.html.
On Linux, although this works in Firefox for files in the web page's domain, it does not work for files outside the domain:
JS9.Load("foo.fits") # works
JS9.Load("fits/foo.fits") # works
JS9.Load("../foo.fits") # does not work
Firefox does appear to load files outside the web domain properly on a Mac.
Webkit browsers such as Safari and Chrome implement resizeable divs in an unintuitive way, which required several hacks in order to allow us to resize the JS9 display on the fly. The resizeable (enclosing) div must be larger than the JS9 display canvas, or else the resize handle cannot be seen. As a result, the resize handle juts out from the JS9 display in an unappealing way. Also, the resize operation can only increase the size of the display, not decrease it. To work around this, you can first decrease the display size using the View menu, which sets a new minimum size for GUI-based resize. Finally, the cursor is not changed to a resize cursor. I couldn't figure out how to work around this in a fool-proof way. We hope Webkit will implement more intuitive behavior in the near future.
A maximum image size is enforced by Apple on Safari mobile devices. (See https://discussions.apple.com/thread/4975106 for a discussion.) Images should be restricted to a size of less than approximately 1900x1900, depending on the size of the FITS header. So an image file of size 1024x1024 should be fine, while a file of size 2048x2048 certainly will be too large.
Resolved Issues:
On Mac OSX, if the Terminal running the js9 messaging script is located in a different Space (i.e. desktop) from the Safari browser with which it is communicating, the transfer of results from the browser to the script can be delayed up to several seconds. It does not happen all the time and it does not happen if the two applications share the same Space. The data transfer also will resume immediately if you switch to the Space containing the browser. The obvious work-around is to make sure that the Terminal and browser share the same Space.
The problems appears to have gone away with MacOS 10.14 (Mojave).
Available memory can be a problem when loading very large gzip'ed FITS files, especially in 32-bit Chrome. JS9 currently reads the entire FITS file or gzip'ed file and inflates parts as needed. It can process files up to approx. 200Mb in size before Chrome runs out of heap space. Note that Chrome often will load an ungzip'ed FITS file in cases where the gzip'ed file fails (though there still are upper limits on the total space available). We hope that the 64-bit version of Chrome (in early Canary release as of 7/1/2014) will alleviate these problems. Otherwise, we will take a more drastic approach to memory management within JS9 (at the expense of speed).
The 64-bit Chrome can make use of 2Gb of memory.
When resizing a box region in one direction only (i.e., width or height), the width of the region's border will be different in each direction. This is due to the underlying graphics algorithm used to resize the region, which changes the scale factor in each direction individually and ties the border width to that scale factor. We will fix this in a future release.
Fixed in Fabric.js v4.x
If the "load image" command is part of a group of commands passed to the js9 script, a race condition can occur when subsequent commands are executed before the image is fully loaded. To avoid this problem, images should be loaded in a separate js9 command and the load status checked for completion before proceeding to manipulate the image. See the js9load script for details (or just use the script itself to load images). (Technical details: images are loaded asynchronously, so that other parts of the web page are available during the load process. A synchronous load could freeze the web page while loading. To avoid this situation, external processes should use the "status load" command to check for a completed load before sending further processing commands).