Jörn Reppenhagen

Sure it's possible. Walking from Berlin to Moscow is also possible. If you concentrate on the moon, you won't need any tracking mount. Jupiter and Saturn may also come into reach. It is also possible to do some more basic astrophotography without - but it's like walking from Berlin to Moscow, with the results usually being "suboptimal", politely expressed. If you love this hobby, do yourself a favor and invest in a tracking mount, there's inexpensive solutions providing you far more observation and general comfort and allowing longer exposure times (but don't expect being able to do minutes of exposure). But your first step should be achieving sharp, focused pictures without excessive noise and grain - see thread linked by NotMyFault.

Diese Fehler mache ich besonders gerne: Mehrere Ebenen, aber nicht die Pixel-Ebene ausgewählt, Pixel-Ebene nicht blau markiert. Passiert ständig, wenn man irgendeine Anpassung anwendet, die als neue Ebene ergänzt und damit automatisch ausgewählt wird. Klick auf die Pixel-Ebene, dann gehts wieder. Bild ist keine Pixel-Ebene. In dem Fall: Rechtsklick auf die Ebene, dann "Rastern ..." wählen. Deckkraft 0 oder sehr niedrig. Je niedriger die Deckkraft, desto weniger wirkt der Effekt. Fluss 0 oder sehr niedrig. Auch dann gehts nicht - oder nicht vernünftig. Das wurde zwar alles bis auf Fluss schon oben von Dan C und Komatös erwähnt, aber vielleicht ists so beschrieben noch ein Häppchen verdaulicher.

@irandar: The results are typical - it cannot work this way. Stacking expects pictures where the objects have an predictable, identical offset - example: Photo 1: Star A at position 100 x 200, star B at position 150 x 170. Photo 2: Star A at position 110 x 205, star B at position 160 x 175. So we've got an offset of 10 in the X axis, an offset of 5 in the Y axis. The same offsets for star A and star B. And the same offsets for stars C, D, E, ... Your main problem is not exposure times, it's looking towards the rotational axis of the sky, the celestial pole, while there's significant time differences between your photos. Your AP stack shows that the North Star, Polaris, is somewhere near the upper right corner of the picture, the pivot point of the sky. This causes objects near the upper right corner "moving" slower than objects far away. Thus the offsets more and more increase with the distance from the North Star, aren't identical anymore. You can see this by the different lengths of the star trails. That's why the stacking algorithms produce that star trails, it just cannot work with stars of different offsets in the same picture. Just imagine sitting inside a dome with stars painted on it's walls, the dome rotating around you. If you look up the stars near the top move slower than the stars at the sides. And if you look parallel to the ground, the stars seem to move with the same speed. If you take photos of the top and stack them, you'll get the same results as with your stacked photos. But if you take pictures parallel to the ground, the results will be much better as the offsets become almost identical. Remedies: a) Very short exposure times, as already mentioned in this thread. PLUS: Photos need to be taken immediately after each other. b) Taking photos more parallel to the ground plane. c) Use of a less expensive motorized mount like Star Adventurer or AZ-GTi, or a "real" mount starting from the EQ5 class, not below. I'd go for option c) if you wish to dive deeper into astrophotography as these mounts also allow mounting of smaller telescopes. You won't be able to achieve real long exposure times of several minutes, but this would solve your problem. If you wish to stick with your DSLR and shorter focal lengths for astrophotography, mounts like Star Adventurer and AZ-GTi are your friends. For everything else a "real" mount (EQ5 and up) is the way to go. Additional info: a) Your photos are out of focus, stars are discs, not points. Focusing on stars isn't easy, manual focusing with maximum magnification of the preview might help, also a Bahtinov mask. With higher focal length/magnification, a Bahtinov mask would be the way to go. With lower focal length/magnification (like 55 mm), it's better to focus via the preview at maximum magnification, take a sample picture (short exposure time, higher ISO) and check if stars are points by watching the taken photos at maximum magnification, correct the focus if needed. Nothing's more frustrating than finding out all your pictures are out of focus - wasting the results of several hours of imaging. b) Take some dark frames as Pauls already mentioned. You've got masses of defective pixels in your photos, that tiny red, blue, green or white dots just every digital camera produces with longer exposure times. Dark frames help eliminating these. Also playing with the Stacking Options (Threshold and Clipping iterations) might help. c) Use RAW photos. JPGs usually look better out of the camera, but the camera's JPG algorithms apply a lot of changes, often in a more or less random and unpredictable way. But astrophotography and stacking need unmodified data to achieve best results. Just set your camera output to RAW + highest JPG quality, so you always get a pair of RAW and JPG, can't forget setting the output to RAW.

@Bruno106: Could you post two of your original RAW files and two of the FITS files? I am no AP expert, but I could give this a try.

Stacking adds a Curves and a Levels adjustment to the picture layer after stacking, so the visible results indeed are stretched. Just deactivate or delete the Curves and Levels adjustment layers to work with the unstretched image.

