New Features in Rawstudio 2.0

So what are the new features, then? This list should give you a quick overview of the new features. We will dive into the technical details of them in upcoming articles, but this should give you the quick overview for you as a user.

Color and Adjustments

Image Quality

Workflow Improvements

Lens Correction




* For lenses and cameras supported by Lensfun. Profiles can be added by user.
** Some optimizations are only be available on x86-64 platforms.


Of course there are also a lot of new cameras supported, including Fuji cameras, and a lot of small bugs have been fixed. In the upcoming blog posts I will go through the major technical differences, and how we have handled them. Until then, take care!

Comments (12)

12 responses to “New Features in Rawstudio 2.0”

  1. past0r says:

    Does Rawstudio efficient work on Dual/Quad Cores? (is OpenMP used?)

    • Klaus Post says:

      It works very efficiently on multicore machines. It does not use OpenMP, but uses pthreads.

      We see about 80% scaling 1->2 cores and 70% 2->4 cores, so 2 cores are 80% faster than 1 core, and 4 cores are 70% faster than 2 cores. I will get into more precise speed numbers in the next posts.

  2. How would one handle grayscale images?
    I am shooting B/W directly in the camera.

    • Klaus Post says:

      That depends mostly on what camera you use, and in what format it stores its RAW images. Otherwise you can always set saturation to 0 per default. :)

  3. Martin Nilsson says:

    Suggestion: for the output options, I think support for some popular (web)albums would be very popular. Lightroom has support for a number of these. And I think it would not be very difficult nor time consuming to implement.

    I think mainly of Simpleviewer, which has a very simple setup using a simple file structure and xlm-files.


    • Klaus Post says:

      I completely agree. It is not a 2.0 priority, but more something like 2.1. We have the following export options that we will explore for the next version:

      * Picasa Export.
      * DigiKam Export
      * PDF Export
      * Web gallery export (could include simpleviewer).

  4. Martin Nilsson says:

    Happy to hear that it is on your list. :-)

    If it is there for ver 2.1 (2.0 would be too much I think, there is more important stuff for that) it would be great (in the meanwhile I have a couple of scripts that generate my Simpleviewer input).

    Of those you list I myself would prioritize a web gallery of some sort and after that PDF export.

    Fore Picasa imports pretty well by itself… DigiKam I never used.


    • Anders Kvist says:

      If you are willing to share your script for generating config for simpleviewer, I’d like to see it (never looked into simpleviewer except images images show by it). It’s one of the nice and simple galleries that everyone can upload to their website, so it should be on our list of exportable, but as Klaus says, it’s not a 2.0 priority…


  5. Mario says:

    Instead of only a navigator view, would a Hand tool be too difficult to implement? I sorely miss it from ACR, and even there it was never enabled by default; it always bugged me that on every image I loaded in ACR I had to press ‘h’ to swich from the zoom tool to the hand. Considering that a RAW converter is not an editor, there are no other editing tools, I think it is most intuitive to let the user move about the image from the start. Let zoom or any other tool be a settable option, but let the hand be default. After all, one can zoom with keyboard shortcuts, but you can’t move the image with the keyboard (other than with accessibility functions available in the OS).

    • Klaus Post says:

      A hand tool is definitely on the to-do list, but I’ve held it off until we could implement a “state” based UI, where you select the tool you currently want active.

      We have not found it feasible for the 2.0 release, and it was the only major feature we had to scrap for the 2.0. So until that is implemented, we don’t want to add more workflow elements that will be changed anyway.

      • Mario says:

        I may have misunderstood the information at the link you provided, but the ‘state’ approach implies exclusivity: you can only be in one state at a time. If this is indeed so, then the interface won’t be as intuitive as it should be. For instance, I don’t see why “Select WB” should be a ‘state’, precluding panning while in it. And then I suppose if you’re in the “Pan” state – equivalent of a Hand tool – you can’t select WB? You can’t straighten because you’re not in the “Straighten” state? Actually, I hope I have misunderstood, so please correct me.

Leave a Reply

Klaus Post on April 2, 2010

RSS feed