QL FITS etc not working

[Tailspin45]

Can't use Quick Look on FITS files

Tried

Code Select Expand

qlmanage -r;qlmanage -r cache and restarted Finder but no joy.

[Sander Berents]

Observatory has its own Quick Look plugin that handles FITS, XISF and SBIG images, not just FITS files. There is no need for QLFits if you have Observatory.

See https://codeobsession.com/forum/index.php?topic=96.0

Previously the problem was caused by QLFits or the system's LaunchServices database. QLFits uses the old Quick Look API that has been deprecated since macOS Catalina (10.15). Observatory 2 uses the modern Quick Look extension API. If you want to use QLFits, then please ask its developer. You can disable the Observatory plugin in System Settings > Privacy & Security > Extensions > Quick Look.

[Tailspin45]

I meant your QL plugin.

[Sander Berents]

• What is the macOS version?
• Which version of Observatory?
• When did it stop working?
• Are the extensions enabled in System Settings > Privacy & Security > Extensions > Quick Look?
• What is the output of qlmanage -m plugins|grep fits
• Are there any issues when you run Observatory?
• If you recently updated Observatory, did you run it before using Quick Look on an image?
• If it is the latest Observatory 2.x, are you running it with the old Observatory 1 license or did you upgrade to the Observatory 2 license?
• Any other issues like described in the linked topic, did you try any of the suggestions there? Those were for the Observatory 1 plugin of course, which still used the old API.

The Quick Look extension of Observatory 2.0.8 works fine for me on the supported macOS versions.

[Tailspin45]

• What is the macOS version?

Sonoma 14.5

• Which version of Observatory?

2.0.8 on 500GB internal SSD

• When did it stop working?

Some time ago. No particular event preceded it that I recall

• Are the extensions enabled in System Settings > Privacy & Security > Extensions > Quick Look?

Yes, Obs Previews and Obs Thumbnails. No other QL extensions

• What is the output of qlmanage -m plugins|grep fits

No output. It thought for a while and then presented the prompt again.

• Are there any issues when you run Observatory?

Yes.
1) It takes forever to load a library, even small a small. Beachball spins for 10-15 minutes, 11 this time before window appears, but beachball still spinning. 35 minutes later (I left to fix lunch) images are showing but beach ball still spinning.
2) It refuses to load most folders if they have more than a few Mb of data
3) Just created a new library and it took two hours and 15 minutes to add 15529 images.
4) It refuses to import some images with no obvious difference from any other images .
5) Some albums in the sidebar some number of images, about half don't
6) Some albums have no images in them although the original folder did.

• If you recently updated Observatory, did you run it before using Quick Look on an image?

Updated some time ago, so I don't remember.

• If it is the latest Observatory 2.x, are you running it with the old Observatory 1 license or did you upgrade to the Observatory 2 license?

Upgraded long ago

• Any other issues like described in the linked topic, did you try any of the suggestions there? Those were for the Observatory 1 plugin of course, which still used the old API.

Yes, tried all of those

• The Quick Look extension of Observatory 2.0.8 works fine for me on the supported macOS versions.
  

I would hope so!

I want to love this program, that's why I keep coming back to it. The QL plugin, the plate solving, the automatic tags, etc., but in doesn't take long for me to get frustrated with glitches and just stop using it.

[Sander Berents]

Where are you storing your images? Where are you storing the library? Both on a NAS or external SSD? The behavior you describe sounds like you store the library itself on a NAS with network issues. Observatory needs quick random access to its library, so don't store it on a NAS. I always use a directly connected external SSD. Images you can store on a NAS of course. Does it work if you use Quick Look with an image on your SSD? Maybe it fails because of a timeout.

What is the CPU core allocation in Observatory's Settings? Those have no impact on Quick Look, but if set too high for your system, importing could significantly slow down. The default is usually best, but if you work with large color images lowering it might be needed (higher settings allocate more cores, but also use more memory).

qlmanage -m plugins returns for me instantly on every machine I run the command. Could it be there's an issue with your system's LaunchServices database again? It only returns plugins that use the old API I think, so I don't expect Observatory to be in there, but at least we now know that the issue is not caused by a conflicting plugin.

[Tailspin45]

Where are you storing your images? Where are you storing the library? Both on a NAS or external SSD? The behavior you describe sounds like you store the library itself on a NAS with network issues. Observatory needs quick random access to its library, so don't store it on a NAS. I always use a directly connected external SSD. Images you can store on a NAS of course. Does it work if you use Quick Look with an image on your SSD? Maybe it fails because of a timeout.

The program is on the internal SSD of a 3.8GHz i7. The libraries are on a 550Gb SSD connected directly to the back of the computer. IOW not on a NAS, not even a hub involved.

What is the CPU core allocation in Observatory's Settings? Those have no impact on Quick Look, but if set too high for your system, importing could significantly slow down. The default is usually best, but if you work with large color images lowering it might be needed (higher settings allocate more cores, but also use more memory).

CPU core allocation is set to 'automatic.' Activity Monitor shows it using 882.9Mb (of 64Gb installed) in 4 threads at the moment. Previews use 26.4Mb in 3 threads. No swaps slowing things up, BTW.