Had a similar problem. My mistake had been the white balance setting in the stacking dialog - it was set to "Daylight", which caused all colors to be rendered yellow/white.

See this video by James Ritson: Plus, you may want to check out this YouTuber and enter "masking" into the search box. You'll find countless useful hints about masking and working with masks: https://www.youtube.com/watch?v=j8jszUpmSM0

Plus, a JPG usually gets heavily processed in-camera before saving. Usually it takes quite some effort making a RAW look as good as the JPG. That's why I always set my camera to save RAW and JPG - to get a JPG I can use immediately, and a RAW I can really play with. You've got some harsh contrasts in your image, pure white to pure black. For not overexposing, the shadows need to become quite dark in the RAW. But still, it seems to be a bit overdone. If you post the original RAW file, we could check and compare the RAW development with other RAW converters. Comparing highly processed JPGs and pristine RAWs just doesn't work.

@Dan C - Mystery solved: a typical case of HAUS (highly advanced user stupidity). A mysterious entity (ME) had set the white balance in the stacking dialog to "daylight".

@Kevin Barry- ASI071MC Pro uses a Sony sensor. This thread is about Fujifilm. @Dan C - I am reluctant to opening a new thread if there's already an old thread dealing with the matter. In most forums you'll immediately get lectured for redundancy. I'll try astrostacking again, maybe I just missed setting a vital option - and if the result is still the same, I'll open a new thread. Note: There's no total absence of colors like before - there's just ONE color; in my case it's yellow, with all the other colors not showing up.

Just to push up this topic again: Still no colors with Fujifilm RAW files and astro stacking with update 1.10.3. Single RAF files have color information, stacked files just show a single tone. Come on, AP guys - this bug is known for more than 8 months, now.

I found some similar issue (Windows version): If I use the Displace filter e. g. to overlay some text on brickwork, then apply more adjustments like a Gaussian blur to smoothe the text and adapt it to the low pixel resolution of the underlying photo, the results look like it should be. But if I export the finished image, all adjustments after using the Displacement filter just disappear, the picture gets saved with just the Displace filter applied without any further editing steps - rendering the text too sharp and unnatural. Same happens if I use "Merge Visible". Only way of exporting the correctly rendered image is taking a screenshot. I guess it's the same problem causing that behavior. Exporting and merging obviously just don't follow the "include what you see" approach. @Iconoclast: Will try that and report back later.

Yes, Vignette is there. But almost unusable because it's stationary fixed to the center of the image. Who puts the subject in the center? Suggestion: Make that vignette freely movable. (Yes, I know ... Ellipse, Gaussian Blur, Erase blend mode - usable workaround, but still a pain in the you-know-where ...) That tiny, tiny slider buttons ("thumbs") ... Sure, that titchy knobs look sooo modern and sophisticated, but it's not what you really need. How often did you miss that knobs? How often did you set the mouse pointer on that knobs, looked back to the picture to see the change - only to find nothing changes because your mouse pointer shifted by some pixels before pressing the mouse button? See? Suggestion: Make 'em BIG! - Alternatively: Keep the size but enlarge the "hit zone" around that knobs. Best: Let the user choose the size in preferences.

Banacan: For this usage case, you might be better off with a simple HSL adjustment - especially because of the transparent background and the uniform color range. Select HSL adjustment, choose red color circle, select the picker, click on a bright red area, set Hue Shift to e. g. -62, Saturation Shift to 56, Luminosity Shift to 49 - or to your liking. Then make sure the HSL layer is selected, invert the layer (color reverts to red), choose the Paint Brush Tool [B], select pure white as a color (255, 255, 255), then paint over the areas you wish to recolor, Opacity controls intensity. Take care not to select "Wet Edges" and "Protect Alpha". That's essentially the same as Recolor - but the above also works with more complex color combinations (not just with "everything red" things). Workaround for setting correct hue with Recolor: Set your target color using RGB, then switch from RGB to HSL. The now shown Hue value is the value to set in the Recolor dialogue. In private: I also find the behavior of the color replacement brush rather strange/senseless - it just doesn't do what it should be supposed to do.

Chris: Possible, but I don't know for sure. I'll pay attention to active selections next time and immediately come whining again.

Chris: So I can stop thinking about spending a fortune on a psychologist. 1. Indeed, I use a 3 monitors + VR setup - but I never experienced that brazen context menu desertion to the left wing before. Had been a first with Affinity. 2. Also my thoughts. But I just didn't change anything of the configuration during the last weeks, except redefining the keys for increasing/decreasing the brush size for mask refinement. The good thing: AP didn't crash or permanently hang anymore, even with hardware acceleration on. There are occasional "hickups" with my case fans turning up violently, indicating a high CPU load over one or two seconds, but then AP recovers. I don't remember noticing that behavior before; maybe it's the update, maybe my hardware acceleration is still off while the config shows it's on - who knows. Only crashes I experienced happened when zooming in fast and deep with Ctrl + mouse wheel.

