delaboratory 0.7.4 has been released, this should be last beta before stable 0.8 release, so if you are able to crash it, please let us know

changes: more basic (single click) operations available, improved gradients, LAB TIFF images support. bugfixes

Downloaded Delaboratory-0.7.4-32bit. Everything works fine except if I try, "Send to Gimp". The following screen shot shows the Delaboratory error message and below it the actual path to the temp file. Note the forward slash in the Delaboratory error dialog.

Do you have gimp-2.8 installed?

You can always export TIFF and open it in Gimp manually.

I think we already mentioned before that you need my Gimp builds to get "Send to Gimp" to work. You need Gimp 2.8 or higher.

I don't know how Ender packages the official Gimp to figure out how Gimp is started when you start from the commandline.

Can you start Gimp from the commandline using verbose (gimp --verbose) and provide the output to me?

Thanks,
Partha

Currently gimp is started by calling "gimp-2.8" executable, we can replace it with anything else, on Linux it is just "gimp". But we can't make it definable by user because there is no user configuration. So propose any solution if you know it. We can also create two or three export options for Windows gimp, i.e. call "gimp-2.8", "gimp-2.6" and "gimp" if that helps.

Sweet! Another release so soon.
Thanks guys.

I had no problems exporting to Gimp-2.8 (Parthas install)
Very nicely done.
Hey is there any chance "Crop" could be added to the mix?

I think crop and denoise function would make it a perfect raw-convertor as well.

Of course, you could crop in Gimp. But denoise would be good. Jacek and I spoke about wavelet functions a while back.

In my workflow I do all color correction and vignette/gradient/local_contrast in delaboratory, then I export to gimp and then do crop and clone/healing. Or I export all layers and open it in gimp later.

The crop would be very usable, but it's not easy. Please notice that I implemented rotation/mirror in source image layer and it was much harder that I expected. The denoise is typical raw processor operation so I wasn't implemented it, another reason is that I never use denoise.

Features like that will be implemented in future, now we need to focus on stable 0.8 release which will be last wxWidgets version (and probably last stable version for a long time) and then I will start using gtk+ and let's hope I will make it at least as functional as it is now.

Looking forward to it!

delaboratory 0.7.9 has been released, this is almost final 0.8, we just need to make sure it won't explode before calling it STABLE

the code is similar to 0.7.4, I just removed lots of logging so logs are now shorter and there is less writing to disk during editing, Partha implemented external editor via environment variable (this is supported on Windows only), and action buttons have now same size have fun

All, if you have my Gimp installed, you are good to go and now need for further action from you. However, if wish to test out other pixel level editors (Gimp 2.6.x, Paint Shop Pro, Photshop etc.), set an environment variable called GR_EDITOR to the full path of the editor's executable. Restart Delaboratory, and use "Send to External Editor" and it should open your image in the editor of your choice.

So the Workflow is (after the above):

Delaboratory (Color correction) -> Send to External Editor -> Opens your pixel editor.

Needless to say, this only works on Windows.

As usual, if you have any questions, please let us know.

Thanks,
Partha

Not sure if I should post here in this thread but did some searching and nothing came up....

I am trying Delab .8 with DNG files on Win7x64 (with 4 gigs ram) with the Partha Gimp 2.8.1x64 and with a very minimal edit when I try to export from Delab to Gimp, I get a message "exporting final image failed - error during update images (probably out of memory). I click ok then get an error "D:\TEMP\TEMP/IMGP2641.tiff: Cannot open (in module: "TIFFOpenW")

Thanks
Todd

Edit: Should have mentioned this is also after adding the environment variable (tried both C:\Program Files\Gimp-2.8.1\bin\gimp-2.8.exe and C:\Program Files\Gimp-2.8.1\bin\gimp.exe)

Todd,

The message means exactly that. Delaboratory ran out of memory while creating the image. You have not mentioned how large the image is or how many stacks (layers in your final composition) you have. Since the final image is not being created, there is nothing for Gimp to open.

Since you are using my builds, no need to set any environment variables. You can test this with some other image that does not give you the memory error.

Is it possible to post the DNG image somewhere so that we can take a look?

Thanks,
Partha

Edit: Can you also post the debug log file at the delaboratory site? It will be located in your Appdata/Roaming/Delaboratory folder.

This is probably bug, but please provide debug.log, it should show was there problem with memory or some other thing.

For a test, please try to export jpg or tiff file to your local directory, it may be also lack of disk space in temp.

I can export jpg/tiff to local successfully.

The DNG's I've tried are all 15-25mb roughly... I also just went and tried a smaller 11mb PEF and got the same results. (The last one I tried was 23 megs)

I have also tried opening and immediately exporting and it's the same error... How much memory roughly would this take? I did move my temp folders from C: to D: because I use an SSD for my OS drive, but I don't think there is a size restriction on that directory... It's already around 700mb just from my FF cache...

Does it matter if I leave or remove the environment variables I added, since I am using a partha gimp build?

If you can export TIFF but you can't export to gimp then something is wrong.
Because exporting to gimp is just exporting TIFF and then calling gimp.

Are you sure you are not running end of disk space in TEMP?

Are you sure provided debug.log is from failed run? I don't see any errors, I see you saved TIFF file and then closed delaboratory.

PS. For memory problems size of source file doesn't matter at all, only resolution matters. For disk space problems see size of exported TIFF.

Ok so I closed FF, emptied the cache/temp and deleted the log and retried a different DNG and got same error. Here is the log.

It's good to know then that all it's doing is calling gimp at the end, because I can just export to tiff and open that in gimp... It's going to 8-bit in gimp either way, right? (dumb question but just making sure there is no advantage other than convenience)

Another question, is there any way to auto brighten in delab once the file is open? I like to right click on a file and 'open with' delab but it defaults to pro photo with no auto brighten.... I like the auto brighten feature you have there, but don't see it in the app once the file is open..

Delab is so cool guys! Keep up the great work.

By analyzing log I found that your problem is not related to memory at all.
(Sorry you are first person with this problem and I couldn't prepare correct error message in 0.8.)

The only possibility for this error is that you can't create TIFF file in:

D:\TEMP\TEMP/IMGP0805.tiff

are you sure D:\TEMP\TEMP is proper path on your disk?

I think you mixed some settings for temp, could you check it?

If you can't fix it then just create D:\TEMP\TEMP dir.


About auto-brighten, I added this option in last day of development, because I assumed some people may not like the idea of ProPhoto or that they may think that loaded image is too dark. It's available only from menu and you can't easily "reopen" the image you loaded, you need to click it again.

The default option is best one, but I agree it may be confusing, I just assure you there is nothing you lose this way (each pixel is stored as set of floats, if you brighten your image manually you will not lose anything).

Yes, this fixed it.. Thanks! I don't know why I didn't realize that temp folder was not there.. I added "tmp" and "temp" via environment variable, but the one that was being used was "tmp"...

I don't even know what ProPhoto is yet, but plan to read about it.. :-)

ProPhoto is wider colorspace than sRGB. So it may happen that your photo is overexposed in sRGB but not in ProPhoto. However, I set contrast in ProPhoto to 90% to avoid overexposing when converting later to sRGB You may change it with slider in source image layer. The goal was to recover as many highlights as possible. The downside is that your photo is more "gray" by default, because it lacks full contrast. But it doesn't matter if you follow Dan Margulis way of postprocessing with curves.