Recent comments

Reply to: LibRaw on RPi   2 years 10 months ago

Re "seems" - I was half-joking, I got your meaning, but wanted to make it clear to readers that I checked the things.
Good luck!

Reply to: LibRaw on RPi   2 years 10 months ago

My apologies re. "seems" - I did not intend to cast doubt on your reply. Thank you very much for all the helpful information, and for checking these installation instructions on your own RPi - that is greatly appreciated! I am looking forward to using LibRaw.

Reply to: LibRaw on RPi   2 years 10 months ago

The easy way to install is:

> sudo apt update
> sudo apt upgrade
> sudo apt install libraw-dev

To compile, install git, and after that:

> git clone https://github.com/LibRaw/LibRaw.git
> cd LibRaw/
> make -f Makefile.dist

To check,

> bin/dcraw_emu
Reply to: LibRaw on RPi   2 years 10 months ago

Thank you for the helpful information! So it seems LibRaw can be installed on an RPi - this is great!

Just to clarify, in the case where both options are available (apt install or compiling), is there a reason why I would choose one over the other (e.g. will the compiling option give me a newer version)?

Additionally, re. compiling, I found these instructions on rawpy's website (a package I'm hoping to use), which look similar to the instructions you provided above, but there are some differences - will either set of instructions work?

