How to reduce disk space usage?

Software Siril
1

Its nice that there is the ability to go back to each sequence. But each processing step also adds a large number of files. becomes a disk space problem when there are lots of short exposure subs of high resolution.

I am already using symbolic links (Windows 10) for the FITS conversion step. Any other suggestions apart from a new or external SSD :slight_smile:?

2

Go into preferences and use compression as well.

3

All the options are lossless?

4

In 16bits yes. Not in 32bits. Everything is noticed in the tool tip text.

5

Thanks.

The tooltips detail the various algorithms but I could not see this information. Maybe it can be added in the next version.

6

Capture d’écran du 2021-04-19 18-05-11
Capture d’écran du 2021-04-19 18-05-11922×630 80.6 KB

7

No doubt it is correct.

But from the user point of view, “16 bit is lossless and 32 bit is lossy” is so much easier to understand :slight_smile:

8

Yes but this is wrong.
32bits can also be lossless with the right algorithm (gzip).

9

Note that the loss with 32 bits floating point images can be equivalent to reducing the precision to below the noise, so it would be unnoticeable.

Also note that it will take more time to process with compression enabled.

If disk space is a constraint, working in 16 bits should be considered.

10

So heres my understanding as of now from a practical point of view

  1. For disk space reduction, use any combination of symbolic links, 16 bit, and compression
  2. For compression, there are 4 algorithms in SIRL - RICE. HCompress, and GZIP 1/2
  3. 16 bit images can be compressed with any of them. But RICE and HCompress will work only with 16 bit
  4. If using HCompress, need to set the HCompress Scale Factor. A factor of 0 or 1 will mean lossless compression. Above 1 becomes lossy. A scale of 2 or 3 should be a good balance (as per tooltip)
  5. For 32 bit, have to use gzip. For this, Quantization Level needs to be adjusted. Zero will be lossless, have poor compression. 16 is the default, where there will be some loss but may be unnoticeable. Higher will be more compression but with more loss of information.
  6. In all cases, processing time will obviously be longer.

Is this correct now?

Thanks

11

RICE works well with 32bits. But this is lossy algorithm. However, as @vinvin said you will never see the difference as the compression is at noise level.

12

I know this topic is carrying on a bit, but FWIW, the tooltips say otherwise - that RICE and HCompress work only on integer arrays, which in SIRIL’ case is 16 bit.

Did it mean to say that RICE and HCompress will only do lossless for integer arrays? If so,
would be great if the text could be redone in the next version.

Anyway its clear now.

Thanks