Recent comments

Reply to: libraw interface   1 day 8 hours ago

So the -c is used for something else in Libraw. I am not successful in adding (VB Net 2015) a reference to LibRaw Dll
It just refuses to add it. I was not able to register it in Windows. So I am way off base Do I need anything more than the DLL? I wonder if there is anyone around who has actually done this. Just a bit of help would be good
Do I need to add anything more than the Dll My program finds and runs all the version emu, simple, etc but it wil lnt
pipe to memory
Help please

Its my lack of C (I am 80 and once used assembly language but not much C)

Reply to: Saturation   1 day 18 hours ago

user_sat is documented way to change maximum with guarantee you do not break anything

(for example, if you'll change maximum value after open_file(), but before unpack() it can result into data error exceptions/warnings).

Reply to: Saturation   1 day 18 hours ago

Thanks a lot. This is clear now. I can change the maximum. Just I can't imagine why and where it can be needed.

Reply to: Saturation   1 day 20 hours ago

user_sat is used to set sensor saturation (max possible) value. It is not related to HSL space

Reply to: libraw interface   1 day 22 hours ago

LibRaw (library) provides dcraw_make_mem_image() call, it should be accessible via VB.

.dll is provided with Win32 builds

Reply to: libraw_dcraw_make_mem_image returns image with empty data size   5 days 18 hours ago

I can't tell right now, the device in question was running an armv7 binaries. I couldn't reproduce the issue on an other device with arm 64 bit binary, but this device also had more memory. I'll try what happens if I run it on android with a x86 binary and report back.

[Edit]: On a x64 device I couldn't reproduce the same behaviour with the same image size, so it's possible that on arm are some other limits may exists. However, since I ported dcraw on arm previously and it works fine on the same device, I guess it has to do with some changes in libraw. May we can debug this, but I have no experience in debugging native code on android, the only way I'm aware of is doing logs in some lines.

Regards Torsten

Reply to: libraw_dcraw_make_mem_image returns image with empty data size   5 days 21 hours ago

Is the problem persists under x86, or it is Android-specific?

If I'll able to reproduce it under my common build environment (Windows, OS X, or FreeBSD) it will ease problem fix. Sorry, no Android tools on hands.

Reply to: libraw_dcraw_make_mem_image returns image with empty data size   5 days 23 hours ago

Hmm, do you have any idea where I could start finding out what's causing this problem? dcraw is returning 0 but width+height are zero. May it's possible to fix it in future versions, that woud be great.

Regards
Torste

Reply to: libraw_dcraw_make_mem_image returns image with empty data size   6 days 13 hours ago

Yes, it should not return 0

Reply to: libraw_dcraw_make_mem_image returns image with empty data size   6 days 13 hours ago

But if an error occurred, dcraw shouldn't return 0, or does it still continue and does not throw an exception which leads to a different result code? Because the dcraw call returns 0 which seems strange.

Reply to: libraw_dcraw_make_mem_image returns image with empty data size   6 days 14 hours ago

Followup:

if recycle() was called somewhere due to error, it will zero imgdata.sizes structure.
Also, dcraw_make_mem_image do not call CHECK_ORDER_* macros to check is processing stage correct or not (to be fixed sometimes).

Reply to: libraw_dcraw_make_mem_image returns image with empty data size   6 days 14 hours ago

Yes, sizes.width/height are set on open_file() stage.

Also, files with height or width less than 22 should be rejected on this stage (identify()'s function tail)

Reply to: libraw_dcraw_make_mem_image returns image with empty data size   6 days 14 hours ago

Well I digged a little into this, and dcraw_process runs without any exception and goes done to the "return 0" properly, but the values it's reporting afterwards (width & height) are just 0. So it seems like dcraw is failing in some kind of decoding stage, but this seems pretty strange since the overall image dimensions should be read at an early stage, shouldn't it? Is there any specific code segment I could may start looking into this more precisely?

Regards Torsten

Reply to: libraw_dcraw_make_mem_image returns image with empty data size   6 days 16 hours ago

Dcraw does not allocate extra memory buffer (for mem-image), so the problem may be here.

Reply to: Request for software names   6 days 21 hours ago

I'm planning to use Libraw in Photo Mate R3 (Android editing software), and switchting from dcraw for better mainability and better camera support.

Reply to: dcraw_emu output to specific position   1 week 1 day ago

Okay,

I will try, thank you for your reply!

Reply to: dcraw_emu output to specific position   1 week 1 day ago

Sorry, no such ability in dcraw_emu sample, output files names are always derived from source file.

BTW, full source code provided with LibRaw, so you may modify samples as you wish.

Reply to: Clipping of over-exposed image   2 weeks 2 days ago

Yes, -U switch sets auto_bright_thr.

Most likely you do not want to turn off black subtraction.

data_maximum is calculated during processing.

Reply to: Clipping of over-exposed image   2 weeks 2 days ago

Hi Alex,

Thanks for more information!

Is "-U 0.0" same as "auto_bright_thr = 0.0"?

Also, if I use "user-black = 0", will there be no "black subtraction" before demosaic?

I printed out the "data_maximum" value from a RAW, why the "data_maximum" is 0 before processing and 4095 after processing. Should it be same before and after?

Thanks,

Mio

Reply to: Clipping of over-exposed image   2 weeks 3 days ago

-U float-number changes auto-brightness threshold (default value is 0.01 so 1% of pixels brightened to clipping), so -U 0.0 may be useful

-W option turns auto-brightness completely off

Reply to: Clipping of over-exposed image   2 weeks 3 days ago

Hi all,

I take the opportunity of this comment to know what are the options to be used in command line (e.g. through dcraw_emu) to avoid any clipping. It seems that a clipping is done systematically whatever the different options...

By the way, I did not find an explanation of the 'gamma_curve' function which does different things depending on the 'mode' input...

Thanks for the help

Greg

Reply to: Clipping of over-exposed image   3 weeks 2 days ago

2nd white patch is clipped in G channel too (after WB applied, all channels to be clipped to make color white).

RawDigger overexposed area display (red overlay): https://www.dropbox.com/s/975db7gahr7ba7c/Screenshot%202017-04-06%2007.1...

RAW histogram of area on 2nd patch: https://www.dropbox.com/s/2a52m2057c50fbo/Screenshot%202017-04-06%2007.1...

Reply to: Clipping of over-exposed image   3 weeks 2 days ago

Hi, thanks for the quick reply!

The file appears to be clipped in the camera in the white patch on the bottom-left; however, the patch directly to the right of it isn’t. The conversion seems to clip both patches to the same or similar value. Can you look into this again?

Thanks so much!

Reply to: Clipping of over-exposed image   3 weeks 2 days ago

This file is already clipped in RAW.

See histogram peaks in G and B channels: https://www.dropbox.com/s/9ny0sk5easwbo6s/Screenshot%202017-04-05%2021.3...

Reply to: Clipping of over-exposed image   3 weeks 2 days ago

The last one (the bottom-left patch). Now the bottom-left patch has the similar code values as the ones of the patch next to it on the right.

Thanks a lot!

Pages