Milky Way Processing Feedback

Hi all;

I have a shot that I really like, I have processed it with Darktable, but I would be interested in your thoughts and if there are other edits that may improve it.

I have uploaded the following files to my private owncloud server

  • the RAW file (.3FR from Hasselblad)
  • the xmp file
  • my exported jpg image

All of these image files are released under the creative commons CC0 1.0 Universal license

The files can be viewed / downloaded here:
http://23.254.244.18/nextcloud/index.php/s/k9sqCHQoMgFPmrb

I have also uploaded the exported jpg file and the xmp file here but the site wont allow me to upload the raw file

Thanks in advance for any feedback


B0001131.3FR.xmp (11.7 KB)

4 Likes

Hi Kevin! If possible, please upload the RAW, JPG, XMP directly onto your post, then add the Play_Raw tag, so others may easily find this.

(Everyone is eager to work on a public domain milky way shot.)

I uploaded the exported jpg file and the xmp file but when I try to upload the RAW file (a .3FR file from a Hasselblad X2D camera) I get this error:

Sorry, the file you are trying to upload is not authorized (authorized extensions: jpg, jpeg, png, gif, ico, dtstyle, txt, scm, pp3, svg, xmp, bz2, xcfbz2, py, arw, apng, orf, cr2, nef, dng, tif, patch, zip, 7z, rtc, raw, exr, hdr, raf, rw2, pfi, xcf, xcf, pef, icc, icm, pto, blend, dcp, xcfxz, xcfxz, ods, mp4, mkv, ogv, webm, cr2, nef, dng, cr2, pdf, kra, ntp, arp, fits, seq, gz, ssf, cr3, heif, heic, avif, crw, dtpreset, nrw, cfg, jxl).

@patdavid Is your team able to allow 3FR’s? @psalm19pix Are you able to post the 3FR as a zip file?

I get an error the size is too large, the 3FR file is 202MB and the zip file ends up being 135MB

Even if I use the -9 flag to force better compression the zipfile still comes in at 135MB

yeah our upload is capped at 100MB currently

The milky way doesn’t look blueish.

2 Likes

Strange it looks with high quality resampling activated completely different after export. When switched off, it looks like it should. So here is my attempt:


B0001131.3FR.xmp (22,1 KB)

1 Like

I shot a white card at the time, used it for setting the white balance, see updated image. However when I do this:

  • go to the shot of the white card
  • click the eye dropper in the white balance module and draw a box within the white card
  • go back to lighttable
  • do history stack → selective copy (and only choose the white balance)
  • then on this image do history stack → selective paste (and only paste the white balance)

I get this warning when I return to darkroom for the image:
white balance applied twice

also here is the updated xmp file

B0001131.3FR.xmp (11.8 KB)

And here is one where I added most of what @Popanz did above but with the right white balance applied.

I love it!

1 Like

FYI: This was exported with the ‘high quality resampling’ set to yes

If you would use a grey card for calibrating a sunset photo, do you think you will get the correct WB? I have my doubts.

1 Like

I thought the best way was to shoot a white card and use it to set white balance, should I be using a grey card instead?

My poor old PC with 8 GB RAM and a stone age Xeon CPU needs more than 5 minutes to process this image in RawTherapee. So quite a simple edit from me.
WB was RGB gray which looks quite good IMHO


B0001131_RT-3.jpg.out.pp3 (16.9 KB)

btw … my preferred packer 7zip produces a 109 MB file from this RAW. zip is a really very old algorithm. It was already outdated when I used OS/2 in office

1 Like

There shouldn’t be a big difference between a grey card and a white card. The problem is, that they are tools helping to get a neutral light setting but they are far away from a rule. That’s why I mentioned the sunset setting:

On a sunset, there is a warm orange light which floods the scenery. So the grey (or white) of a grey card doesn’t look like neutral grey anymore. If you now use this card for WB everything gets a loot cooler look than it was in reality, because you suppose the warm lit card is the neutral reference. So using a grey card when you have a quite neutral lighting is a good idea. But using it in special light situations doesn’t give you automatically the correct WB. When the light itself isn’t neutral this has to be taken into account.

I think that my edit is in the end still too cool and the WB tends more in direction to @Sunhillow’s render. Maybe a bit more like this:


B0001131.3FR.xmp (26,8 KB)

1 Like

Yep, the sky and the stars here can be regarded as an emissive light source (as opposed to something that is merely reflecting light), so daylight white balance preset shouldn’t distort the sky and star colour. The galactic bulge is yellow-orange, and the the background sky is greenish-red because of airglow. Rest of the colour palette is from distant light pollution.


B0001131.dng.pp3 (14.4 KB)

2 Likes

One more from me


B0001131_RT-6.jpg.out.pp3 (16.8 KB)

1 Like

Here’s my attempt. Always challenging working with singles. I’ve done astrophotography for over 6 years now and own a tracker + astromodded camera.

I attended the Nightscaper Conference last year. One of the presenters, Dan Zafra, suggested the best way to white balance is to pick an edge of the sky trying not to select any stars if possible. Set vibrance and saturation to 100% for a moment then fine tune white balance until the colors between say the milky way and airglow are distinct and clear. With DT you could make further adjustments with RGB Primaries. Then reset vibrance/staturation. The image should be bland. But when you set those the colors should pop. Make sure not to blow out the stars which also shouldn’t be all white.

I lean towards warmer appearance and bolder MW in my nightscapes.

DT 4.9 dev (warning: heavy use of diff or sharpen; it took forever to export…)
B0001131.3FR.xmp (22.1 KB)

2 Likes