Conversion from RAW to JPEG quality issues

Screenshot_20230909_151925

I have a couple of astro photos which I took recently (in RAW format) and have edited them to the point where I am now satisfied how they look.

However, when I convert them to JPEG with the highest quality setting the output seems a little lacklustre. For example, the picture is not as sharp as I would like and it seems a few stars a missing. I appreciate it is a lossy compression algorithm but are their exports settings I could use that would bring me closer to the picture I actually see in darktable?

I have attached an example setting that I am using at the moment. There is no specific reason why I am using the “BRG” profile except just to play around to see if it had any noticeable impact on the picture.

Any suggestions much apreciated.

Try 99… I feel like I have heard setting JPG to 100 can sometimes not produce what you expect

1 Like

Welcome to the forum, @PuzzledOtter,

I am not aware of any issues, with lack of sharpness after exporting. At 100% magnification I think the exported jpg (at 100% quality) is a faithful representation of what I see in darkroom main window, at 100% zoom.

I use git master v 4.5 (Linux) and 4.4.2 (Win 11). I use 100% jpg quality setting when I export, usually to sRGB color profile.

I must admit that i rarely develop my astro raw directly in darktable though, so I lack immediate experience of how stars are rendered. I do not have a tracker, so I have to stack raw in SIRIL first: RAW → SIRIL → TIFF → GIMP → JPG.

EDIT: Example Exported jpg at 100% zoom (left) and darkroom at 100% zoom

Check your raw zoomed in to 100% in the darkroom before exporting. Some operations are not reflected properly in the zoomed-out preview (for performance reasons). Contrast often looks different, especially in dark areas.

See

Ah! I see what you mean. I have zoomed 100% on DT and then at a similar zoom level on Dolphin (I use Fedora Linux) and they both appear similar in appearance. I guess I have to be careful when editing next time that I take this into account.

Many thanks for the advice. Much appreciated.

@PuzzledOtter welcome to the forum. Personally after putting all the effort into editing in DT I export my images as a 16 bitt tiff file in Adobe RGB profile as an archival storage of my edit. Then if I need a jpg for the internet or other purpose I can open the tiff file in any suitable program including DT or Gimp and without making any changes export it as a JPG in sRGB profile. Of course, if I still have the RAW edit in DT I could just export it as a JPG from there. I just normally wouldn’t export a JPG only after doing an edit in DT.

Same here. I use16 bit integer tif and ProPhoto RGB color space space (actually RawThearpee RTv4_Large) for my archive as output from darktable. Possibly in vain, but theoretically there are image data from modern camera sensors corresponding to more than Adobe RGB, when mapped to a color space. I have my darktable working profile as Linear ProPhoto RGB for the same reason. My reference is here: https://www.youtube.com/watch?v=uPTN1FQtsf8 (I have Canon 5D mk IV).

EDIT: @Terry and all, Should we not use a linear color space for archiving then? Both Adobe RGB and RTv4_Large (ProPhoto RGB) have gamma curves.

Isn’t gamma used to better distribute the available resolution (bits per sample), so the more important parts (where human vision is more sensitive to small changes) are represented in finer detail?

Gamma encoding of images is used to optimize the usage of bits when encoding an image, or bandwidth used to transport an image, by taking advantage of the non-linear manner in which humans perceive light and color.
(Gamma correction - Wikipedia)

The pipeline is 32-bit floating point, so some data is lost on export. Would 16-bit linear (which must round everything the same way) discard more info than gamma encoding?

ProPhoto is such a huge space that you actually end up wasting (not using) quite a few of those bits (if not using float). You probably want to use a gamut that just about covers your data.

On technical merit, I agree, that smallest possible gamut cover color space is the best, since that gives me the smallest gamut step size, for a given bit depth per channel. Given the colors around me, sRGB is often fine.

Am I beyond sRGB at times, certainly; macro of flowers and insects, art work, neon lights.

I have never investigated a floating point workflow, that would be an interesting project.

Yes, but I often do HDR and landscape stitching with the Hugin tools and they recommend linear data in the intermediate files in to stacking and stitching. For these cases I select linear output profiles.

Good question. I do not know.