Recent comments

Reply to: White Balance in Digital Cameras: Problems   13 years 3 months ago

Link to Rawnalyze backup copy: http://rawnalyze.rawtherapee.com/

Reply to: new cameras   13 years 3 months ago

Thanks for your patch.

It is integrated into LibRaw 0.11.3 and into coming LibRaw 0.12

Reply to: About LibRaw   13 years 3 months ago

You can integrate C-code in MATLAB using the mex-API. I looked at this for dcraw, but got stuck, and I found that it was simply less work to make a thin MATLAB wrapper calling dcraw from the command-line.

I remember some frustrating aspects of doing anything to the dcraw code, hope that this project makes it easier.

(the spam-filter here really hurts!)

Reply to: Reading color   13 years 4 months ago

Yes, output is converted to 8-bit only on file/memory writing stage (i.e. on output).

So, you may call dcraw_make_mem_image() to create 3-component 8-bit bitmap.

Reply to: dcraw_emu.exe versus dcraw.exe   13 years 5 months ago

LibRaw (and, so, dcraw_emu) contains 'auto-maximum' feature to deal with 'pink clouds' problem.
If you want to produce files which are binary identical to dcraw's results, you should switch this option off. Use -c 0 switch of dcraw_emu to do that.

Reply to: how to import Libraw in Digikam   13 years 5 months ago

New versions of LibRaw are imported in KDE (libkdcraw) very fast. Usually in 1-2 days. So you just need to update your KDE extra libs from KDE trunk

Reply to: Asking advice for storing raw files   13 years 5 months ago

The only real and easy solution is to write your files in .DNG format. Sure, there is no way to write CR2

Reply to: Image resolutions   13 years 7 months ago

Please see:
http://www.barrypearson.co.uk/articles/dng/specification.htm#areas

Using dng_validate or an EXIF metadata viewer should be able to tell you the resolutions of the various areas in your DNG file.

Reply to: Crash when freeing a libraw_processd_image_i   13 years 9 months ago

The libraw_memmgr::free() is very simple, it just calls upper level ::free than forgets the pointer:

    void  free(void *ptr)
    {
        ::free(ptr);
        forget_ptr(ptr);
    }

So, if your code crashes in ::free(), it should crash in LibRaw's free() too. For pointer allocated by ::malloc() there is no difference between LibRaw::free() and ::free().

I cannot reproduce this problem in my Windows enviroment (VS2008 SP1, Win7/x64).
Could you please describe your enviroment in more detail (VS2008 patch level, Windows version, may be sample code)?

P.S. Sorry for very aggressive captcha. This is the only way to prevent forum/comments spam.
Please note, that registered/authorized users are not terrorized by captcha :)

Reply to: Crash when freeing a libraw_processd_image_i   13 years 9 months ago

I also encounter this problem.
In my project I link the libraw (I use Visual Studio). Everything works fine.
However if I want to free (using ::free(ptr)) the pointer returned by dcraw_make_mem_image(...) I get an exception
_CrtIsValiHeapPointer(pUserData) documented in dbgheap.c with
/*
* If this ASSERT fails, a bad pointer has been passed in. It may be
* totally bogus, or it may have been allocated from another heap.
* The pointer MUST come from the 'local' heap.
*/
_ASSERTE(_CrtIsValidHeapPointer(pUserData));

I think the problem is caused that the lib is creating the memory, so only the lib itself is allowed to free it afterwards. The application does only seem to have rights to read the memory.
If I also make the free function public in class LibRaw it seems to work, but there should be a more elegant solution ;)

Regards Tobias

Reply to: OpenMP problems compiling   13 years 9 months ago

Since LibRaw 0.9, the OpenMP pragmas are effective only on LibRaw compile time, not at apps compilation.

Reply to: Crash when freeing a libraw_processd_image_i   13 years 9 months ago

the image is allocated by 'upper level' (system) malloc, not LibRaw's one:

libraw_processed_image_t *ret = (libraw_processed_image_t*)::malloc(sizeof(libraw_processed_image_t)+ds);

So, it should be free-ed by system free(), not LibRaw::free();

Please describe your enviroment in more details.

Reply to: Dan Margulis on RAW module   14 years 3 months ago

Good evening Dan!
I'm a moderator of Russian CG Forum Arttower.ru. Could you give us the permisson to publish the Russian translation of this article (http://www.libraw.su/articles/raw-module.html) on our site?

Reply to: cin / stdin   14 years 5 months ago

LibRaw need to seek to arbitrary position in input stream. So, there is no way to read from stdin.

You may implement you own LibRaw_datastreeam class with full buffering.

