|
FAQ
FAQ
Q Are you going to implement RAW support in delaboratory? A It is possible to add RAW support by calling dcraw or using libraw, however, I don't really see good reason for that. There are mature raw processors (I use and recommend rawtherapee), I can't make anything better, I can only make whole workflow simpler (faster?). This is definitely not the top priority. Q Are you going to implement painting, dodge/burn, clone tool, healing brush, etc? A Currently delaboratory always works on previews - scaled down images. Each local modification requires access to full size image. So the first step in this direction is to implement zoom support. This is complex task and won't happen in the near future - color correction is more important. Currently I use local sharpening and clone/heal in GIMP. Q Are color profiles supported? A No. In my workflow I use 16-bit tiffs generated by rawtherapee, they have no ICC profile included, they are just sRGB and everything works as expected. I am aware of problem with ICC profiles in tiffs generated by dcraw or commercial raw processors. These profiles are ignored (but there is a message box to inform you about it). Please understand that delaboratory is my hobby project - to implement color profile management I must have good reason, and currently I don't see any. Q Can you add one more colorspace? A Tell me which one do you want and why do you want and where can I read about it. You can even add it yourself, this piece of code is quite easy (you just need to know equations for RGB conversion). Q Will you add more effects? A Yes, that's the plan. Currently I think about equalizer (similar to HSV equalizer from rawtherapee) and wavelet sharpen (see GIMP plugin). Q Will there be plugins? A Yes. I want to use GREYC's Magic Image Converter http://gmic.sourceforge.net/ for that, it's already used as plugin in GIMP (but limited to 8-bit per channel, in delaboratory it will of course use 32-bit per channel). Q Why 32-bit per channel? Isn't 16-bit enough for 16-bit images? A The output color depth doesn't really matter. If you only watch photos on monitor all you need on output is 8-bit per channel. What really matters is color depth inside the engine. 32-bit per channel means I don't have to worry about conversions and round errors. Of course there is a cost - twice larger memory usage. Q Does delaboratory support multithreading? A No, but it's a good idea for future releases. Currently every calculation is performed within one thread. Engine is designed this way that it should be possible to calculate channels in separate threads - the result will be (probably) much higher speed. Q What's the delaboratory direct competitor? A I am not aware of any application with similar design, philosophy and features. Please don't compare delaboratory with raw processors, GIMP or PHOTOSHOP - it's totally different approach. The main reason why there are no other applications with this set of features is that Free Software developers don't need them. Q Why are you creating this? A I love Free Software, I use it on my desktop since 1998. I bought my first digital camera in 2005, in 2009 photography started to be my really serious hobby. I quickly realized what are limits of GIMP, I was searching for alternatives - I discovered rawtherapee and GMIC. I was under heavy influence of Dan Margulis classic guide to color correction. The delaboratory is a product of all my experiences. In April 2011 I started first implementation. I code this project because I need it for my photos. It does what I need in my postprocessing. It fits exactly between rawtherapee and GIMP in my workflow. Q Can I help? A Yes! You can create package for your operating system or distribution (see Installation for existing packages). You can find bugs and report them here: http://code.google.com/p/delaboratory/issues/list. If you are a programmer - you can help with implementation of new effects (all you need is to know algorithm you want to add). |
► Sign in to add a comment
dcraw 9.11 -o 1 switch does send clear sRGB and makes your warning obsolute, no libtff needed. Imo it does outperform the RT raw engine, combined with delab.
Q : Where can I see your photography ?
> Please understand that delaboratory is my hobby project - to implement color profile management I must have good reason, and currently I don't see any.
It is pity to hear that especially when you deal with all those colourspaces. Only the LAB one defines the absolute colour, RGB for one have colour which definition is dependent on what colourspace it is in. For example, the RGB 255,0,0 is not the most saturated red in absolute scale (it is only so in the colourspace this is defined in - i.e. sRGB for example) so it cannot be converted the reddest red in LAB - you need to know what colourspace it comes from to see which red it corresponds to in LAB precisely. Considering the nature of delaboratory (colour correction) - which is to me to get the accurate/believable colour where you need it, your statement above that you have no need for that does sound strange. Please take it as a constructive criticism - I found the delaboratory a breath of fresh air in all the free graphical tools and it is exactly what is needed right now. Thanks for an excellent tool.
ashish I will put some photos in the future, I am still not not fully happy with my photographs so I don't want to use them to promote this project ;)
alexey I think I will need to change description of delaboratory, because lots of people believe that "color correction" means "to get the accurate/believable colour" while what I need is to manipulate colors in any way
there will be no support for color profiles or RAW in delaboratory 0.6, maybe I will use some RAW library later
> hat "color correction" means "to get the accurate/believable colour" while what I need is to manipulate colors in any way
I do realize that - I was mainly referring to skintones by that. However, in any colour correction it is good to start with the accurate colour to begin with - having tiff file in say BetaRGB and opening it in delaboratory to find out that all the colours are washed out is not a good idea. Again, delaboratory conversion to LAB from RGB converting relative colour to absolute - i.e. you need to know what RGB colour was actually referring to. And for that at least you do need colour management.
It is actually not that difficult - all you have to do is to define 3 RGB colourspaces: input one (the one that comes with the file or default), working one (the one that you have all internal RGB space stored in for all delaboratory image manipulation) and the one you convert to on save or export. LCMS2 I believe can handle all those.
Re: raw support, I would rather see the profiles support than that ;-). The reasons being that RAW is better left for specialised tools that do it best (RPP, Rawtherapee, Dark table, Photivo etc). Your tool currently excels in non-destructive colour correction and personally in my view its good to leave it at that ;-)
I am currently strongly against using color profiles, so RAW support would be kind of workaround. Will see in the future.
BTW Would be great if RAW docoders would export tiff in LAB format but I wasn't able to do that in RT.
> I am currently strongly against using color profiles
Would you care to elaborate why? I would understand if your entire workflow was in LAB all the way through but it is not and RGB by definition requires an extra bit of information to tell you what the colour really is.
> BTW Would be great if RAW docoders would export tiff in LAB format but I wasn't able to do that in RT.
RPP does save/export TIFF in LAB format. It is not open source but it is free
This is more "political" issue. I believe that you can take great photos with any camera ("your camera doesn't matter"), and this belief can be also extended to color gamut. There are sRGB 8-bit JPEGs on websites like 1x.com - are these photos bad?
Some RAW decoders are proud of using LAB, while delaboratory is able to use multiple colorspaces. At the same time.
You may wonder why I am not kind of "pixel peeper" person. I created delaboratory because I needed some features which were missing in existing applications, not to have "better more natural more accurate color" on photos.
> There are sRGB 8-bit JPEGs on websites like 1x.com - are these photos bad?
You are forgetting the fact that these are the final result. It does not mean that the processing has to be done in sRGB. It has nothing to do with pixel peeping either and if you want a more accurate comparison - compare the sRGB vs something like AdobeRGB or BetaRGB to 8bit vs 16bit editing. sRGB in some cases may not simply be enough even to hold some colours digital camera can produce and those will simply be lost in converting image to sRGB. No colour correction will bring them back just as it is with 8 vs 16 bit editing.
Currently each channel in delaboratory has values between 0.0 and 1.0. for instance 0.0 in each channel of RGB is black and 1.0 is white.
There is no problem to extend this range so for instance instead 1.0 the upper limit will be 2.0. This way you could achieve "wider gamut" on same color model.
If the RAW support will be inside delaboratory and it could be exported for instance to LAB, which is device independent, then all further data loss can be avoided this way.
this is not serious design or roadmap, I am just explaining my point
I have my priorities and I hope support for G'MIC will come earlier than support for LCMS and stuff like that.
> Currently each channel in delaboratory has values between 0.0 and 1.0. for instance 0.0 in each channel of RGB is black and 1.0 is white.
Yes but what about reading the RGB TIFF files and writing them? I was not talking about internal representation of the image - in the workflow I referred to out of 3 RGB spaces, the internal one is the least important. Reading and writing are more. An example with the same pure red (255,0,0) colour - in your internal model it will correspond I take it to (1.0,0,0) but the (255,0,0) coming from sRGB TIFF is not the same as (255,0,0) coming from AdobeRGB TIFF and in absolute space they won't be mapped to 1.0 (depends how you use that internal space). Since colour correction also relies on visual feedback, how is that internal representation in delaboratory actually converted to be displayed? I take it, it does not support any display profiles so how could you be sure that your edits say to make skintones warmer are actually making it warmer? True, it may roughly work on 90% cases but then again all you have to came across is a monitor that deviates from sRGB enough to introduce unwanted effect and the edits will result in something you have not seen on a monitor. As an easy example of that - what would happen to the colours if you do colour correction in delaboratory on Dell U2410 monitor set to aRGB mode? My guess would be your image end up overly saturated and not what you seen when editing it.
I understand its your creation and I am not arguing about your priorities, I just trying to say that for colour correction (whether for accurate colour or not) it does matter and a great deal.
"Yes but what about reading the RGB TIFF files and writing them?"
correct, that's why I said RAW support may be workaround :)
"Since colour correction also relies on visual feedback, how is that internal representation in delaboratory actually converted to be displayed? "
and that's the second reason why implementing color profiles is not trivial, currently I just convert color to RGB (which is sRGB) and display it on screen via wxWidgets
I agree that accurate color display is important, and for some people it's most important thing, but this is my hobby project, I have my priorities and this feature is far less important than stable multithreading, support for external plugins like G'MIC, better UI, more layers (c2g, wavelets, etc).
That's why I will probably need to change the project description, because people see "color correction" and instead look at the revolutionary features they are confused that there are no ICC support.