FITS files can contain several images (or more generally n-dimensional arrays) and tables.
Is there a way to automatically open images e.g. with the ds9 application and tables with the TOPCAT application when I double-click the FITS file in the Mac OS X Finder?
I'm thinking of something like FITS Explorer from AstroSoft, but free and nicely integrated into the Mac (i.e. Finder, Quicklook).
If such a thing doesn't exist, what is your workflow for browsing and opening images and tables in FITS files?
I just found QLFits which is a Mac OS X Finder QuickLook plugin that display some FITS header info and an image simply by hitting SPACE after selecting a FITS file in the Finder.
The same guy wrote FITSImporter:
a Spotlight plugin that allow you make spotlight queries against dedicated FITS header keywords. It provides also additional information in the "Get Info" panel of the Finder (⌘-I).
Both are open source (GPL licence), the code is available on github: QLFITS, FITSImporter.
They are not perfect though (e.g. I didn't see a way to get at the different extensions in a multi-extension FITS file, although the description says there is; and you can't use QLFits to browse tables) and development seems to have stopped, but still well worth a try!
Apart from recommending you QLFits, you could try to write an AppleScript application, or Automator action using any scripting language, which explored the FITS file, and sent table-based FITS to TOPCAT, and image-based FITS to DS9, and make that application the default for FITS files.
Related
In my Electron app, I am trying to use dialog.showOpenDialog() to allow users to choose the image file that they want to open. On Ubuntu 18.04, when they choose an image file, a preview of the image would appear on the right side like so:
https://i.stack.imgur.com/RG6Po.png
However, if the user chooses a file that is too large (typically 1GB+), my app would crashes, with the following being printed on the command line:
tcmalloc: large alloc 1073741824 bytes == 0x32f584ab4000 # 0x7fb5985b16cf
I tried disable thumbnail generation in the Search & Preview tab of the file manager but it didn't disable this right-hand-side preview in the dialog box.
My app works with very large raster files so being able to choose these image files is crucial. I have considered either installing a new file manager or moving my code to another OS, but I want to ask beforehand if there is any less drastic solution that I can take?
The previews are being added to the GtkFileChooserDialog by Electron itself, so changing your file manager or its settings won't have an effect. Changing OS would work, of course, as drastic as it is.
It does seem like Electron should offer an option for turning off previews among the platform-specific ones in dialog.showOpenDialog. At the minimum, it should enforce a reasonable cutoff on file sizes for previews.
To accomplish that, you'd have to patch Electron locally (and then ideally submit a PR). Whatever you decide to do, I don't see a bug reported about this in the Electron repo, so doing that could be helpful to anyone else who runs into the problem.
I'd like to have my own file extension which holds my own data. With double clicking it will start with my own software. So far no problem.
How can i save a picture in that file (metadata?) in a way that it is shown in the OS (Windows, Mac) like a .jpg in the preview window (big symbols in windows, or in the window of the space key preview in macOS)?
The image is generated by my software and therefore is for the user to have a quick info of the internal data...
Thanks in Advance for your help!
Operating systems sometimes allow you to write plugins that read your file data and then convert it to a form that the OS knows how to display in a thumbnail. As for getting your file format to open in existing applications such as Photoshop, this will generally not be possible unless the application developers either choose to add support for your format themselves or allow you to write a plugin, which you will need to do yourself. Most existing file formats that are supported natively in operating systems and user programs have well-known, popular standards and users expect that their software will support these formats by default.
I'm working on a program that acts as a Windows Accessibility / UI Automation API client, consuming accessibility data from other programs (much like a screen reader does). I'm looking for a way to get the full path of the current "document" (or other file) open in a program. So, for example, Word might give me the path to the current .docx file, Paint the path to the current image file, WMP the path to an audio or video file... you get the idea. Is there a way to do this?
On a Mac, I'd use NSAccessibilityDocumentAttribute, but Windows doesn't seem to have an equivalent accessibility property. A few other questions I looked at:
Getting the path & filename of the open document in any Windows application (last answer in 2009, may have been unaware of accessibility APIs, no answer gives reliably accurate data)
How to get filename and path of file opened in Notepad? - five years old, specific to one program, only answer given is incomplete.
So... is there any equivalent to NSAccessibilityDocumentAttribute, and if not, is there a reasonable way to re-implement it (possibly doing stuff outside of the accessibility tree / API)? It's more important that this return correct information (i.e. never give me a file that isn't open in the relevant program/window) than that it be universally available.
I'm using C# (via System.Windows.Automation for accessibility) but could use other languages if needed, so long as they'll run on Windows 10 (downlevel support nice but not mandatory).
I have a shoebox type (as opposed to document based) OS X app that stores images in the app's sandbox container.
These images can be shared via Share Extensions (in form of a NSURL) or exported via drag and drop.
When an image is shared to an image editor (e.g. Acorn offers a Share Extension), or dropped on an image editor, the image editor opens the file from within my sandbox container and can now alter, rename or delete this file - which can lead to all kinds of inconstancies in my app.
First, I was surprised, because I thought, files in the sandbox can only be accessed by the app itself. But it seems this is not the case, when I intentionally share the NSURL.
So how can I prevent that someone can alter files in my sandbox container while still offering them for drag and drop and to Share Extensions?
I tried not sharing NSURLs but NSImages, but many Share Extensions do not work with NSImages, so this is not a good option.
Is it a possibility to write-protect the files in the sandbox?
Should I always make a copy of an image to a temporary location, before I offer it for sharing or drag and drop (could be slow for big images?)
I am happy to hear your suggestions or learn more about the problem.
Create a bookmark of the NSURL.
So the user can still rename, move and delete the file, but you notice it and know the new location and name and still are able to access the file. Should work even if it's outside your sandbox.
So you can handle this.
https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSURL_Class/
That's one of the benefits working with NSURL and not with a simple path string.
I want to create an application on a Mac to convert multiple files (txt, pdf, doc, html, etc) to a single pdf file that can be printed. The real point is that if you have 50 texts you don't have to open every single file and click command-p.
I'm not quite sure whether the best way to do this is by creating a full-fledged app or an automator plugin (or something else). If I remember correctly there's a filter in mac os's terminal that can convert files to pdf (but I forgot what it's called).
So would an automator plugin do this well, or shall I make an app for this? Can you provide me advantages for each answer?
I've done cocoa touch programming before so I can write objective-c quite well.
Use appscript, either as an action in an automator script or standalone. The advantage is that it is very simple and will take you a fraction of the time to write an app.
Here is something very close to what you want. It sets up a drop-folder and each file dragged onto it is printed (you can use multiple-select to get what you want). It uses Apple Works 6 which doesn't support the file-types that you want.
To modify it to use the Preview application instead you need to change the tell command in the script and then google the dictionary for Preview to check which verb to use for printing.