git clone https://github.com/LibRaw/LibRaw.git libraw
git clone https://github.com/LibRaw/LibRaw-cmake.git libraw-cmake
cd libraw
git checkout 0.20.0
cp -R ../libraw-cmake/* .
cmake .
sudo make install
Reply to: LIBRAW Thread Safety   2 years 10 months ago

Yes, you need to link with libraw_r on Mac/Linux (and, yes, Windows build is thread-safe)
Also, thread stack may be too small for on stack allocation (LibRaw rawProcessor), so dynamic allocation is preferred (LibRaw *rawProcessor = new LibRaw;)

Reply to: Fuji X-Trans files washed out colors in 2021   2 years 10 months ago

Thank you for your help.
Than I there is another issue related to the Java wrapper - Sorry for that. The output_color=0 was already commented out therefore was never active (leading slashes).

I have now removed the options and use the lib with the default options. After JDK18 I have to generate the sources from the header file again and will see if that helps.

Nevertheless under windows I had troubles with ljpeg-8d which is not compiling. For now I have removed libjpeg from all builds because it is not so important for the users.

Reply to: LibRaw 202101 snapshot   2 years 10 months ago

samples/raw-identify.cpp sample: removed lot of extra output used only by development team
I'm not sure this was a good change. It was great to be able to get more info about the files. Please add it back.

Reply to: Fuji X-Trans files washed out colors in 2021   2 years 10 months ago

I do not see color change due to user_qual=0 (output_tiff=0, half_size=0 are the default value).

BTW, you set output_color=0 too. This turns off camera color to sRGB (or other known colorspace) conversion and will result in washed colors.

Reply to: Fuji X-Trans files washed out colors in 2021   2 years 10 months ago

I have now found the issue which parameter is causing the problem. If one of those parameters below are set the colors are washed out. In 0.20.2 this is not happening.

libraw_output_params_t.output_tiff$set(params$slice, 0);
libraw_output_params_t.half_size$set(params$slice, 0);
libraw_output_params_t.user_qual$set(params$slice, 0);

Reply to: Fuji X-Trans files washed out colors in 2021   2 years 10 months ago

I try's the sample applications and you are right that all is working.

The problem is that the sample applications are not setting any params. As soon as you add my param list the output colors are also washed out.

I am using the following params to speed up decoding of x-trans files (For Canon/Nikon it doesn't matter). Without those parameters the encoding is much slower. But if I set only one parameter the color are washed out independently which parameter I set:
use_camera_wb$set(params$slice, 0);
use_auto_wb$set(params$slice, 0);
output_tiff$set(params$slice, 0);
half_size$set(params$slice, 0);
user_qual$set(params$slice, 0);

Reply to: Fuji X-Trans files washed out colors in 2021   2 years 10 months ago

Tested with dcraw_emu -T -w, for both 0.20-stable branch (from github) and for master branch (also from github).
I do not see great color difference here: https://www.dropbox.com/s/vdlbhfyd6e53pu0/Screenshot%202022-01-11%2021.4...

Files produced are also (temp.) stored on dropbox for your inspection: https://www.dropbox.com/sh/ek4rezjhju4xmmx/AACVcj-2X4G1EvI6cpkbpA3xa?dl=0

Please try to reproduce the problem using LibRaw's sample application (dcraw_emu or simple_dcraw). If these applications produces correct results, the problem source is probably in your code or in Java wrapper you use.

Reply to: Canon R5 CR3 Support?   2 years 11 months ago

EOS R5 (released in 2020) and R3 (released in 2021) are different cameras.

R3 will be supported in the next public version (snapshot or beta/release, whatever come first)

Reply to: Canon R5 CR3 Support?   2 years 11 months ago

Hi, i have same problem from cannon R3 cr3 (decoded with a purple tint) , that confuse me if R5 is supported

Reply to: CR3 to Tiff conversion results in different brightness levels   3 years 4 days ago

Brightness adjustement and maximum level adjustement are different things (wrong maximum may/will result into 'pink highlights' problem and auto-adjust works against it).

I agree, set_maximum_adj_threshold should be added to C-API.

Reply to: CR3 to Tiff conversion results in different brightness levels   3 years 4 days ago

Hi Alex,

with dcraw_emu using -M -o 0 -c 0 -j -W -q 1 -4 -T as arguments, both TIFF images converted from CR3 now look equally bright, and the two TIFF images converted from the corresponding DNG files also look equally bright. However, the TIFF images converted from CR3 and DNG differ in brightness. Is this by design?

I'm now trying to figure out how to use it programmatically. The parameter adjust_maximum_thr seems not to be accessible from the libraw_set_... API. I'm using C# with InteropServices. I think I can write such method and amend it to libraw; or better maybe you should consider the addition of this method (something like libraw_set_maximum_threshold).

I already used in my program:

```
libraw_set_no_auto_bright(handler, 1);
libraw_set_bright(handler, 1.0f);

```
so I expected no automatic brightness adjustment anyway.

Thanks, LelliD

Reply to: CR3 to Tiff conversion results in different brightness levels   3 years 5 days ago

(copied from E-mail, probably this answer may be interested to public)

To turn off automated maximum adjustement use dcraw_emu -c 0 (imgdata.params.adjust_maximum_thr = 0)

Reply to: CR3 to Tiff conversion results in different brightness levels   3 years 1 week ago

We never publish files that are sent to us without explicit permission.

Please use any file sharing service (e.g. WeTransfer/free option) and send the link to info@libraw.org

Reply to: CR3 to Tiff conversion results in different brightness levels   3 years 1 week ago

Hi,

I can provide the files (as long as they will not appear in a public forum). I think it would suffice to upload the two .CR3 files (35 MB each). Can you please show me a way to upload them?

Lellid

Reply to: libraw.dll?   3 years 1 week ago

We do not provide precompiled snapshot versions. Please contact vendor of your software to re-compile it with newer libraw.

Reply to: Different behaviour between git and 0.20.2 with wide char   3 years 1 week ago

Looks like your patch works like a charm.

Cheers,

Reply to: Different behaviour between git and 0.20.2 with wide char   3 years 1 week ago

Yes (if you do not use earlier github snapshots)

Reply to: Different behaviour between git and 0.20.2 with wide char   3 years 1 week ago

No problem: no risk no fun ;).
I will let you know.

Last question. Which version I could consider for your change?

LIBRAW_VERSION > LIBRAW_MAKE_VERSION(0, 21, 0) ?

Reply to: Different behaviour between git and 0.20.2 with wide char   3 years 1 week ago

As a result, you use very untested (and not supported) code path :)

Reply to: Different behaviour between git and 0.20.2 with wide char   3 years 1 week ago

I will test it.

In fact our code is cross-compiled with CI pipelines: can't use visual studio. Especially because we build it for linux too.

Pages