qlmanage -m plugins returns for me instantly on every machine I run the command. Could it be there's an issue with your system's LaunchServices database again? It only returns plugins that use the old API I think, so I don't expect Observatory to be in there, but at least we now know that the issue is not caused by a conflicting plugin.

qlmanage -m plugins ran instantly for me too. Results attached. Observatory is not listed.

qlmanage -m plugins|grep fits also ran instantly now too, perhaps because Observatory wasn't in the midst of some endless process?

If it's of any use, I've also attached a crash report from back in February that I may or may not have sent along.

[Tailspin45]

P.S. Just selected list view, then CTRL-A to select all the sub frames, then selected icon view. Now it's in one of those aggravating endless beach ball situations.

After several minutes (~4) it finally finished doing whatever is was doing.

I then selected a single sub, held down the Cmd key and selected another and it went into the beach ball routine and didn't highlight the second sub. It took about 8 minutes this time to come to its senses.

I just repeated selecting two subs and it worked fine.

Selected another album and I'm in beach ball purgatory again.

Just emailed you several DiagnosticReports, if they might help

BTW, why do you list the files by the date the files were added to the computer, which is irrelevant, instead of the date in the FITS header? It's in the Overview, which is helpful, but not nearly as much as it would be if the sub were listed by capture date/time.

BTW#2, could you also report the number of subs selected along with total duration?

[Sander Berents]

I did a quick selection test with a large number of images, and it looks like the beach ball is caused by unnecessary UI updates when you select or deselect images. I'll look into this for the next update.

If the exposure date/time is displayed correctly in the inspector, then you are probably sorting by import date/time, not exposure date/time. See the sort dropdown.

The number of selected images you can see in the browser. For the total duration calculation Observatory excludes rejected images, so it's not exactly the same. I can add the number used for the total duration calculation in the next update.

[Tailspin45]

If the exposure date/time is displayed correctly in the inspector, then you are probably sorting by import date/time, not exposure date/time. See the sort dropdown.

Well, duh. I completely forgot about that. Per usual, you thought of everything. I shoulda known. Thanks!

[Sander Berents]

Back to the original topic: Can you check your system if it has multiple copies of Observatory? The Quick Look extension can fail if the system loads it from a different copy than what you are using. If you have old copies of Observatory, make sure to compress them so the system doesn't recognize them as applications.

Please also check /Applications/Utilities/Console for Quick Look crash reports or other Quick Look related errors when viewing FITS, XISF or SBIG images.

[Tailspin45]

Only one copy of Observatory. I also removed backup and clone copies.

No QL crash reports cataloged in Console.

Just updated a different program and had to go to Settings | Privacy & Security to give it full disk access and discovered Observatory was listed there but turned off. Enable it and everything seems to be working right! QL works and selecting subs from list causes no hiccoughs.

However, I still have that problem that the program refuses to load some folders. Interestingly, when I loaded sub-folders one-by-one, they loaded fine (and quickly).

I suspected, and further testing confirms, it's a size issue. It immediately quits importing a 65Gb folder full of lights, calibration files, and PixInsight by-product files such as Registered, Aligned, etc.  But it happily loaded a 2.7Gb folder with 146 files in 93 seconds. Still waaaay to slow, but at least it loaded.

[Sander Berents]

Good to hear that the Quick Look extension works now. But it's weird because Observatory doesn't need full disk access, and the Quick Look extension runs in its own sandbox. I have that turned off and it works fine for me.

The selection beachball I have resolved already for the next update. It was caused by excessive UI updates for things that weren't even displayed.

I have tested Observatory with folders larger than 65 GB, so the size is not the cause of the crash. What dimensions and size are your images usually, and what format? When you import, Observatory doesn't just create a thumbnail and add it to the library. It also computes image statistics, the average HFD of stars, tags plate solved images, etc. For large images, that just takes time.

Please try to import the 65 GB folder with the core allocation set to its minimum value. There used to be a bug that could result in a crash when importing, and I found its cause after introducing the core allocation setting. Maybe you are hitting another concurrency bug.

[Tailspin45]

What dimensions and size are your images usually, and what format

I have five cameras that capture only FITS files
ASI462MC   2.1Mb    1920x1080
ASI533MC   9.05Mb  3008x3008
ASI294MC  11.7Mb   4144x2822
ASI678MC   8.29Mb  3840x2160
ASI120MM   1.2Mb    1280x 960

When you import, Observatory doesn't just create a thumbnail and add it to the library. It also computes image statistics, the average HFD of stars, tags plate solved images, etc. For large images, that just takes time.

Do that in the background after import is complete?

Please try to import the 65 GB folder with the core allocation set to its minimum value. There used to be a bug that could result in a crash when importing, and I found its cause after introducing the core allocation setting. Maybe you are hitting another concurrency bug.

That appears to be the case. With core set to minimum value the 63.15Gb folder with 1015 files loaded in 989.9 seconds

[Sander Berents]

Great! Please email a crash report for that 65 GB folder when using the default core allocation setting.

Import is already a background task. Observatory needs this information, and a background task of a background task is a bit too much.