-2 is: LIBRAW_FILE_UNSUPPORTED
If your 'raw' file is just a sensor dump without metadata consider using open_bayer() call
Microsoft RAW extension is produced by Microsoft, we're not involved in this process in any way (Microsoft uses the public version of LibRaw).
So, we're completely not responsible for MS RAW Extension.
You may try to use our FastRawViewer instead.
I have the exact same issue with A7VI RAWs and the Microsoft RAW extension.
I figured out it's related to the new Sony lossless compressed RAW format.
A7IV compress or uncompressed RAW are displayed fine, but A7IV lossless compress RAWs are not displayed at all.
The LibRAW blog post from 22. Oct. 2021 says the new Sony losslesss compressed RAW format is now supported.
My guess would be Microsoft RAW extension includes a version that is too old.
So you're talking about Microsoft RAW Extension, right?
Using Windows 11 for importing and cataloguing, I cant view any Sony a7iv raw files. I can open them in photoshop, but I dont like shooting raw & jpeg
What software (that uses LibRaw for RAW support) do you use?
Just wondering if an approximate date is known for next update to include Sony a7iv ILCE-7M4. Thanks
There is separate project on github: https://github.com/LibRaw/LibRaw-cmake
Note: we (LibRaw team) is not responsible for it and do not provide any support for it.
Could you please provide some sample file that illustrates the issue?
Right now we're unable to reproduce it, Kodak DC40/50 files (that uses radc decoder) loads correctly in RawDigger (that uses LibRaw): https://www.dropbox.com/s/qw6o57ikv3mls1n/Screenshot%202022-03-06%2017.4...
Sony ILCE-1 is fully supported in 202110 snapshot:
Supported camera list: https://www.libraw.org/supported-cameras-libraw-202110
Announce page: https://www.libraw.org/news/libraw-202110-snapshot
So its been almost a year and the public snapshot seems not to be out there. When can we expect full Sony A1 Raw file support for uncompressed raw, lossless compressed raw and compressed raw? Thank you.
DNG file metatata:
| | 1) ImageWidth = 3040
| | 2) ImageHeight = 2014
| | 21) DefaultCropOrigin = 15 7 (15/1 7/1)
| | 22) DefaultCropSize = 3008 2000 (3008/1 2000/1)
| | 27) ActiveArea = 0 0 2014 3040
By default, LibRaw extracts ActiveArea image (3040x2014)
Suppose we are discussing the latest public version (https://github.com/LibRaw/LibRaw, master branch):
DefaultCrop tags are parsed into imgdata.sizes.raw_inset_crops
This crop can be applied via: LibRaw::adjust_to_raw_inset_crop(1)
DefaultCrop top/left in this specific file is odd and will be rounded to nearest even margin, so image will be cropped to 3007x1999 starting at 16,8
There is no way to avoid this in current LibRaw (this change was implemented in LibRaw 0.20)
You may switch to LibRaw pre-0.20 (0.19 or so) with LIBRAW_PROCESSING_USE_DNG_DEFAULT_CROP flag set to params.raw_processing_options
Could you please provide some sample file?
Just wanted you to know that this topic is solved as far as I am concerned. Cygwin building did not work though whatever I tried.
I tried Cygwin because my MingW solution broke correct character encoding with your change of file loading on the windows platform in
LibRaw 0.20.1 changes
Windows support/Windows unicode (wchar_t*) filenames support
I have everything working now with full unicode support using the Microsoft Visual Studio compiler.
Thank you very much for your great work on Libraw ;-)
Greetings, everyone. I have fond memories of this project and the learning involved. But I also have emails coming in requesting permission to view my tables with their expired links. For every person that requests access, Google tells me
"firstname.lastname@example.org is requesting access to a file via an old link, which is no longer valid due to a security update. Share the file with this person directly, or copy and send the new link in sharing settings."
The email from my original account was shut down years ago, but I hosted the files on a permanent account. So here are updated links for each of the resources. Here's to another four years of, hopefully, helping people out.
Also @ajohnson was very, very correct about the DHT artifacts in dark regions. Spent a whole what, day?, half a day?, in 2019, cross-examining the algorithms and the rest of the project and unfortunately it was all DHT!
Fence / Roof comparison:
Track line comparison:
Black / white checker comparison (animated GIF!):
Summary table with performance times (on a decently large 16bit image):
Okay, yes, thanks... for now, I will not try more on Cygwin... building is completely broken it seems in that environment with the GNU compiler. (With the MingGW compiler on Cywgwin and the mingw makefile it does work but does not solve my character encoding issues.)
Using MingW was what I did before, but was wondering if I could get things to work using Cygwin.
With MingW on Windows I am having serious character encoding issues since the new Libraw versions related to :
I was able now to turn on unicode in MingW using: https://sourceforge.net/p/mingw-w64/wiki2/Unicode%20apps/
Needed to alter libraw.h and now I can use wchar_t but still not working with asian characters...
So still trying. Do you have any suggestions how to make it work with MingW and wchar_t file path?
Thank you, I was able to fix the swab issue, but much more compile errors after that... so it seams it is rather nasty to compile with Cygwin. I tried different compilers and versions but have not been very succesfull...
See also the patches Cygwin itself used to carry for LibRaw 0.18, (they're probably out of date since codebase was significantly changed since), but swab is also mentioned: https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/libraw.git...
I think this comes from here: https://github.com/LibRaw/LibRaw/blob/b31fa58eea272c4ba67ccdbd527f329a5a...
_WIN32 is defined even on Cygwin, but I guess one shouldn't set LIBRAW_WIN32_CALLS on Cygwin; as a consequence, unistd.h is not included from internal/defines.h: https://github.com/LibRaw/LibRaw/blob/master/internal/defines.h#L50-L65
Any reason you're building for Cygwin, and not native MinGW instead?
According to quick googling, swab function is present in cygwin C runtime.
Sorry, do not have cygwin installed, so no additional help (e.g. what include file should be added)
More details, I am using the GNU compiler Collection c++ gcc-g++ version 11.2.0-1.
Whatever i try, the swab function causes the problem: not declared in this scope.
Please direct Affinity team to our 'extended support options' page: https://www.libraw.org/extended-support
They currently use the public version, which is updated according to the announced schedule (update policy section on our homepage)
I use Capture One 21 (I am aware that 22 should support the Sony A7IV).
And I use Affinity Photo 22.214.171.1248 (Photoshop replacement). Affinity support says their software depends on LibRAW for camera support... Yet, FastRawViewer 2.0 already seems to support the camera already.
And I use darktable 3.8.0 (both Windows and Linux).