This is a small but nice one if you use a keyboard with a non-English layout. Changing the brush size is quite clumsy if using the mouse: Click the drop-down, exactly hit the tiny slider thumb (why the heck are that "grab points always that tiny???) with the mouse, pull the slider, find a place to click outside the drop-down to close it and to see the new brush size, find the brush size to be wrong (because you didn't see it's size while dragging the slider), repeat. So you wish to use the keyboard. Unfortunately, the default definition is "[" and "]". Convenient für users with an English keyboard layout, a pain in the you-know-where for everyone else. E. g. for German keyboards, it's Alt Gr + 8/9. So you call up the preferences and change the shortcut keys. But you need to change that brush size keys for each and every single brush in all the different categories, next pain in the ... Only to find out later that you missed a definition. Back to preferences, search for the brush in question ... Quite an annoyance. So my suggestion is obvious: A gobal definition of keys for changing the size of all brushes at once in the preferences.

An update ... I managed to solve the problem halfway - it's still faulty, but bearable. Two sample pictures attached. It's a sequence of white balance, levels, frequency separation, multiple HSLs on the low frequency layer and painting on the same layer, using a reversible mask for sky and foreground objects, then applying contrast and sharpness adjustments on the layers. I am quite sure there is a quick, direct and flawless approach - but I just don't see it.

Crash again after I did the same thing I did for the crash I reported on September 8th - Zooming via Ctrl + mouse wheel. There was NO crash report (DMP file). Not while Photo was hanging, not after terminating Photo using Task Manager, not after restarting Photo. There's pretty some DMP files in the folder, but nothing documenting the latest crash. Add: Some strange secondary effects after restarting AP. 1. First right-click on the Layers list on the right side opened the context menu on the LEFT side of the screen, just below the Files menu. Happened only once, after that the menu permanently was back on the right side. 2. Hardware acceleration switched BACK ON. I updated the graphics card drivers after the first restart, then wished to switch on hardware acceleration to check if the new drivers solved the crash problem. And found the option ticked already. Yes, it had been off. Otherwise my AP installation wouldn't have survived three of four editing steps - had been the only remedy against that constant crashes. I left it switched on - and no crashes till now. I experienced some "digestion issues", everything slowing down, freezing like hanging, but then AP recovered. No, I don't drink, I also did not consume any drugs.

I am using one single RTX 2070 - and I also have that crashes. Maybe the solution is Serif buying us a second graphic card for removal.

carl123: What exactly did you do to recover all the blue tones in the sky? I ended up with similar results (also with the same erroneous blue in the clouds) - but with the lower part of the sky being gray instead of blue.

IanSG: Exactly my own thoughts. Nille: If you've got a sky's RGB value of 255, 255, 255 (except in the brightest part of a cloud) in a JPG, there's no way of recovering anything, not with AP, not with CaptureOne, not with alien technology. Only way is replacing the sky completely. But just upload the RAW (not the JPG ), if you won't mind.

Chris: No, I haven't. Where to find that on a Windows machine?

I had the same experience, Chris. Problems started after the latest update - previously, I had hardware acceleration on all the time, no problems. But after the AP update I experienced crash after crash while OpenCL was on. Then I updated NVidia drivers, which didn't change anything. Crashes stopped after deactivating the OpenCL option, but some processes (like frequency separation) now just take longer than forever. CORRECTION: AP just crashed while zooming - with OpenCL OFF!

NotMyFault: Ach, du bist ja auch Germane! - Ich antworte aber in English, damit die anderen Leute das auch mitverfolgen können. I attached a super quick edit of your screenshot, of course it's low-res, but should illuminate the issue. It's just an HSL edit. See the quite distinct "circle of nothing" between inner circle and bleeding rim, plus the results of that bleeding into the background? You'll also notice there's more bleeding to the inside - invisible prior to the HSL adjustment. That's also exactly my own results. But I am quite sure there must be a real simple solution, I am just too blockheaded to find it. Just have a look at the second image, a black and white conversion. That spot is still there, creating a quite bright misty spot in the center. Now the third picture, same black and white conversion, but with the blue component set to 0. Spot almost completely gone! Also works after a channel swap, this time with the red component set to 0. There's still a faint discoloration, but I guess that's because the color of the blue (or red) component is not 100 % on the (hot)spot. Slight loss of contrast could be compensated by raising the cyan (yellow after channel swap) component accordingly. Thus it seems to be possible to eliminate that spot completely just by reducing a single color component of the right color composition. I'll experiment with a layer overlay of a single color (without any fading) and diverse blend mode settings for substracting that color from the background layer. Hopefully hitting the color on the spot does the trick. (Till now, it just didn't.) Maybe this finding might help working out a solution. - Or maybe it's just elaborated BS.