Recent comments

Reply to: highlight recovery regression...   13 years 4 months ago

Thanks for report, to be tested.

Sorry for delayed answer, summer is vacation time.

Reply to: ./configure failing on OS X   13 years 4 months ago

According to configure output, your Xcode package is not installed correctly. The gcc is unable to compile small test program:

configure:2940: g++ conftest.cpp >&5
ld: library not found for -lcrt1.10.6.o

I've tested the configure script under 10.6.8 with Xcode 4.x without any minor problem. I've used Xcode 3.x several months ago without any problem too.

Reply to: Festina Lente   13 years 7 months ago

Well, those comments are for raw converter developers.

Reply to: Festina Lente   13 years 7 months ago

Where is the floating point implementation?

Elle Stone

Reply to: Festina Lente   13 years 7 months ago

Iliah, You say "It looks like the time spent in postprocessing to get more details and counter-act artifacts might be better spent if demosaicking prepares a cleaner and more detailed image to start with. The processing time difference between integer and floating point implementations of demosaicking most of the times is less than 5 seconds, which is substantially less compared to the time spent on image editing to get close to the same result. Try it, and you will see. "

How does one go about "trying it" to see? What about this comment:
"For float data output we need to change entire processing pipeline to floating point." from http://www.libraw.org/about?

Elle Stone

Reply to: Unscaled 16 bit RGB access   13 years 7 months ago

The data scaling is performed before interpolation.

So, there is no way to get debayered and unscaled data. You may remove call to scale colors or rewrite this call (LibRaw::scale_colors) if you wish.

Reply to: half_size and dcraw_make_mem_image()   13 years 8 months ago

Perfect, everything works. Thank you!

Reply to: half_size and dcraw_make_mem_image()   13 years 8 months ago

The problem is very simple:
- you have set half_size=1 *after* unpack is called. So for the very first run the half_size is not set for unpack stage but set for postprocessing stage.

But half_size option is heavily used on unpack() stage (only 1/4 of image array allocated, pixel data placement is very different).

You need to move
rawProcessor_.imgdata.params.half_size = 1;
line above of unpack() call.

Reply to: half_size and dcraw_make_mem_image()   13 years 8 months ago

The case is confirmed, your code really produces different first image (have not looked into it, but see by different MD5 sums).

Thanks again for your bug report. I'll write another comment here when bug will be fixed

Reply to: half_size and dcraw_make_mem_image()   13 years 8 months ago

I'm using LibRaw 0.13.1. I've tested on Windows and macosx; and in each case there is a difference between the first and the second decoded image.

Reply to: half_size and dcraw_make_mem_image()   13 years 8 months ago

Thanks for bug report.
It looks very strange for me because I use half_mode in my programs without any problem, but I'll test your code sample.

What version of LibRaw do you use?

Reply to: half_size and dcraw_make_mem_image()   13 years 8 months ago
#ifdef WIN32
// suppress sprintf-related warning. sprintf() is permitted in sample code
#define _CRT_SECURE_NO_WARNINGS
#endif
 
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <math.h>
#include <ctype.h>
#ifndef WIN32
#include <fcntl.h>
#include <unistd.h>
#include <sys/stat.h>
#include <sys/mman.h>
#include <sys/time.h>
#endif
 
#include "libraw/libraw.h"
#ifdef WIN32
#define snprintf _snprintf
#include <windows.h>
#endif
 
 
void write_ppm(libraw_processed_image_t *img, const char *basename)
{
    if(!img) return;
    // type SHOULD be LIBRAW_IMAGE_BITMAP, but we'll check
    if(img->type != LIBRAW_IMAGE_BITMAP) return;
    // only 3-color images supported...
    if(img->colors != 3) return;
 
    char fn[1024];
    snprintf(fn,1024,"%s.ppm",basename);
    FILE *f = fopen(fn,"wb");
    if(!f) return;
    fprintf (f, "P6\n%d %d\n%d\n", img->width, img->height, (1 << img->bits)-1);
/*
  NOTE:
  data in img->data is not converted to network byte order.
  So, we should swap values on some architectures for dcraw compatibility
  (unfortunately, xv cannot display 16-bit PPMs with network byte order data
 
#define SWAP(a,b) { a ^= b; a ^= (b ^= a); }
    if (img->bits == 16 && htons(0x55aa) != 0x55aa)
        for(unsigned i=0; i< img->data_size; i+=2)
            SWAP(img->data[i],img->data[i+1]);
#undef SWAP
*/
    fwrite(img->data,img->data_size,1,f);
    fclose(f);
}
 
int main(int argc, char *argv[])
{
	char filename[] = "raw_canon_550d.cr2";
	LibRaw rawProcessor_;
	int rc;
	for (int i = 0; i < 10; i++)
	{
		libraw_processed_image_t* rawImg = NULL;
		rc = rawProcessor_.open_file(filename);
		rc = rawProcessor_.unpack();
		rawProcessor_.imgdata.params.filtering_mode = LIBRAW_FILTERING_AUTOMATIC;
		rawProcessor_.imgdata.params.output_bps = 16; // Write 16 bits per color value
//		rawProcessor_.imgdata.params.gamm[0] = rawProcessor_.imgdata.params.gamm[1] = 1.0; // linear gamma curve
//		rawProcessor_.imgdata.params.no_auto_bright = 1; // Don't use automatic increase of brightness by histogram.
		rawProcessor_.imgdata.params.document_mode = 0; // standard processing (with white balance)
		rawProcessor_.imgdata.params.use_camera_wb = 1; // If possible, use the white balance from the camera.
		rawProcessor_.imgdata.params.half_size = 1;
		rc = rawProcessor_.dcraw_process();
		rawImg = rawProcessor_.dcraw_make_mem_image(&rc);
		char ppmfname[128];
		snprintf(ppmfname,1024,"%04i",i);
		write_ppm(rawImg, ppmfname);
		rawProcessor_.dcraw_clear_mem(rawImg);
		rawProcessor_.recycle();
	} 
	return 0;
}
//not truncated
Reply to: random Crash with CRW file in memory stream   13 years 8 months ago

