Recent comments

Reply to: Demosaicing seems not multi-threaded...   10 years 2 months ago

Yes, check for this bit if you're worried about AHD fallback

Reply to: Demosaicing seems not multi-threaded...   10 years 2 months ago

Thank you!
I've seen the field LIBRAW_WARN_FALLBACK_TO_AHD in LibRaw 0.17.
I suppose that testing (imgdata.process_warning & LIBRAW_WARN_FALLBACK_TO_AHD) after processing will allow one to display a warning.

Reply to: Kodak .dcr   10 years 2 months ago

Have you tested simple_dcraw and/or mem-image samples with these kodak samples?

Reply to: Kodak .dcr   10 years 2 months ago

Noted, my code converts all bitmap thumbs to jpg.

Reply to: Kodak .dcr   10 years 2 months ago

Again.
Kodak thumbnails *are not JPEGs*

Reply to: Kodak .dcr   10 years 2 months ago

I was blocked for some reason, so I was never able to post an example of the thumbnail I pulled:
https://drive.google.com/file/d/0B572ihVmygYtZW5PcTlHMHdyOG8/view

Reply to: Kodak .dcr   10 years 2 months ago

I've modified mem-image sample, added line:

printf("Type=%d\n",thumb->type);

after the line

libraw_processed_image_t *thumb = RawProcessor.dcraw_make_mem_thumb(&ret);

And, yes, mem-image -e writes thumbnail as expected (in PPM format because it it bitmap).

Also, our FastRawViewer (that uses LibRaw::unpack_thumb to extract thumbnails) works fine with these files.

Reply to: Kodak .dcr   10 years 2 months ago

I updated to the latest and see the same artifact. Is the thumbnail processed properly for you? No additional steps necessary to handle it as opposed to other bitmap thumbnail formats (which work for me)?

Reply to: Kodak .dcr   10 years 2 months ago

For both these images, thumbnail type is 2 (LIBRAW_IMAGE_BITMAP)

Checked with LibRaw 0.16 and with current (0.17) version.

Reply to: Kodak .dcr   10 years 2 months ago

I pulled these from a forum topic for testing:

http://s3t.it/data/uploads/rt_kodak_dcs_14nx_raw_photodesk.zip

Reply to: Kodak .dcr   10 years 2 months ago

It should work.
Could you please provide some file(s) for testing (Dropbox or google drive is a good way for file sharing)

Reply to: Kodak .dcr   10 years 2 months ago

Currently I'm checking:

libraw_processed_image_t *image = rawProcessor->dcraw_make_mem_thumb(&result);
...
bool isJpeg = image->type == LIBRAW_IMAGE_JPEG;

This doesn't work for kodak?

Reply to: Kodak .dcr   10 years 2 months ago

Some kodak files are very special in respect of thumbnails:
- the thumbnails are actually RAW data
-unpack_thumb() process them
- thumbnail.tformat is BITMAP for these images, not JPEG

Also, LibRaw 0.17 (alpha) has fixed several bugs relates to kodak thumbs.

So,
- upgrade to 0.17 (or Github master branch)
- ensure, that you handle thumbnail.tformat right

Reply to: Demosaicing seems not multi-threaded...   10 years 3 months ago

I've made the tests for OpenMP with the model 1 (which is the model that I use most often).
I never use model 0 because it makes the accuracy of tracked displacement worse; and never go after model 3.

Reply to: Demosaicing seems not multi-threaded...   10 years 3 months ago

Good question :)

I'll add bits to imgdata.process_warning field in coming LibRaw 0.17

Reply to: Demosaicing seems not multi-threaded...   10 years 3 months ago

I understand that fallback to AHD is automatic when 'libraw can not do otherwise'.
But my question was about the value stored by user_qual after dcraw_process.

I've made this test: set user_qual to 18 (to be sure to activate the fallback to AHD), call of dcraw_process, and then display the value of user_qual which were still 18. So, is there a solution to know if the fallback has actually happened?

Reply to: highlight blending && reconstruction - applied on bayer data or RGB?   10 years 3 months ago

LibRaw's dcraw_process() call is mostly identical to dcraw's processing.
Highlight recovery is applied after white balance and demosaic

Reply to: Demosaicing seems not multi-threaded...   10 years 3 months ago

Yes, fallback to AHD (user_qual=3) is explicitly stated in docs:
===
Values 5-9 are useful only if "LibRaw demosaic pack GPL2" compiled in (see README.demosaic-packs in your distribution for details). Value 10 is useful only if LibRaw compiled with "LibRaw demosaic pack GPL3". If some interpolation method is unsupported because LibRaw compiled without corresponding demosaic pack, AHD interpolation will be used without any notice.
===
http://www.libraw.org/docs/API-datastruct-eng.html#libraw_output_params_t

Reply to: Demosaicing seems not multi-threaded...   10 years 3 months ago

Right! I've made my tests too quickly.
Is user_qual set to 3 by libraw if the user set it to 9 for example (without additional demoniac packs)?
Anyway, it is now clear. Thank you very much for answering.

Reply to: Demosaicing seems not multi-threaded...   10 years 3 months ago

If you build libraw *without* additional 'demosaic packs', then interpolations from 5 to 10 are not compiled in (and library will fallback to user_qual=3, AHD interpolation)
OpenMP accelerated are:
ppg interpolation (user_qual = 2) and AHD (user_qual=3)

Reply to: Demosaicing seems not multi-threaded...   10 years 3 months ago

Yes, 'model 1' means 'iProcessor.imgdata.params.user_qual = 1' in my question.
Thank you for replying, it's good to know (I didn't find this information in the documentation).
After some rapid tests, it appears indeed that 'only' the interpolations 5 to 9 are OpenMP accelerated.
Thank you again!

Reply to: Demosaicing seems not multi-threaded...   10 years 3 months ago

'model 1' is 'VNG interpolation', right? This interpolation is not OpenMP accelerated in LibRaw.

Reply to: Demosaicing seems not multi-threaded...   10 years 3 months ago

Libraw contains several demosaic methods. Which one do you use?

Reply to: LibRaw processing order of operation && where to get RGB image that's not processed yet   10 years 3 months ago

The camera to sRGB matrix is in imgdata.color.rgb_cam[3][4] array.

This is 'device link'profile, you may multiply this matrix to another one (e.g. srgb to Adobe RGB) to get different output color space.

Pages