... Faust 1, Chapter 7, Mephistopheles to a student on the topic of medicine (the student believes), but actually about how to "deal with women" (what Mephistopheles actually says) ...
Oh yes absolutely so, I fully understand that! That's why I only issue a warning and allow the user to continue. It's more a case of did you recognise the camera or not!
> by the time you have completed the unpack() operation, does the LibRaw code know if the camera is/isn't supported
The philosophy is to try to support those cameras that are "not listed" too, even if the support is limited. In a lot of cases a file coming from a non-listed camera can be unpacked, but the support is limited. IsSupported implies yes or no as an answer. Grau, teurer Freund, ist alle Theorie, Und grün des Lebens goldner Baum.
Many thanks - probably better to use "Sony ILCE-7M2 / A7 II" no point in replicating the Sony word!
A thought just occurred to me - by the time you have completed the unpack() operation, does the LibRaw code know if the camera is/isn't supported. If it does know that, it would be simple to add a new function:
bool LibRaw::isSupported()
method that a client application can call after calling unpack() ...
Checking camera support against the list of names isn't going to provide a definitive "not supported" answer, because, for example, not all the camera aliases are known (for example, Leica C-Lux can have CAM-DC25 as a name in EXIF). We add such aliases as we discover them.
Unfortunately, we don't have a better solution at the moment, and it's not easy to come up with a one.
You are absolutely right re Sony, we will take care of this, thank you for your suggestion.
Thank you for the sample files (downloaded, you may remove them to clean up OneDrive space).
1st: we do not see green tint in our software that uses LibRaw for raw decoding and/or rendering (FastRawViewer, RawDigger). We do not know what specific version(s) of LibRaw is used in your apps and how app vendors use it (only for raw decoding, or also for rendering), so it is hard to help w/ this specific case.
2nd: Garbage at right edge of high-res image confirmed. We will adjust the size of sensor technological area to be cropped out in future LibRaw update (coming soon).
Thank you again for detailed problem report and for the RAWs.
Followup: the issue solved in current public snapshot via #if __cplusplus >= 201103L || (defined(_CPPLIB_VER) && _CPPLIB_VER >= 520) and/or LIBRAW_USE_AUTOPTR define
If you are willing to build it yourself, the edits are trivial to make it use std::unique_ptr instead.. Just replace the two std::auto_ptr instances in the libraw_datastream.h with std::unique_ptr (along with the export)
Then go into the CPP file and make sure that
a) every construction of the filebuf that formerly looked like this:
I think it was due to my C++/CLR project. When tested from Visual Studio in release, unpack time was 11s.
When tested outside of Visual Studio, time was 2.6s.
Then I tested to use the libraw.dll instead of embedding the code in my project directly and unpack time was 1.1 sec, same timing than the postprocessing_benchmark project.
I still don't know why the dll is faster than compiling the code in my project, but that's fine :)
The "has been subtracted at the unpacking stage" statement covers "possibility": if black pattern is not covered by black/cblack[], the only way is to subtract it on unpack to prevent LibRaw user from camera-specific details.
From user's point, there is no difference between 'black subtracted by camera' (e.g. old Nikons) and 'black subtracted on unpack()'
no need to shout at me, I was documenting my progress here for others to hopefully help. Maybe I should have kept it to myself.
> blacks are NOT subtracted by unpack().
... may I humbly refer you to your documentation, which clearly states:
Structure libraw_colordata_t: Color Information
...
unsigned black;
Black level. Depending on the camera, it may be zero (this means that black has been subtracted at the unpacking stage or by the camera itself)
...
I do not wish to use the 4-component-distribution version of the data for several reasons (one, not the least, being performance, my current very crude reverse-engineered version is slightly faster than the original and that is without optimization and converting large loops to CUDA). That is why I was asking questions in order to better understand what happens under the hood.
In the end I want to use libraw for reading/unpacking RAW data and do all post-processing after that step myself, to better integrate it into pipelines. Recreating the reading part would be possible since my usecases only cover about 10 different camera models/brands and I have limitless access to all of them, but libraw (dcraw) is doing a great job there, so why reinvent the wheel ...
Thanks for the advice you gave (pointing me back to ninedegrees)! If we were able to communicate better I would volunteer for reworking the documentation, obviously, that would not be wise. Therefor: Thank you for the work you invest in maintaining libraw!
http://www.lemkesoft.org/tmp/P1007511.HSP
Yes, we need sample files (BTW, LUMIX S 24-105/F4 looks like lens name, not camera name)
New snapshot is here: https://www.libraw.org/news/libraw-snapshot-201910
This Fall: not later, than Nov, 30.
the question is if the dates are still valid (the end of October?): the sooner we get the support the better
Also waiting for PANASONIC DC-S1/S1R. Hope it will be supported soon
Thanks, Iliah,
as a hint for others experiencing strange issues with DNG files: If you are using ImageMagick's compile of DCraw - that's the problem. It's broken.
Mact
... Faust 1, Chapter 7, Mephistopheles to a student on the topic of medicine (the student believes), but actually about how to "deal with women" (what Mephistopheles actually says) ...
Oh yes absolutely so, I fully understand that! That's why I only issue a warning and allow the user to continue. It's more a case of did you recognise the camera or not!
I love the (Goethe?) quote too!
> by the time you have completed the unpack() operation, does the LibRaw code know if the camera is/isn't supported
The philosophy is to try to support those cameras that are "not listed" too, even if the support is limited. In a lot of cases a file coming from a non-listed camera can be unpacked, but the support is limited. IsSupported implies yes or no as an answer. Grau, teurer Freund, ist alle Theorie, Und grün des Lebens goldner Baum.
Many thanks - probably better to use "Sony ILCE-7M2 / A7 II" no point in replicating the Sony word!
A thought just occurred to me - by the time you have completed the unpack() operation, does the LibRaw code know if the camera is/isn't supported. If it does know that, it would be simple to add a new function:
bool LibRaw::isSupported()
method that a client application can call after calling unpack() ...
Thanks again
David
Dear Sir:
Checking camera support against the list of names isn't going to provide a definitive "not supported" answer, because, for example, not all the camera aliases are known (for example, Leica C-Lux can have CAM-DC25 as a name in EXIF). We add such aliases as we discover them.
Unfortunately, we don't have a better solution at the moment, and it's not easy to come up with a one.
You are absolutely right re Sony, we will take care of this, thank you for your suggestion.
То be included in next snapshot.
I've answered to your E-mail message about GFX100 on Fri, 6 Sep 2019.
Please check your e-mail.
Hello, are there any news about Fuji GFX100?
(I guess, my letters got to a spam, so I'm duplicating my questions here).
Thank you for the sample files (downloaded, you may remove them to clean up OneDrive space).
1st: we do not see green tint in our software that uses LibRaw for raw decoding and/or rendering (FastRawViewer, RawDigger). We do not know what specific version(s) of LibRaw is used in your apps and how app vendors use it (only for raw decoding, or also for rendering), so it is hard to help w/ this specific case.
2nd: Garbage at right edge of high-res image confirmed. We will adjust the size of sensor technological area to be cropped out in future LibRaw update (coming soon).
Thank you again for detailed problem report and for the RAWs.
Followup: the issue solved in current public snapshot via #if __cplusplus >= 201103L || (defined(_CPPLIB_VER) && _CPPLIB_VER >= 520) and/or LIBRAW_USE_AUTOPTR define
What is minimal compiler/libstdc++/libc++ for that?
Will it compile on MacOS 10.6 using XCode 4.3 (for example)?
If you are willing to build it yourself, the edits are trivial to make it use std::unique_ptr instead.. Just replace the two std::auto_ptr instances in the libraw_datastream.h with std::unique_ptr (along with the export)
Then go into the CPP file and make sure that
a) every construction of the filebuf that formerly looked like this:
std::auto_ptr<std::filebuf> buf(new std::filebuf());Now looks like this:
auto buf = std::make_unique<std::filebuf>();Also, wrap each assignment of what used to be an auto-ptr with std::move. So, for example, this line:
f = saved_f;changes to this:
f = std::move(saved_f);Didn't even start.
it seems this issue 100 had been closed. Do you have any progress on new rawspeed lib?
Looks like you have some runtime checks turned on (not initialized variables, array bounds check, etc).
Also, Visual Studio's heap debug slows down every program w/ large memory allocations (when run inside Visual Studio)
Problem solved.
I think it was due to my C++/CLR project. When tested from Visual Studio in release, unpack time was 11s.
When tested outside of Visual Studio, time was 2.6s.
Then I tested to use the libraw.dll instead of embedding the code in my project directly and unpack time was 1.1 sec, same timing than the postprocessing_benchmark project.
I still don't know why the dll is faster than compiling the code in my project, but that's fine :)
Thank again for confirming that I had a problem!
The "has been subtracted at the unpacking stage" statement covers "possibility": if black pattern is not covered by black/cblack[], the only way is to subtract it on unpack to prevent LibRaw user from camera-specific details.
From user's point, there is no difference between 'black subtracted by camera' (e.g. old Nikons) and 'black subtracted on unpack()'
hi,
no need to shout at me, I was documenting my progress here for others to hopefully help. Maybe I should have kept it to myself.
> blacks are NOT subtracted by unpack().
... may I humbly refer you to your documentation, which clearly states:
I do not wish to use the 4-component-distribution version of the data for several reasons (one, not the least, being performance, my current very crude reverse-engineered version is slightly faster than the original and that is without optimization and converting large loops to CUDA). That is why I was asking questions in order to better understand what happens under the hood.
In the end I want to use libraw for reading/unpacking RAW data and do all post-processing after that step myself, to better integrate it into pipelines. Recreating the reading part would be possible since my usecases only cover about 10 different camera models/brands and I have limitless access to all of them, but libraw (dcraw) is doing a great job there, so why reinvent the wheel ...
Thanks for the advice you gave (pointing me back to ninedegrees)! If we were able to communicate better I would volunteer for reworking the documentation, obviously, that would not be wise. Therefor: Thank you for the work you invest in maintaining libraw!
Mact
Pages