Reply to: Random And Groundless Thoughts On Color Control In a Raw Convertor   14 years 6 months ago

http://www.digitalcolour.org/toolbox.htm

Dr Green has matlab code for CIECAM02.

As for profiles. There is not a profile as such. You need to determine your own cameras RGB to XYZ response. If you have a D70s I could send you some matrixes that I made earlier. I am in the process of publishing a paper on the subject. Ill keep you posted.

Reply to: Random And Groundless Thoughts On Color Control In a Raw Convertor   14 years 6 months ago

Looks very promising.

Is there some code (plus profile) to play with?

Reply to: Random And Groundless Thoughts On Color Control In a Raw Convertor   14 years 6 months ago

Hi

I successfully applied CIECAM02 to a RAW imaging workflow. The main problem was to identify the adopted white from scene colorimerty as an input to CIECAM02. I ended up using the cameras white balance for ease in order to complete the experiment. The scene illumination was calculated from ISO and Exposure and gave favorable results. The main part of the process was to characterise the camera using a double monochromator and calculate the cameras spectral response. This was then used to determine the device RGB to XYZ matrix by reducing errors in JMH space for different values of La and white point.

The resulting matrices were used to transform RAW RGB to XYZ according to scene white and La and then passed through CIECAM02.
The internal coordinates used were JMH and output to standard sRGB viewing conditions through the reverse CIECAM02.

I got some pretty good results, (although maybe not appearance perfect) compared to the sRGB JPEG produced by the Nikon D70s.

DCRAW and Matlab used for computation.

Reply to: Limit on number of images in file?   14 years 6 months ago

The problem is in MacOS X fseek() call. It takes 32-bit offset (long int). There is fseeko() function which takes off_t offset and so will work with files larger than 2Gb.

The quick fix:
in libraw/libraw_datastream.h change:
return substream?substream->seek(o,whence):fseek(f,o,whence);
to
return substream?substream->seek(o,whence):fseeko(f,o,whence);

This will break compatibility with Windows (no fseeko) and, possible, Linux. I'll prepare more universal solution (with #ifdef) today or tomorrow (to appear in 0.8-Beta5)

Reply to: Limit on number of images in file?   14 years 6 months ago

There is two news, good one and not-so-good :)

1. Frame offset is stored as 64 bit in this format, so there is no *theoretical* problems.

2. There is two possible sources of problems under Mac OS X:
a) one possible source is 32-bit off_t type (i.e. some special compilation flags are needed because 64-bit offsets are possible)
b) FILE * interface under Mac OS X does not support large files.

I've MacBook with MacOS 10.5 on hands, so will continue investigations. Hope, I'll find problem source today.

Reply to: Limit on number of images in file?   14 years 7 months ago

Oh, sorry.

I've downloaded this file several weeks ago, than make LibRaw 0.8-b4, than forgot about file.

Will work with it tomorrow.

Reply to: Limit on number of images in file?   14 years 7 months ago

gentle ping....

M

Reply to: Limit on number of images in file?   14 years 7 months ago

Hi, many apologies for the long delay, I got food poisoning after the last post,
and I've been trying to catch up ever since.
I've put a test file on http://www.modern-industry.com/test.cine Its about 49MB.

Mike

Reply to: Random And Groundless Thoughts On Color Control In a Raw Convertor   14 years 8 months ago

It is the same case with the brightness contrast: for the majority of street scenes, there is an empirical desire to increase the brightness. This effect was measured by Stevens and Stevens 45 years ago, and the results can be quantitatively used. The reason why you need to increase the contrast of the printouts is the same: you look at them at a much dimmer and duller light than the one that was present during the shooting and presumed by the viewer.

Sorry, link to warez site deleted by LibRaw admin

Reply to: Limit on number of images in file?   14 years 8 months ago

You say '16Gb' ?

For many file types data_offset of frame data is read as 32-bit integer (via get4()). So, maximum frame offset is 2Gb.

To check this I need some sample with several frames. I don't need full 16-Gb file multi-multi-frame file, but file with 3-4 frames will be enough.

Reply to: Limit on number of images in file?   14 years 8 months ago

I'm afraid it may not be very easy to repeat, as the file I'm using
is a .cine file of around 16G! I know this sounds an extreme case, but
some professional movie cameras shoot raw...

I didn't use any special switches, just something of the form of

dcraw_emu -s 700 mytestfile.cine

I'm afraid that I'm going to be very busy for the next couple of days, but
a good experiment I might perform would be to create a file with very small frames, so I
can find out if the frame count or the file size is the issue. That might
also create a test case that can be loaded via the Internet.

Mike

Pages