deufrai
commented
2 years ago Hi and thanks for this detailed report
First, You went into a lot of trouble for the install.I suggest you use our nightly builds instead. Available here => https://als-app.org/nightlies/latest/. There you'll find an archive for RPI that contains everything needed to run ALS smoothly. Simply decompress the archive wherever you want, make the als* file executable and run it :)
Second, This is indeed a known issue : alignment of colour images uses multiprocessing to work on the 3 RGB layers in parallel. But this needs a lot of memory. Memory that is scarce on RPI4. We have plans to add a check on available memory before performing the alignment. So it is done sequentially when available memory is too low. See : https://github.com/gehelem/als/issues/112
But I cannot tell when it is ready
mgutierrezp
Hi all,
First of all, thanks for this fantastic software. Great job!
I'm currently running a raspbian 10 distro (in particular, astroberry 2.0.3), updated one month ago. I've faced some issues while installing ALS (tried 0.6.1 and last alpha version). Were resolved mainly following the tips in https://indilib.org/forum/development/5204-als-astro-live-stacker.html/45819.html#49158. I also had to do some tricks like installing a particular version of llvmlite (0.32.0); otherwise it was complaining about my local llvm version (too old, although updated a few days ago, it seems). In any case, I managed to install both alpha and stable versions. Once installed, I faced another issue. I'm using a nikon dslr cam (.nef files). First image dropped in the monitored folder, was recognized perfectly and showed in the preview, but subsequent files could not be stacked and were discarded:
1-08-25 12:10:45,655 Dummy-2 als.stack DEBUG Stacker._get_image_subset_boundaries() returned (0, 4015, 0, 6015) in 0.037 ms 2021-08-25 12:10:45,655 Dummy-2 als.stack DEBUG Searching valid transformation on subset with ratio:1.0 and shape: (4015, 6015) 2021-08-25 12:10:45,657 Dummy-2 als.stack WARNING Could not stack image FILE : /home/astroberry/livestack/DSC_0014.NEF : Input type for source not supported.. Image is DISCARDED 2021-08-25 12:10:45,658 Dummy-2 als.stack DEBUG Stacker._handle_image() returned None in 32.728 ms
After digging into the code, seemed that the issue was related with numpy:
2021-08-25 12:01:37,688 MainThread als.logic DEBUG Controller.on_stacker_queue_size_changed() returned None in 52.408 ms Traceback (most recent call last): File "/home/astroberry/soft/als/venv-dev/lib/python3.7/site-packages/astroalign.py", line 187, in find_transform source_controlp = _find_sources(source)[:MAX_CONTROL_POINTS] File "/home/astroberry/soft/als/venv-dev/lib/python3.7/site-packages/astroalign.py", line 326, in _find_sources import sep File "sep.pyx", line 1, in init sep ValueError: numpy.ndarray size changed, may indicate binary incompatibility. Expected 44 from C header, got 40 from PyObject
I uninstalled numpy and installed this way into the venv:
pip install numpy==1.20.0 --no-cache-dir --no-binary :all:
Problem solved.
But now I'm facing a big problem and I'm afraid I have no any solution. I think it's not a bug, but a memory constraint:
2021-08-25 12:26:44,326 Dummy-2 als.stack DEBUG Aligning color image... 2021-08-25 12:26:55,193 Dummy-2 als.stack DEBUG Color channel processes are done. Fetching results and storing results... Traceback (most recent call last): File "/home/astroberry/soft/als-0.6.1/src/als/code_utilities.py", line 33, in wrapped result = func(*args, kwargs) File "/home/astroberry/soft/als-0.6.1/src/als/processing.py", line 445, in run self._handle_image(image) File "/home/astroberry/soft/als-0.6.1/src/als/code_utilities.py", line 33, in wrapped result = func(*args, *kwargs) File "/home/astroberry/soft/als-0.6.1/src/als/stack.py", line 173, in _handle_image self._align_image(image) File "/home/astroberry/soft/als-0.6.1/src/als/code_utilities.py", line 33, in wrapped result = func(args, kwargs) File "/home/astroberry/soft/als-0.6.1/src/als/stack.py", line 204, in _align_image self._apply_transformation(image, transformation) File "/home/astroberry/soft/als-0.6.1/src/als/code_utilities.py", line 33, in wrapped result = func(*args, **kwargs) File "/home/astroberry/soft/als-0.6.1/src/als/stack.py", line 246, in _apply_transformation for channel, data in results_dict.items(): File "", line 2, in items
File "/usr/lib/python3.7/multiprocessing/managers.py", line 811, in _callmethod
raise convert_to_error(kind, result)
multiprocessing.managers.RemoteError:
Unserializable message: Traceback (most recent call last): File "/usr/lib/python3.7/multiprocessing/managers.py", line 289, in serve_client send(msg) File "/usr/lib/python3.7/multiprocessing/connection.py", line 206, in send self._send_bytes(_ForkingPickler.dumps(obj)) File "/usr/lib/python3.7/multiprocessing/reduction.py", line 51, in dumps cls(buf, protocol).dump(obj) MemoryError
Aborted
It happens from the 2nd image (first stack attempt).
Maybe my .nef files are too big (~20MB) for a such a tiny computer. I'm not sure it it's really a limitation or a bug. I tried to add additional swap but no luck. I've monitored the resources while reproducing the error and memory is not exhausted at all. No OOM killer shows in the logs, neither. But maybe the process tries to reserve more memory that available (even increasing the swap) and then crashes.
Hope this info helps to the developers to improve this fantastic project. I haven't seen any similar software under linux.
Regards