1st option: the samples we have contains vital metadata (image size) in EXIF fields. It would not help if you just prepend arbitrary JPEG at start.
2nd option (backport from patched dcraw): looks OK, but there is a lot of code covering multiple cases. It is not possible to move on without having sample files for all these multiple cases.
We are ready to go this route, but someone should prepare (various) examples
The Raspberry Pi RAWs should be identical to the RAW data dumps in the JPEG file.
Look for "BRCMo" (Hex: 42 52 43 4d 6f) in your files. Thats where my files start.
Unfortunatelly I can only produce RAWs for my real use case. Maybe I could put fake JPEGs in front?
I have also to contact the people from DeepSkyStaker. The program loads EXIF(JPEG) files at start concatenated w/ RAW but only uses the JPEG ...
It looks like I have 2 possible options:
1st: Fake JPEG data in front of the RAW data and and fix the bug in DeepSkyStacker
2nd: Enable LibRaw to read the pure RAWs (here a fork of dcraw which should be able to do this: https://github.com/6by9/dcraw) and ask for a DeepSkyStacker update with the new Libraw.
R-Pi files we have (and support in LibRaw) is EXIF(JPEG) files at start concatenated w/ RAW data dump.
Your dump looks entirely different. Do you have any format docs?
... 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() ...
Supported in 201910 snapshot: https://www.libraw.org/news/libraw-snapshot-201910
I've checked this commit (using Qt Creator/libraw.pro build file).
OK, it looks like that relying that MinGW does not defines WIN32, but defines _WIN32 only is not correct. This assumption is fixed in this commit: https://github.com/LibRaw/LibRaw/commit/0ebd8a4e1846a3d265f823ac9b2f52ed...
(just use git pull to updated from github).
Checked w/ MinGW-W64/7.30, I do not see any problems
I ran in to a syntax error at #endif /* _LIBRAW_CLASS_H */
This may not be the correct endif (the compiler says there is an extra ( or maybe an extra if
I think I have not repaired this correctly as my fix then causes a bunch of errors
in libraw_c_api.cpp
If I knew what I was doing this would be an easy fix
(should be) fixed in this commit: https://github.com/LibRaw/LibRaw/commit/fabd1482276cd3c0aed7b2a3cb9ba07c...
I just sent some example files to info at libraw dot com.
I hope you have access to this mailbox and that the examples are sufficient.
Different RAW files that covers different cases handled in patched dcraw.c you mentioned above.
How do these example files have to look like?
1st option: the samples we have contains vital metadata (image size) in EXIF fields. It would not help if you just prepend arbitrary JPEG at start.
2nd option (backport from patched dcraw): looks OK, but there is a lot of code covering multiple cases. It is not possible to move on without having sample files for all these multiple cases.
We are ready to go this route, but someone should prepare (various) examples
The Raspberry Pi RAWs should be identical to the RAW data dumps in the JPEG file.
Look for "BRCMo" (Hex: 42 52 43 4d 6f) in your files. Thats where my files start.
Unfortunatelly I can only produce RAWs for my real use case. Maybe I could put fake JPEGs in front?
I have also to contact the people from DeepSkyStaker. The program loads EXIF(JPEG) files at start concatenated w/ RAW but only uses the JPEG ...
It looks like I have 2 possible options:
1st: Fake JPEG data in front of the RAW data and and fix the bug in DeepSkyStacker
2nd: Enable LibRaw to read the pure RAWs (here a fork of dcraw which should be able to do this: https://github.com/6by9/dcraw) and ask for a DeepSkyStacker update with the new Libraw.
R-Pi files we have (and support in LibRaw) is EXIF(JPEG) files at start concatenated w/ RAW data dump.
Your dump looks entirely different. Do you have any format docs?
LibRaw is not about video files and/or (already) processed files.
LUMIX says:
HSP is a HDR format compressed with the HLG video technology.
HLG (Hybrid Log Gamma) is a HDR format following (ITU-R BT.2100.
Supported in 201910 snapshot: https://www.libraw.org/news/libraw-snapshot-201910
Thanks.
Does not looks like something well-known.
Are you sure this is really RAW (mostly unprocessed) file?
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
Pages