Lol Cyril was faster than me… I was about to say the same thing to you…
I’ve created a dedicated thread to talk about macOS builds. I’m sorry for the noise added to this thread 
1 Like
I did change my mind. 
The new interface is working pretty good, even on my laptop. I especially like the way the bw and rgb frames are all together now.
More ideas based on recent trials - I’ll be glad to send them wherever I need to.
- It would be nice if we could drag select the color(rgb) panel when doing color correction and such.
- Tab stacking might allow the control panel to be made smaller to the right.
- a way to have the histogram graph(not controls) stay visible during other edits would be helpful.
- increase the Asinh stretch to allow more than 1000 in it’s drag bar. (maybe I don’t understand?)
- bug: maximize doesn’t lock to desktop for some reason(I know I should do an issue at git but i’m lazy)
- A startup option to have it start in user mode with drag bar to the right, I do it every time start Siril.
- Saving the setting for view mode between starts might also be useful. (I like autostretch for quick previews)
I’ll be sure to check back and can explain any of these further if needed. I also have a big idea I just had on the indilib forum but figured I better use a new thread for it.
Thank you for all guys do, you make AP processing more accessible to so many people!!
2 Likes
How? It is difficult to make smaller the right pannel because there is the console too. If it is too small it will be difficult to read something.
Indeed, that is an idea I have to think about. Thanks.
Going too high is never a good idea with asinh. 1000 is already very huge.
It works on my machine, and if not on yours it is probably a GTK bug.
I’m not sure to understand.
This one is not a good idea. A lot of people get confused with the view mode and the real pixel changes. If we allow to save the mode. Every user will always start in autostretch mode and, therefore, forget it is a viewer and not the real image.
Saving the setting for view mode between starts might also be useful. (I like autostretch for quick previews)
This one is not a good idea. A lot of people get confused with the view mode and the real pixel changes. If we allow to save the mode. Every user will always start in autostretch mode and, therefore, forget it is a viewer and not the real image.
I’ll try to explain my position on this. If you have any trouble translating my writing style please just ask, I’ve worked with many different language speakers and can elaborate as needed. Patience is often needed.
First. Early versions most certainly DID save what you saw, and I used that many times before an update changed it. This is why some of your users, (especially those of us using it so long) are confused by what they now consider odd preview behavior. Furthermore, what good does it do to have the preview pane NOT represent buffered/loaded/edited data?
–In short, I totally understand that only the linear view mode represents the data. I am saying that starting with a trimmed min/max value also does not represent the actual image data.
Maybe some pics will help?
This is how a fit opens now, linear mode with min/max auto scaled:
This is how I would like it to be able to start:
So it would stretch like this:
And not like this:
now… If you haven’t started sharpening the guillotine yet…
Here’s Another idea to play with: When you hit autostretch in the editor, the carrots are all to the left and hard to get at. How about having the carrots recenter when you hit autostretch, as they do after applying changes manually, but before the changes are applied. That way we can tweak from there with a rescaled edit bar without saving overexposed areas or noise that pops up with the auto.
Is there a tutorial that could help me understand Asinh better? I had thought it acted on unstretched linear data to bring up lows without allowing highs to grow similar to the way a logarithmic asymptote does but maybe i’m confused? I looked up the math/graph but can’t grok the usage in this case.
Thank you again for your patience and time. 
It was a bug and only with jpg. Because for sure we’ve always tried to make distinction between visualization and real pixel changes. We like the way it is done now because user can change visualization without interfering with pixel values. Not a lot of software do that and it is essential in astrophotography IMO.
It has always been the case (except if some bugs occurred in the past). We compute min/max values in order to show range of data at first load.
You have a zoom for that at the top. Just use it it will be easier. Also you can resize the histogram transformation window.
No, because arrows are re-centered only if changes are applied. Hit histogram gear shows you a preview, you have to confirm then to really apply it.
What ainsh do you talk about? visualization or histogram transformation tool.?
Sorry for the delay. I just found this unsent message.
I was wondering about the new asinh transformation tool?
hey…one out of what, 20? i’m going to have to readjust my sights a bit here. 