What’s up in the Future for Rawstudio?
There are of course still areas where we could improve Rawstudio – as unlikely as that may seem :)
Here are some of the things I have noted for upcoming major things that come to mind. If you have any input on any of the topics or new suggestions, we are very interested in hearing your opinion in the comments below.
Cool image from sxc.hu with reference to the future :)
Here we go – here is a braindump of the issues that are top-of-mind right now:
- Improve Demosaic
The current algorithm is fine, especially considering the speed, but has some worst-case scenarios which doesn’t look too good.
I still have a research project going on this, which could be fun to keep going.
- Improve Sharpen+Denoise
De-noise and sharpening is already one of the best, but on very high settings it will create artifacts. I would like to improve this by implementing “soft overlapping” areas, and a limiter, that limits the amount of change permitted similar to “Limitedsharpen” and its successors.
- Faster Image Switching
Even though we are very fast at switching between images, the time the UI is locked is still quite annoying. Implementing either a file or memory based cache could help that somewhat.
I am not sure a filebased cache approach will help much, since we are already very fast on displaying the initial image with the high quality render taking a “considerable” time.
Offloading rendering to a separate thread may also be needed for this, so it is no easy task to make this work well.
- Float Precision Image Pipeline
Switch the entire pipeline from de-mosaic and forward to a planar float-point precision. Most filters are internally processing in float point. Memory usage for caches will go up, image quality will be largely the same, processing speed will be largely the same on SSE2 machines. So there isn’t any huge gains, mostly internal stuff.
- Implement “Post Processing” Filters
We could implement an interface for having more postprocessing effects available. Not sure how this is best implemented, but there seem to be some proposals regarding libgimp, and some commandline tools, which we could also implement. Suggestions are of course welcome.
- More Output Modules
Adding more output modules gives more possibilities. We could add export modules, that export to new formats as well as common applications, much like the GIMP export, so you can continue working on your images there. Obvious applications are DigiKam, Darktable and similar programs, which allow you to do more detailed editing of your images.
- Edit Modes
An adjustment I would have like to have made before the 2.0 release was edit modes, since the “default whitebalance on left click” isn’t exactly intuitive. This will also more expose some of the features like crop, rotate, loupe, and make stuff like panning more feasible to implement.
44 responses to “What’s up in the Future for Rawstudio?”
Leave a Reply
Hello,
My wishlist-item:
Curves/levels not only for Y (Luminance)
but also for R and G and B Channel and an Invert-Plugin
I know we can invert the curves by hand, but this is not so convenient :-)
This makes it possible to photograph film-negatives (with a macro and some stuff of course) and invert and make the black and whitepoint
adjustment (orange (un)masking)
regards
Reiner
Ah yes – I also had profiles for UV shooting on the list, which also has to switch R/B channels if I recall correctly.
What is “orange (un)masking”?
Hi,
mostl film negatives have an orange color tint
on the substrat. (the orange mask)
This is was used to improve
the colors during the chemical dvelopment process.
Later on this must be removed
http://en.wikipedia.org/wiki/C-41_process
regards
Reiner
Hi,
Rawstudio is great and no complaints. One “teensy” little thing : Max available colour temperature of 1200 ( I often white balance underwater which tends to be way above that : then if you open a photo in RS the embedded jpeg / thumbnail gets its WB set to 1200 )
Looking forward to all further developments and thanks for all the great work.
Francesco
>I often white balance underwater which tends to be way above that : then if you open a photo in RS the embedded jpeg / thumbnail gets its WB set to 1200(0)
I do see your point, and we had some talk about that when setting the limits. We preferred to set the limits somewhat at “natural light”, with some added margin.
Underwater photos, as well as photos from tinted lightsources will therefore not be directly “re-correctable” using whitebalance, but I don’t think that would be expected, since the light isn’t supposed to be “white”.
Can’t you use the Colour Mixer to change the image to the color rendition you’d prefer?
Perf improvements in image switching sounds great! May I suggest pre-loading of images as well? That would probably help a lot when going through a sequence of similar images and deciding which ones to keep. Maybe images could be preloaded into a cache in ram and then evicted in some LRU fashion as more images need to be cached. On the other hand, caching can make the performance unpredictable… I hope you find a good way :)
A few more things I’d like to see:
1. Camera defaults depending on metadata (specifically, NR setting defaults per ISO level or a range of ISO levels is what I want here)
2. Horizontal scrolling support (for example with a touchpad)
3. Some multicore scaling improvements (I have a 6-core desktop and rawstudio seems to mostly use ~4 cores, even when batch-processing)
>>>May I suggest pre-loading of images as well?
Yes. Right now we are preloading the binary data from the surrounding images. If I recall correctly, it is 2 or 3 on either side of the active image, so the file data is in the system file cache, when you switch.
The poor multithreading scheduling options of Linux, unfortunately makes pre-decoding images very hard, since it would slow down the UI considerably. Furthermore the actual “first preview” of images is quite fast, if the file data is already loaded from disk.
The only way to speed up the “first view” time of any image would be to fully decode all RAW images (as RAW images), when the directory is first loaded. With 1000+ images that would not only take a huge amount of time and require heavy disk IO, but we would also have to fill up a huge amount of disk space for a “preview” of each image.
>>>1. Camera defaults depending on metadata (specifically, NR setting defaults per ISO level or a range of ISO levels is what I want here)
Yes, yes, yes! We actually prepared for that, but it didn’t make it into 2.0.
>>>2. Horizontal scrolling support (for example with a touchpad)
Please explain?
>>>3. Some multicore scaling improvements (I have a 6-core desktop and rawstudio seems to mostly use ~4 cores, even when batch-processing)
Every processing filter is multithreaded and will use all your cores. There are however some parts that cannot be (at least easily) multithreaded, like:
* Disk IO – if IO is multithreaded, it in most cases be slower because of disk thrashing. We have a locking system in place that ensures that only one (major) IO operation can take place at the same time. In your system monitor, it will look as if we are not multithreading, but it is in fact faster than pushing several IOs at once. The only exception is SSD’s, but considering the price I don’t expect many people to store their images on SSD’s.
* Raw decoding. Most RAW formats are impossible to decode multithreaded. This inludes native formats from Canon, Nikon, Pentax, Olympus. Notable exceptions are Sony (ARW2), Panasonic (RW2) and DNG’s from Adobes DNG converter (recent versions using tiles).
* JPG/PNG/TIFF saving. The “usual” libaries (libjpeg, libpng, libtiff) do not support multithreaded encoding/saving, and since we don’t intend to write our own libraries and would like to wait for successful completion before moving on, that part of the pipeline isn’t multithreaded. Furthermore you again run into IO restrictions if you begin to do asynchronous saves.
Everything else in the processing pipeline is nicely multithreaded.
On preloading:
I was not aware that you where using it already, nor that the linux scheduler was bad :)
New idea then: Would it be possible to decode and run the entire image through the pipeline when in 100% mode, so that scrolling can be smooth?
I’m assuming that you don’t do this already, due to the performance characteristics I’m seeing. Perhaps it would have to be done in two passes to quickly render the part that is showing in the scrollable area at the moment. This request is a bit unfair though, as it runs very well already on my desktop, but it is slow on my laptop (Core 2 Duo, 2.26GHz).
On defaults:
I’m glad to hear it is planned :)
On horizontal scrolling:
Laptop touchpads (or, I guess, the synaptic driver) have the ability to emit events for horizontal strokes along the bottom edge of the touchpad, similar to how it works for vertical scrolling. This can (in Gnome 3 at least) be enabled in the mouse preferences.
To see an example, you can try this in firefox:
Go to a page with a fixed width and make the firefox window to narrow for the page to fit in. Then scroll :)
Nautilus supports this as well.
The current behaviour of rawstudio is to scroll downwards when I use this feature (the direction of the stroke does not matter, it always scrolls downwards).
On multithreading:
Good points, though I use an SSD, for the initial work with images at least :)
Perhaps this could be solved by running two pipelines side by side?
Depends a lot on how heavily contended the io lock is of course, but I think you know that better than me ;)
>>>I was not aware that you where using it already, nor that the linux scheduler was bad :)
You cannot set priorities to individual threads (only entire processes), so if you do any background rendering, it cannot be done without making everything else sluggish.
>>>New idea then: Would it be possible to decode and run the entire image through the pipeline when in 100% mode, so that scrolling can be smooth?
You are correct in your assumption. The tradeoff will however be a significant delay (>1-2 seconds) whenever you zoom into the image. Making it render the entire image is trivial, if you feel adventurous, you can change line 1556 in src/preview-widget.c from
rs_filter_request_set_roi(preview->request[i], &roi);
to rs_filter_request_set_roi(preview->request[i], NULL);
Note that this will also affect when you change any filters, since denoising/sharpen will obviously have to be run on the entire image if it (or previous) filters change.
We have talked a lot about splitting rendering into a separate thread, so the UI feels more responsive. I am however hesitant, since I don’t like the idea of the current image not reflecting the current settings.
>>>On horizontal scrolling:
>>>The current behaviour of rawstudio is to scroll downwards when I use this feature (the direction of the stroke does not matter, it always scrolls downwards).
Ok, I will see if see if we are doing something wrong. Could you add a bug report
>>>On multithreading:
>>>Depends a lot on how heavily contended the io lock is of course, but I think you know that better than me ;)
Not much, unless running on a slow network share. Especially for batch processing, since we are starting to fetch the next image from disk in the background, once we have loaded and start processing the current image.
[Scheduling priority]
Interesting, I did not know this. I read in the pthreads man page that priority is set on processes, as you say. It states further down though, that the nptl implementation is non-conformant to this requirement and can supposedly have different nice values for different threads… Maybe it is posix that is unflexible, rather than linux per se?
Anyway, it does seem like a pretty annoying limitation.
[Horizontal scrolling]
Filed as bug #517.
pthread_setschedprio and pthread_setschedparam change the priority per thread (not the entire process) on Linux – I use them in my own code and know this to be true.
As for features, it would be nice to have custom white balance presets so I don’t have to manually change the sliders each time I want to set a daylight, cloudy, etc., balance.
It would be nice to expand Rawstudio about:
– profiles (save parameters, easy apply on next photo/group of photos),
– conservative rotate image with deegres (step by step) :)
– autocrop rorated image,
– LAB color space for forthcoming filters,
– filters – this is a river-theme. The most elastic way is to implement plugin system, so every one could write own filter (but i don’t know how :)). The price could be high (slowness).
>>>profiles (save parameters, easy apply on next photo/group of photos),
Ah – just had to read that correctly! Ah – so you have “named presets” you can select and apply. Good idea!
>>>conservative rotate image with deegres (step by step) :)
I have not seen this work very well in other programs, but adding a slider popup with a number field when in crop mode would be feasible.
>>>autocrop rorated image,
Yes – makes sense!
>>>LAB color space for forthcoming filters,
I don’t see any specific advantages of LAB. The DNG profiles use HSV, which is basically the same, and for everything else YCbCr is much faster, and does the same thing.
>>>filters – this is a river-theme. The most elastic way is to implement plugin system, so every one could write own filter.
This is what I meant for “Post Processing”. This should allow for any filter to be written to do processing after “basic” correction has been done.
First of all I’ve to say what I like most about Rawstudio: processing speed and color accuracy :)
But similar to Dariusz I’ve some points to improve:
– conservative rotate image with deegres: The UI could be similar to the crop tool but with a slider
– autocrop rotated image
– Changing existing keywords: The UI could be the same but if there are existing keywords they should appear in the dialog (alt-T)
– Image rating (1,2,3) should write the star rating to the exported images – like the tagging. Here could be some workflow confilict: I’ve read that you use 1,2,3-rating as 1 as first class, 2 as second class etc.
In my workflow I use 1 as 1 star, 2 as 2 stars etc.
But keep up the great work!
Christian
[Changing existing keywords]
Yes – tag editing is definately also something we should look at!
[Image rating export]
Yes – you are right – it should be possible, and also that there isn’t a fixed format for that, so it will be difficult to do with a wide impact, since it would be require that other applications could read it.
[Image rating export]
I’ve used this feature only rarely and when I have, I used it as a grouping in the ui rather than as a rating.
Also worth noting is that most rating systems use a six level rating scheme (not rated, 1-5 stars) rather than four (not rated, 1-3 stars or first to third class or whatever it really is in rawstudio ;))
Hi,
Another (small) thing and I have no idea if it is an hard thing or an easy thing to implement. One of the commonest reasons to export from RS to other than direct to jpg is for “fill-light”
Regards,
Francesco
Hi,
I would like to see perspective tool in rawstudio.
I also have hard time adjusting contrast sometimes as there is no way to change it by the smallest increment. (At least I dont know it.)
There is also no way to create several pictures with different geometry from one source image.
Regards,
Jan
While most of RawStudio is excellent from a UI flow, I find the current plugins for exporting to (e.g.) Picasa & Flickr are fairly difficult to find and use. I would also like to be able to add tags directly in the UI (without having to open a dialog for it) and then right-click -> export -> Picasa (e.g.) to have it upload while I can move on to another image. Having the export to Flickr/Picasa available as a target within the Batch processing operation would also add awesomeness.
Lens correction is often a slow process, and for most images it is not important to me. Sometimes the non-linear nature of a particular lens does offend me for (e.g.) an architectural image, and I enable the lens correction temporarily. I would like the ability to associate the correction on/off with a particular image in this way, and somewhere simpler than having to go into “Edit Lens”, Enable, Export, Edit Lens, Disable would be appreciated.
Perspective correction is a post-process filter that would be useful for architectural photos. This is a necessity for architectural photos intended for Wikimedia Commons to achieve “Quality Image” status.
When I first start RawStudio I find that I am always adjusting the open/closed state of the controls on the RHS to the set which I find most useful. It would be nice if this open/closed state was preserved across invocations. Nicer still if I could re-order them and/or hide some entirely.
I would like to assign the key “z” to the “Zoom to Fit” action (I’m right-handed and anyway I don’t have a numeric keypad on this laptop, so ‘*’ is kind of complex to hit) but this seems impossible – I can assign ‘a’ or ‘Shift+Z’ but not ‘z’ on it’s own. These assignments should also survive across invocations – if someone goes to the trouble to different shortcut keys I don’t think they want them to be volatile, although the preferences screen could perhaps contain an option to reset them to the defaults.
Similarly I would like to assign two different keys to “Export to Flickr” and “Export to Picasa” so it would be nicer for these to be sub-menu options under an “Export to …” menu option, rather than being a drop-down choice in an “Export As” dialog as at present. Well, if it worked for me at all – in fact “Export to Flickr” doesn’t actually manage to log into my flickr account, perhaps because it’s authenticated via Google… :-)
Finally, I helped with the packaging to get RawStudio 2 into Debian recently, and the biggest problem we had was with the filesystem location of plugins (which are obviously architecture dependent) and the filesystem location of lens profiles and other stuff (which are obviously *not* architecture dependent. It would be nice if the build system had a mechanism for specifying these two locations separately as the current patch in Debian is kind of an ugly hack.
Thanks for all of your hard work – it’s much appreciated, and has enabled me to turn off the “save as jpeg” option on my camera with the full confidence that I can quickly and easily create a better jpeg through RawStudio than the camera can :-)
Regards,
Andrew McMillan.
[Tags+import+export]
I think a rightclick menu on images is way overdue.
For tagging. Select images, Alt+T, enter tags, enter to save – how could it be easier?
Exporting. If you set up “Quick Export” in the preferences, you simply have to click “ctrl+s”, and it will export directly to Flickr/Picasa without any questions.
Flickr/Picasa should be available in batch output settings on the batch tab.
[Lens correction per image]
We have considered this, and it might come in a new version.
[Perspective correction]
Unlikely to happen as an integrated part, but could very well be part of a post-processing package. We would rather focus on core functionality, and leave the advanced image processing to other applications, and meanwhile improve the
[open/closed state preserved across invocations]
Yes – it was also our intention that they should, but they aren’t always for some reason.
[Key re-assignment]
I am not an expert on this, but I think the re-assignment part is something done by Gnome (or gtk, or something), so we have no control over that. I don’t like having to edit a text file, if we where to support key re-assignment, so the investment in creating a UI for that is rather big. But if it is something that comes up a lot
I personally use right-click on the image, and select zoom there. It is easy, because it is the menu item right at the pointer, and it zooms where your mouse is anyway. You could also try using ctrl+left click on the image, which shows a 100% loupe view of where you point on the image.
[assign two different keys to “Export to Flickr” and “Export to Picasa”]
I see your point! Having a number of “Quick Export” options available could be helpful!
[filesystem location of plugins]
I cannot answer about that, since my Linux knowledge is very superficial. This is something Anders&Anders probably know a lot more about.
Regards, Klaus
Highlight and Shadows recovery sliders (à la photoshop) would be super nice too. Rawstudio and Gimp are my main tools as a photographer. Thanks!
Got another idea :)
It would fit my workflow perfectly if there was a way to configure rawstudio with the default export folder set to the same folder as the currently open one, so that I get one folder with for example:
IMG_0001.nef
IMG_0001.jpg
IMG_0002.nef
IMG_0002.jpg
…
…
This is how I sort my images, and the step of picking the current folder is a (small, but slightly annoying) extra step in the export process.
Easy – use the filename template: “%p/%f” – you might prefer to use “%p/%f_%2c” which will append a number, so you don’t get file overwrite issues. Can be used in Batch and Quick Export.
See more here:
http://rawstudio.org/blog/?p=404
Nice!
That’s what I get for not exploring the ui more – it’s right there :)
“Automatic for the people”,
Sometimes I’m using Rawstudio as ‘automatic preview creator’ for my ‘photos from vacations in 3000 variations’. So, I put them all in queue, and after few minutes I’ve got nice jpegs. To be fully satisfied with these jpegs, I would to see some automatic in Rawstudio. Auto-WB, Auto-Exposure, Auto-Contrast, Auto-Curve…
How it can be done? Maybe checkbox ‘auto’ for them? Or right-click on value (in style of ‘reset’ button).
It’s clear, what should Auto-WB option do.
Auto-Contrast and Curve should calculate, how to squeeze or expand histogram for full lights/shadows. Nice example is Sigmoidal contrast.
Hi, there,
I’m a Panasonic GH2 user. Recently, I found that RawStudio renders highlight (overexposed) region of my photo as pink color. I did some survey and realised that this may have something to do with dcraw. In fact, the results produced by RawStudio are exactly the same as those of dcraw using -H 1 parameter. Is it possible to fix this issue in the current version?
I also update the lensfun library for micro four-third lenses. Should I send my file to you or to the author of lensfun?
Thanks for all the work!!
Best.
Yes it is, but I need a sample file, so I can update the
See here, and preferably file a bug, so I don’t forget:
http://rawstudio.org/blog/?p=677
http://bugzilla.rawstudio.org/
And yes – we do not interfere with the Lensfun DB, so you can send them directly to the author.
I got it. I shell upload the bug to bugzilla soon.
Thank you again for your reply.:-D
cheers.
A better crop tool (with keep aspect, and switch between portrait/landscape) would be awesome! Also I wrote a (bit nit-picky) list on the 2.0 Release blog post: http://rawstudio.org/blog/?p=614&cpage=1#comment-1281
Looking forward to a new version!
That’s easy :)
Aspect can be selected on the right, when crop mode is active. To switch from landscape to portrait simply drag the corner to the new orientation.
I love rawstudio. Best thing since sliced bread, keep up the good work.
One thing that would be nice for me would be to improve on the multi-user work flow. By this, I mean that my wife and I both prepare photos for our blog from our own login accounts on the same computer. We have stickied the group attribute, and have our default permissions set to allow group rw but the default file permissions for the .rawstudio folders seem to ignore the system defaults and always create folders without group rw permissions.
Once I chmod the files, we’re in business. Love the time stamp sorting, and the ability to view raw and jpeg files at the same time. Wonderful tool.
I’d like to see a clarity filter similar to ACR. Can someone here also point out any available presets for RAWStudio?
Hmm, could you refresh your PPA with an Oneiric package of Rawstudio 2.0?
Thanks,
It should be there – it were published a day before your post…
Ineed. Great :) Thanks.
I’d like rawstudio to be usable as a raw developer from (lets say) shotwell. It would include a new mode that allows to open just one (or a set of files) (indicated by command line parameters) and to save jpgs based on the performed changes (if any) to filenames that have also been specified on the cli. This way, in an organizing tool like shotwell, the user could simply open specific raws with rawstudio, make changes, hit a save-button and exit rawstudio and see the result in the organizing tool.
Hello. I like rawstudio very much, I especially appreciate its speed, which makes it possible to process images relatively efficiently – not as fast as jpeg’s but faster than other tools working with RAW images.
What I am mostly missing is more powerful denoising. My Canon 60D is very noisy at higher ISO (say 1600) and in rawstudio even with the denoising sliders at 100%, there is still a lot of especially chromatic noise left. Canon’s DPP software can suppress this noise much more. This is at the expense of some blurring, sure, but it is an acceptable trade-off for me. For this reason, I need to use Canon software for my high ISO images, while I would much prefer to use rawstudio, for its better speed, ergonomics, and native Linux support.
My second wish would be for rawstudio to read and preset the camera settings, as Canon’s DPP does. This way, for most images the settings would not have to be altered at all.
Thank you and please continue your good work.
Yes – that is one of the main things I’m looking at.
With the current algorithm we cannot dial it up much further without some serious artifacts showing up. I’m currently working on modifying it so it can be stronger without artifacts showing up.
Another thing I’m also looking into is halo suppression when sharpening, for which I have the basic algorithm in place, but need to implement it.
All the way back onto Dariusz profiles comment:
That is exactly what I was thinking too, except I would like to have a profile that I can apply across all A’s then have an option to apply another across all B’s, ect.
Also would be nice to be able to save settings, and load them/select them from a list.
+1 Paul S.
Otherwise, excellent and quick!
Rawstudio lacks a slider for fill light (éclaicir the shadows without affecting the overall light level).
An android port would be nice with devices like the transformer prime around.
adobe has recently released photoshop and other creation apps for android as adobe touch series, and libre office is now working on a port.
How about some instructions on using Rawstudio.
I am new at using RAW.
I loaded a raw photo into Rawstudio tried to crop it, but could not see a way of getting the croped area as picture on it’s own.
When I turned the photo into JPEG it was on a 45degree angle when opened in any other program. How can I correct this?
More packages have included lensfun but I often find that manual adjustments produce better results than Hugin can for instance. I feel one of the problems is tilt when a shot is taken and find that simple sliders that can correct that and barrel and pincushion are best. Tilt can have 2 orientations. Camera up, down, camera tilted left right. Correcting lens distortions doesn’t really help.
Few lensfun data files have CA correction. Again I feel manual sliders are preferable. On many lenses CA is all over the place with zoom and aperture changes. There isn’t a one size fits all.
Noticing that shadow recovery has been mentioned I recently sort of ran Nikon’s ViewNX2 under wine. The shadow recovery seems to attempt to maintain contrast as the shadows are reduces. In other words it really relights shadow areas.
I feel an export facility is essential so save leaving huge files about when they are not needed. Some packages save processing setting in a file associated to the raw file that has been worked on. That way the 16bit output format file can always be regenerated quickly if needed. I would hope unlike a certain package that the export is a standard system call rather than
something aimed at a specific package. I finish off with one of several packages according to what I need to do. One package I use at that level has a neat solution to this. Other packages are linked to as if they were plugins. Any number of them. In this case when the other package is closed the calling package gets the modified image.
:-) I like the way rawstudio is going. Thanks. Next job is to try and build from source on the forgotten distro – opensuse. It never used to be a problem but of late it is more and more often.
John
–