If i read doc, i can use it's memory stream which received file :/ but random crash appear. It's like stream size is incorrect (and it's possible ^^).

Now it's works perfectly for me when i'm embded my memory to edsdk MemoryStream.

For edsdk, you probably wait a long time before receive an answer...

Reply to: random Crash with CRW file in memory stream   13 years 8 months ago

Is is possible, that ESDK memory is protected from outside access and only ESDK call may use it?

Unfortunately, I've no reply from Canon-Europe yet, so cannot look into ESDK.

Reply to: random Crash with CRW file in memory stream   13 years 8 months ago

Memory manager is used (and inlined) only within LibRaw::* calls.
These calls (including constructor) are not inlined, so there are no problem with it.

There *was* a problem with LibRaw::make_mem_image() call in previous versions of LibRaw: if you're allocated mem_image within LibRaw and free() it within your app, you're in trouble. The problem is fixed in 0.12 or 0.11 or so by providing extra call ..clear_mem_image()

But the problem was *not* random, it appear every time and within free() call, not in memchr() as in your case.

Reply to: random Crash with CRW file in memory stream   13 years 8 months ago

Good news.
If i use my memory to dowload cr2 file with edsdk, i haven't crash :D

thanks.

Reply to: random Crash with CRW file in memory stream   13 years 8 months ago

Like LibRaw expose libraw_memmgr memmgr; i think memmgr use malloc and free from crt associated with application. Not with crt associated with the dll. Internally that can cause CRT error.

I test with my application. I've always a crash in memchr. But i think it's a multithread error with edsdk and COM initialization.

thanks for help.

Reply to: random Crash with CRW file in memory stream   13 years 8 months ago

No-no.

libraw (.a, .so) is compiled with -DLIBRAW_NOTHREADS, so some internal decoder buffers are static. This is faster, but this library is not reentrant. You may use it in multithreaded environment, but not for decoding several files in parallel

libraw_r is compiled with -pthread and without LIBRAW_NOTHREADS define, so all I/O calls are made via thread-safe version and decoder storage is allocated within LibRaw class. So, extra locks, extra indirection for storage, but thread-safe.

Not reentrant version is several percent faster.

Reply to: random Crash with CRW file in memory stream   13 years 8 months ago

Yes, memory manager is exposed to public. But the code that uses memory manager is entirely within DLL, including LibRaw class constructor and all methods.

The problem may occur only with link time code generation, but LibRaw.DLL do not use it.

Anyway, 4 different DLLs should solve the problem.

Reply to: random Crash with CRW file in memory stream   13 years 8 months ago

In the best, is that i understand.

I thinks if you use pimpl idiom on LibRaw class you can remove this problem.
If i understand correctly the error, your libraw_memmgr implementation is declared in .h and is inlined.
So when you use it in application free and malloc are not the same that use in the dll.

http://support.microsoft.com/kb/140584/en-us

Reply to: random Crash with CRW file in memory stream   13 years 8 months ago

libraw_r is C api ?

Reply to: random Crash with CRW file in memory stream   13 years 8 months ago

Thanks for info.

It looks like I need to provide four different DLLS:
librawT.dll - /MT
librawTd.dll - /MTd
librawD.dll - /MD
librawDd.dll - /MDd

Oh! Windows make me crazy!

Reply to: random Crash with CRW file in memory stream   13 years 8 months ago

For Windows version the context is stored in object. So, it reentrant.

For Unix version, the default is not re-entrant, but libraw_r library is reentrant.

Reply to: random Crash with CRW file in memory stream   13 years 8 months ago

I've test with valgrind. No memory error found ^^

I check your build option and my visual project option. We have a difference .
You use /MT and i use /MD. In this config, on an xp the main example crash on the first unpack.
If i change you option to use /MD it don't crash :D
I found more information about this mix error here :
http://msdn.microsoft.com/en-us/library/2kzt1wy3(v=vs.71).aspx


Caution Do not mix static and dynamic versions of the run-time libraries. Having more than one copy of the run-time libraries in a process can cause problems, because static data in one copy is not shared with the other copy. The linker prevents you from linking with both static and dynamic versions within one .exe file, but you can still end up with two (or more) copies of the run-time libraries. For example, a dynamic-link library linked with the static (non-DLL) versions of the run-time libraries can cause problems when used with an .exe file that was linked with the dynamic (DLL) version of the run-time libraries. (You should also avoid mixing the debug and non-debug versions of the libraries in one process.)

I'll check tomorrow with my application if it's only that.

ps :I think you should propose a debug and a release dll with /MD and /MDd option.

Pages