Hi. Thanks for putting this example. I tried the same with CR2 images. But the converted image (in OpenCV) is brighter than the original CR2 image. What should I do?
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 ?
What I see in this file (downloaded yesterday from the link posted above):
- starting from offset 1788B23 (hex) it contains zero bytes only
- first 40% of the file looks OK.
Sorry, I cannot answer your question, whether the file is damaged or not.
I downloaded the image accidentally for some tests with Exiftool and I also tried to open it with libraw.
I'm also unable to open this file using both LibRaw (and LibRaw based software) and Adobe Camera Raw.
Аre you absolutely sure that this file is not damaged?
According to Exiftool for your 1st file:
GPS Latitude : 48 deg 7' 48.30" N
GPS Longitude : 11 deg 34' 2.32" E
According to LibRaw (variables from MSVC Debugger):
+ latitude 0x0000016e11b1f0cc {48.0000000, 7.00000000, 48.3039856} float[3]
+ longitude 0x0000016e11b1f0d8 {11.0000000, 34.0000000, 2.32399201} float[3]
I do not see any difference.
It is likely that your '(0, 48, 7)' is lattitude array dump (1st 3-item array in parsed_gps structure), it looks like offsets used (either in parsing or in interpreting the data) are wrong.
Please make sure you use libraw*.h and libraw*so (.a) from the same version (so assume same structures offset).
Another possible problem is structure padding (different assumption in calling code and in compiled LibRaw)
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!
Hi. Thanks for putting this example. I tried the same with CR2 images. But the converted image (in OpenCV) is brighter than the original CR2 image. What should I do?
Delphi XE2?
Do not use a 10 years old IDE. Upgrade to latest Delphi or use latest Lazarus IDE.
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
Thank you for your feedback. I'm going to inquire about libtiff.
Regards
DNG format is really TIFF 6.0 + (lot of) extra tags for metadata.
Compressed DNG files are usually stored in tiles (each tile compressed separately)
If you want to read 'original' (i.e. compressed) data, libtiff is much better fit for this task.
Ah, got it. Thanks.
And also: https://github.com/LibRaw/LibRaw/blob/master/doc/API-datastruct.html#L48...
(sorry do not see the way to highlight it in html-formatted mode)
Yes, this is expected:
https://github.com/LibRaw/LibRaw/blob/master/Changelog.txt#L48-L52
rawProcessor->imgdata.params.use_rawspeed = 1
Produces compile error. params.use_rawspeed is not found.
RawSpeed support is here and not changed.
It seems that RawSpeed support is removed from this release?
What I see in this file (downloaded yesterday from the link posted above):
- starting from offset 1788B23 (hex) it contains zero bytes only
- first 40% of the file looks OK.
Probably, previews are in first 40%
Hello
The Track1:JpgFromRaw, Quicktime:PreviewImage and Canon:ThumnailImage fields embed a correct JPEG.
Jean
Hello,
thanks for your investigations.
Sorry, I cannot answer your question, whether the file is damaged or not.
I downloaded the image accidentally for some tests with Exiftool and I also tried to open it with libraw.
Thanks again and
Best regards
herb
I'm also unable to open this file using both LibRaw (and LibRaw based software) and Adobe Camera Raw.
Аre you absolutely sure that this file is not damaged?
Thank you
Github version just updated: https://www.libraw.org/news/libraw-202101-snapshot
According to Exiftool for your 1st file:
GPS Latitude : 48 deg 7' 48.30" N
GPS Longitude : 11 deg 34' 2.32" E
According to LibRaw (variables from MSVC Debugger):
+ latitude 0x0000016e11b1f0cc {48.0000000, 7.00000000, 48.3039856} float[3]
+ longitude 0x0000016e11b1f0d8 {11.0000000, 34.0000000, 2.32399201} float[3]
I do not see any difference.
It is likely that your '(0, 48, 7)' is lattitude array dump (1st 3-item array in parsed_gps structure), it looks like offsets used (either in parsing or in interpreting the data) are wrong.
Please make sure you use libraw*.h and libraw*so (.a) from the same version (so assume same structures offset).
Another possible problem is structure padding (different assumption in calling code and in compiled LibRaw)
Parsing of LibRaw GPS data doesn't seem to match EXIF
RAW_PENTAX_K20D.PEF
http://www.rawsamples.ch/raws/pentax/k20d/RAW_PENTAX_K20D.PEF
LibRaw parsed_gps: ((0, 48, 7), (48.3039855957031, 11, 34), (2.32399201393127, 18, 14), 50, '3', 'S', #20, 'D', #0)
EXIF:
GPS Version ID : 2.2.0.0
GPS Latitude Ref : North
GPS Latitude : 48.130084°
GPS Longitude Ref : East
GPS Longitude : 11.567312°
GPS Altitude Ref : Above Sea Level
GPS Altitude : 593.3 m
GPS Time Stamp : 18:14:50
GPS Satellites : 0
GPS Map Datum : WGS-84
GPS Date Stamp : 2008:05:08
RAW_SONY_SLTA65V.ARW
http://www.rawsamples.ch/raws/sony/RAW_SONY_SLTA65V.ARW
LibRaw parsed_gps: ((0, 45, 35), (39.9160003662109, 9, 13), (40.5859985351562, 17, 54), 50, '=', #10, '4', 'C', #0)
EXIF:
GPS Version ID : 2.3.0.0
GPS Latitude Ref : North
GPS Latitude : 45.594421°
GPS Longitude Ref : East
GPS Longitude : 9.227941°
GPS Altitude Ref : Above Sea Level
GPS Altitude : 180.04 m
GPS Time Stamp : 17:54:50
GPS Status : Measurement Active
GPS Measure Mode : 3-Dimensional Measurement
GPS Dilution Of Precision : 1.5647
GPS Speed Ref : km/h
GPS Speed : 0.145
GPS Track Ref : True North
GPS Track : 209.84
GPS Map Datum : WGS-84
GPS Date Stamp : 2012:01:04
GPS Differential : No Correction
Great thanks!
I appreciate all your hard work.
Not yet.
We plan to push new LibRaw snapshot to github this week.
Are the necessary changes in the Git repo if we build from source? I skimmed the commit logs but didn't see anything obvious and we need this too.
Thanks,
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!
Pages