Hi, will ZRAW support be coming soon? Z-Cam's are getting quite popular with the indie cinie scene, so it'd be great to have those files supported by LibRaw.
Libraw team pointed out that the problem could be in the firmware so we had our customer do an upgrade of the camera firmware and the problem is now gone.
Thanks!
The colors look fine. I have posted the image in the google drive link in my earlier post (f828_srgb_0.202.png). The image is different from 0.20.0 but does not appear bad or malformed.
Please confirm if the change to rgb_cam is expected.
Alex,
I debugged my code and actually looked at the rgb_cam values in memory and they are different between 0.20.0 and 0.20.2. You can check the values I have posted in my first post.
The google drive link above has the RAW file. You can confirm this at your end.
Alex,
I understand there is no "right" answer when rendering an RGB image from CFA data. The images in 0.20.0 and 0.20.2 look quite similar (no opinion on which is better, they both look good).
I wanted to confirm that the changed value in 0.20.2 was expected and not accidental because it matched the values from an older behaviour.
I cannot understand your question. You complained 0.20.0/raw-identify displays incorrect data for some color matrices. We fixed that in 0.20.1/0.20.2. What exactly is the problem?
Ok, so reducing quality is with libraw_set_demosaic(handler, LibRaw_interpolation_quality.LINEAR); ?
I tried it and its speeding up the process already a little bit.
Unfortunate I can't access the params-scruct from SharpLibRaw, its not implemented, so I'm not able to play with params.user_qual and/or use half-size.
Sorry, how? With what function?
All I need is the pixels, but for 100.000 photos, which takes ages now since libraw_dcraw_process() needs 5-7sec per photo.
I found the pixels now in data[]. Its an c#-marshaling issue, wish needs a few more steps.
I also realized, that libraw_dcraw_process(handler); takes quiet a lot of time, several seconds, depending on the image-size. Is is really necessary for libraw_dcraw_make_mem_image()? Or is there a faster way to get the image?
LibRaw is not about video, so no specific plans for ZRAW.
Nonetheless if you could share some sample file(s) with us, we'll look at them
Hi, will ZRAW support be coming soon? Z-Cam's are getting quite popular with the indie cinie scene, so it'd be great to have those files supported by LibRaw.
Libraw team pointed out that the problem could be in the firmware so we had our customer do an upgrade of the camera firmware and the problem is now gone.
Thanks!
Thanks for looking into this issue.
No, this is not known issue.
We really need sample file(s) with this issue.
Please send some to info@libraw.org (or use some file sharing service, eg. Dropbox or WeTransfer/Free option and send link to this E-mail)
The colors look fine. I have posted the image in the google drive link in my earlier post (f828_srgb_0.202.png). The image is different from 0.20.0 but does not appear bad or malformed.
Please confirm if the change to rgb_cam is expected.
Dinesh
OK, may be, too lazy to check.
Is something wrong with F828 colors and LibRaw 0.20.2?
Alex,
I debugged my code and actually looked at the rgb_cam values in memory and they are different between 0.20.0 and 0.20.2. You can check the values I have posted in my first post.
The google drive link above has the RAW file. You can confirm this at your end.
Dinesh
The problem was in raw-identify printing code, not in data.
Alex,
I understand there is no "right" answer when rendering an RGB image from CFA data. The images in 0.20.0 and 0.20.2 look quite similar (no opinion on which is better, they both look good).
I wanted to confirm that the changed value in 0.20.2 was expected and not accidental because it matched the values from an older behaviour.
Regards,
Dinesh
I cannot understand your question. You complained 0.20.0/raw-identify displays incorrect data for some color matrices. We fixed that in 0.20.1/0.20.2. What exactly is the problem?
Alex,
I am upgrading to 0.20.2 and I noticed for this file, the rgb_cam value matches that of 0.19.5 instead of 0.20.0.
The raw-identify output on 0.20.2 has the following:
Camera2RGB matrix (mode: 1):
1.6374 -0.2528 -0.0035 -0.3811
0.0672 0.8224 -0.5306 0.6410
-0.0009 -0.3551 1.4153 -0.0593
which matches 0.19.5 (see comments above). Is this intentional?
Regards,
Dinesh
Sorry, know nothing about C# (both generally and specific wrapper you use)
Ok, so reducing quality is with libraw_set_demosaic(handler, LibRaw_interpolation_quality.LINEAR); ?
I tried it and its speeding up the process already a little bit.
Unfortunate I can't access the params-scruct from SharpLibRaw, its not implemented, so I'm not able to play with params.user_qual and/or use half-size.
Just to remember, I'm using c#
If so, you need raw to rgb interpolation that is performed by dcraw_process(). Reducing quality (or using half_mode) will speed-up things.
I need a rgb-pixmap.
And followup: what 'pixels' do you need? Original raw values, or processed RGB pixmap?
dcraw_process() parameters are adjusted via imgdata.params: https://www.libraw.org/docs/API-datastruct.html#libraw_output_params_t
Sorry, how? With what function?
All I need is the pixels, but for 100.000 photos, which takes ages now since libraw_dcraw_process() needs 5-7sec per photo.
One may adjust params.user_qual and/or use half-size interpolation.
Thanks Alex,
I found the pixels now in data[]. Its an c#-marshaling issue, wish needs a few more steps.
I also realized, that libraw_dcraw_process(handler); takes quiet a lot of time, several seconds, depending on the image-size. Is is really necessary for libraw_dcraw_make_mem_image()? Or is there a faster way to get the image?
This happens when pkg-config has not been installed when running autoreconf prior to executing configure script.
Followup: look into samples/mem_image_sample.cpp
Data is not empty,
your pixels are in data[0].....data[data_size-1]
glad to hear that my assistance helped.
Pages