Delphi Wrapper?

Does anyone know of a Delphi wrapper that could allow LibRaw to be used in Delphi? I'm using Delphi 10.1 Berlin and would like to be able to use the API in my applications.

Thanks,
Mike

Forums: 

AFAIK, Delphi developers use

AFAIK, Delphi developers use LibRaw C-API (do not know it needs additional wrapper level or not)

-- Alex Tutubalin @LibRaw LLC

Laheller, thanks for the

Laheller, thanks for the wrapper. It works for colour images but at the moment not for extracting unprocessed raw.

The second green color is missing. I get RGB0 where 0 stand for zero value. See this screen shot.

https://ibb.co/d0TD6Lv

I do the following

libraw_open_file
libraw_unpack
libraw_raw2image
libraw_dcraw_make_mem_image

Maybe Alex can clarify:
Why is the second green missing and how to fix? Having the raw packed in a three color image is not a problem but the missing second green is a problem.

Is this the LibRaw standard way for getting unprocessed raw: "getting three buffers: RED, GREEN, and BLUE. All buffers have the same sizes (size of the image) but with “holes” in the place of other colors pixels." or is a better way?

And what is also puzzling is in an other program setting libraw_set_output_color(handler, LibRaw_output_color.raw); doesn't do anything either.

Han

Han, what camera files do you

Han, what camera files do you test with?

Fujifilm X-Trans (6x6 pattern) files are 3-component, there is no 'second green'.

There is no way to get separate image planes via LibRaw:
- unprocessed data (assuming we're talking about bayer/xtrans camera) is single layer
- intermediate data(after LibRaw::raw2image) is a 4-component per pixel interleaved (4th component is not used in X-trans case)

-- Alex Tutubalin @LibRaw LLC

I have tried two camera

I have tried two camera images:

CR2, EOS 80D
CR3, EOS R

unprocessed_raw.exe writes normal raws. The 3 layer format is not a problem but then missing second green, G2 is essential

Understood the problem.

Understood the problem.

make_mem_image() is not targeted to make copy of intermediate state if imgdata.image[] content.
it is targeted to create 3-component image (RGB) from 4-component imgdata.image (also, rotation, 16-8 bit conversion and gamma curve is applied).

make_mem_image() assumes that all processing is already done, so RGB image is contained in first 3 components of 4-component imgdata.image[][4] pixel.

If one need to access unmodified imgdata.image data it should be done directly.

-- Alex Tutubalin @LibRaw LLC

??? Your code is calling

??? Your code is calling raw2image, but not calling dcraw_process().....

Also, current processing stage is reflected in imgdata.progress_flags

-- Alex Tutubalin @LibRaw LLC

I don't have a solution for

I don't have a solution for it at the moment. I assume it has to do something with ushort but the current Pascal wrapper doesn't contain a reference to it. I can only hope Laheller has a solution for it.

ushort (*image)[4];
The memory area that contains the image pixels per se. It is filled when raw2image() or dcraw_process() is called.

I cannot understand how it

I cannot understand how it happens:
- you're able to access libraw_processed_image_t fields (e.g. data)
- but not able to access libraw_data_t fields (e.g. imgdata.image)
....

-- Alex Tutubalin @LibRaw LLC

Explanation...

That's because I did not directly define the libraw_data_t structure (a record in pascal) in the wrapper. I am simply using a general void* (a Pointer type in pascal) instead. Means any pascal program using this wrapper has access only to the pointer itself (to the libraw_data_t structure) but not the structure fields directly.

Reason is simple: All subsequent calls after libraw_init simply accepts the pointer (to structure) and they just do their job.

There was no reason yet to directly define the libraw_data_t record in the wrapper because no direct access to any field was required.

Question

Alex, what do you think, makes it sense to provide a getter method in C API only for this field (libraw_data_t->image)?

I just checked the definition of that field and when I am correct, it is a pointer to a whole 4 element array of ushorts.
I guess that array will be resized internally by whatever call. What is the final size then?

It is not possible to add

It is not possible to add getter(s) for every field in LibRaw structure (while every field may be needed in some specific case).
We provide very limited C-API that solves most common need(s): open RAW file, render it, provide the rendering.

We do not have any plans to extend it much for every need that may occur.

C-API is simple enough, so any not very experienced programmer may extend it using provided C-API code as a sample. Although, there is no guarantee that we'll not reorder internals in future.

-- Alex Tutubalin @LibRaw LLC

(and second answer)

(and second answer)

imgdata.image array is allocated either in raw2image() call or in unpack() call.

array size is no less than imgata.sizes.iwidth * imgdata.sizes.iheight

-- Alex Tutubalin @LibRaw LLC

does not work in delphi XE2 - any suggestions

Hi ,

i tried your simple example in delphi xe2
using the libraw -wrapper
but the return of strings - like error messages
does not work - i just get "??????" for the error code -100009

Source:

err := libraw_open_file(handler, pchar('C:\temp\nikon\test.NEF'));
if (err <> LibRaw_errors.LIBRAW_SUCCESS) then
begin
WriteLn('Open: ' + IntToStr(integer(err)) + ': ' +
libraw_strerror(err));

as err is being filled correctly ( even though the file exists ? )
the output of libraw_strerror(err) is just "???????"

if i convert the console-app to a vcl-app the return looks more like japanes characters ...

so something goes wrong be reading the strings from the function
does someone have an idea ?

thx

Delphi XE2?

Delphi XE2?

Do not use a 10 years old IDE. Upgrade to latest Delphi or use latest Lazarus IDE.