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?
Thanks, that clarifies things. I'll give it a try.
here it is: https://github.com/LibRaw/LibRaw/commit/54b8d6c0f4fbea3aab7a706d35370156...
BTW, you may not include gpr_sdk/private/gpr.cpp in your gpr_sdk build, LibRaw do not use this high level interface.
(looks like we need to update GPR readme)
Sorry, we still use Adobe DNG SDK v1.4
We are integrating it now.
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
Pages