What?!? the images are EXACTLY the same size. Why is it giving this error?

Software Siril
1

13:46:22: Reading FITS: file dec_m27ha_stacked.fit, 1 layer(s), 2072x1411 pixels, 32 bits
13:46:22: ICC profile differs to that of the first image loaded. Converting this image to match the first one loaded.
13:46:42: Reading FITS: file r_m27_OIII_stacked.fit, 1 layer(s), 2072x1411 pixels, 32 bits
13:46:42: ICC profile differs to that of the first image loaded. Converting this image to match the first one loaded.
13:46:42: Attention: channels are dated more than 24 hours apart. DATE_OBS set to the earliest observation start date but for some purposes this field may be of limited use (e.g. solar system objects may have moved significantly between channels).
13:46:51: The image sizes are not consistent. This may happen as the result of previous alignment operations. Please reload the input images.

2

Hello,
If you’d produced a screeshot as we regularly request (we’re not soothsayers) we’d have told you that the sizes aren’t identical in the dialog window and that there’s a “NOT OK” for at least one of the images.

1 Like
3

the log provides the same information as the UI. both images are 2072X1411x32b

4

It seems that you find my last message inappropriate. At least I greeted you, the same cannot be said for you.
Since your arrival on this forum, your behavior has been far from encouraging us to help you.

I’ll pass.

3 Likes
5

If you are trying to get help, you should work with the people trying to provide you help.

6

before pressing the align button

image
image1920×829 286 KB

after

image
image1912×1006 350 KB

image sizes are IDENTICAL

7

I haven’t tried but I guess it’s because you’re leaving an empty line in the tool, remove the red if you don’t want it, or load an image in it

1 Like
8

Thanks, that was exactly the issue.

It’s frustrating that the software provided a misleading error message about mismatched resolutions, rather than identifying the actual problem with the red channel being left blank during compositing. This kind of issue highlights a breakdown in universal design principles, where clear and accurate feedback to the user should be a priority.

9

yes, it’s also that you are trying many things that make no sense for people who know how to use the tool already like us, we cannot spend much time handling fringe cases, the team is already hands full with the main workflows sorry

but it’s a free software, so that means you can fix the problem and submit the correction for everyone, that’s the beauty of it

2 Likes
10

Thank you for your reply. I understand that the team is focused on main workflows and that resources being limited in open-source projects is the norm. The work you’re doing is valuable, and I appreciate the effort involved in maintaining and improving the software.

I spend my days as a UX consultant for an aerospace company, I focus on designing systems that guide users effectively, during crucial phases of flight when decisions need to be made fast and correctly. One of the key principles of good design is to ensure the system communicates clearly with both experienced and novice users. Misleading error messages, like the one I encountered, can create unnecessary frustration for new users, potentially discouraging them from engaging further with the software.

Because of this, I hope you can appreciate that when I see glaringly bad UX, it’s as grating for me as it might be for you as a developer to encounter something like poorly written, unoptimized, or spaghetti code in a critical part of the system. It’s something that stands out immediately and feels like it shouldn’t have gotten past review.

I’d be happy to help contribute to improving the UX if the project is open to such collaboration. However, I think it’s important to acknowledge that dismissing concerns about usability as fringe cases or user error can hinder the broader adoption of the software. Improving the user experience benefits everyone, both the community and the project itself, by making the tool more accessible and increasing its appeal to a larger audience.

So, in the spirit of an olive branch, here’s how I’d guide the team to make this process clear and unambiguous, following the best practices. First, we need to ensure that users cannot start the “Align” process when the system isn’t fully configured. Right now, the “Align” button can be pressed even if one or more channels are blank, which leads to errors that are both avoidable and confusing. Adding a constraint to disable the “Align” button until all channels are either assigned or explicitly removed would prevent this. To make the constraint user-friendly, the disabled “Align” button should display a tooltip when hovered over, explaining why it’s unavailable and what the user needs to do to continue. For example, it could say, “The red channel is blank. Please select a file or click ‘-’ to remove it.” This would guide users toward resolving the issue without frustration or guesswork.
For a well-maintained code base, this sort of change should take 1–2 hours to implement and will save countless hours of confusion and your time spent answering repetitive questions from new users.