What I mean, is when I run this:
dcraw -v -T -4 -o 0 -D -t 0 -k 0 -H 1 image.CR2
I do not have any black frames, and this is the behavior I'm trying to reproduce. I've had this with the use of width and height (but RAF files was buggy).
Correct me if I'm not right, but it was not working because in RAF file you have left and right frame. But in others, like CR2 you have left and top (If I well remember).
So how we remove frames if they aren't in the same place ?
OK.
Fuji are kind of tricky. Thank you for all your advices.
But by using raw_width and raw_height I have black frames I do not want. It was the reason I used width and height.
But apparently this is a problem for Fuji !!
EDIT: and I also have
==21644== Invalid read of size 2 in the line buf[i++] = raw->rawdata.raw_image[offset + col + (raw_width * row)] ;
EDIT2: Sorry, this is only because offset is not necessary anymore with raw_width and raw_height.
Thank you for the tip about only using raw_width and raw_height.
But by doing like this I have: http://hpics.li/d461ad2
width and height are not good at all ...
All other images seem to work correctly.
Thanks for the quick reply. dcraw_emu converts the image properly. Now I can see where the problem is. The image has been rotated by camera but I am processing it as if it's in landscape position.
Canon Makernotes is, sure, array of binary data pointed by 0x927c EXIF tag.
The problem with Canon is camera specific makernotes, so you'll need to process every variant
(Canon CameraInfo1D Tags, Canon CameraInfo1DmkII Tags, etc, etc,etc)
For different vendors you'll need to add more vendors processing.
Exiftool already do this camera/vendor specific processing.
I got some more information on this through the Exiftool documentation, as Exiv2 does not yet support this parameter (under discussion with the Exiv2's author). ideally I would like to avoid using Perl-based Exiftool.
Going first here: http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/index.html (with explanation on how to decypher what follows)
and clicking on Canon, you end up with the tag list, with adresses written in hex.
Then at 0x0004, clicking on “Canon ShotInfo Tags” brings you down to a so called 2-byte-offseted “index2” at number 12 (and I have no idea what that means), where you’ll find the little bugger “CameraTemperature”.
With this information, I have to find out how to read that out either from the raw file, getting my hands dirty, or through the Exiv2 API, if it allows it knowing the exact locations in the makernote...
Feel free to advise, although i understand this not Libraw's concern.
You use Qt library. It is very easy to use QProcess wrapper to run exiftool (make sure you've closed raw file handle in Windows to allow access, LibRaw::recycle_datastream() do that, keeping all parsed data in memory).
We supply exiftool binary with our RawDigger software, exiftool's license permits this.
Ok, I understand that it would cumbersome to maintain such feature. I will give it a try to either exiv2 or exiftool. The problem with using a command line output is that it would make me digress a bit from my software intended design. So far I manage to have things work in Windows, Mac and Linux without any hassle but dealing with exiftool command line will break things out of my software, and maybe forcing the user to install exiftool too?...
exiv2 seems to allow to keep things more internal.
I think I should go ahead because I did understand.
Thanks for your help with Fuji
What I mean, is when I run this:
dcraw -v -T -4 -o 0 -D -t 0 -k 0 -H 1 image.CR2
I do not have any black frames, and this is the behavior I'm trying to reproduce. I've had this with the use of width and height (but RAF files was buggy).
By the way, many thanks for helping me!!
Sorry, cannot understand your question.
Initially your question was about 'dcraw -D' so document mode, so full access to raw with black frame.
Correct me if I'm not right, but it was not working because in RAF file you have left and right frame. But in others, like CR2 you have left and top (If I well remember).
So how we remove frames if they aren't in the same place ?
OK.
Fuji are kind of tricky. Thank you for all your advices.
But by using raw_width and raw_height I have black frames I do not want. It was the reason I used width and height.
But apparently this is a problem for Fuji !!
EDIT: and I also have
==21644== Invalid read of size 2 in the line
buf[i++] = raw->rawdata.raw_image[offset + col + (raw_width * row)] ;EDIT2: Sorry, this is only because offset is not necessary anymore with raw_width and raw_height.
Yes, Fuji S2/S3/S5 (and, may be, other Super-CCD cameras) use different aspect ratio, not 1:1
The rotate trick is to scale 1:1.41 images to square pixels using only integer math.
Thank you for the tip about only using raw_width and raw_height.
But by doing like this I have:
http://hpics.li/d461ad2
width and height are not good at all ...
All other images seem to work correctly.
Fuji is not different, raw access is the same.
The only difference is not 1:1 aspect ratio on some (very) old Fuji cameras.
BTW, please use raw_width/raw_height in your code, not width/heigh (and not iwidth/iheight)
imgdata.sizes.flip contains rotation information got from file
imgdata.params.user_flip - rotation, forced by user
Both are in same format: 0=none, 3=180, 5=90CCW, 6=90CW
libraw_processed_image_t (result from ..mem_image() calls) contains height/with of (rotated) image.
I wonder is there any way that I can get the rotation information using the API?
Thanks for the quick reply. dcraw_emu converts the image properly. Now I can see where the problem is. The image has been rotated by camera but I am processing it as if it's in landscape position.
Same result: tested with up-to-date libraw's dcraw_emu without problem.
Do you use your own code with LibRaw or use libraw samples to test?
I converted the file with
dcraw_emu -T -6 -w IMG_0007.CR2
and it looks normal.Could you please try the same?
Here is the link to the raw file.
https://www.dropbox.com/s/8usgnpkvc39s8qq/IMG_0007.CR2?dl=0
thanks,
Use Dropbox, or google drive or any other file sharing service.
https://github.com/LibRaw/LibRaw/issues/76
Canon Makernotes is, sure, array of binary data pointed by 0x927c EXIF tag.
The problem with Canon is camera specific makernotes, so you'll need to process every variant
(Canon CameraInfo1D Tags, Canon CameraInfo1DmkII Tags, etc, etc,etc)
For different vendors you'll need to add more vendors processing.
Exiftool already do this camera/vendor specific processing.
I got some more information on this through the Exiftool documentation, as Exiv2 does not yet support this parameter (under discussion with the Exiv2's author). ideally I would like to avoid using Perl-based Exiftool.
Going first here: http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/index.html (with explanation on how to decypher what follows)
and clicking on Canon, you end up with the tag list, with adresses written in hex.
Then at 0x0004, clicking on “Canon ShotInfo Tags” brings you down to a so called 2-byte-offseted “index2” at number 12 (and I have no idea what that means), where you’ll find the little bugger “CameraTemperature”.
With this information, I have to find out how to read that out either from the raw file, getting my hands dirty, or through the Exiv2 API, if it allows it knowing the exact locations in the makernote...
Feel free to advise, although i understand this not Libraw's concern.
Hello,
we are using libraw in our software: http://free-astro.org/index.php/Siril as RAW images are often used in astrophotography.
logo: https://free-astro.org/svn/siril/trunk/pixmaps/siril_logo.svg
Thanks for this library.
Cheers,
You may implement own datastream (e.g. based on LibRaw_bigfile_datastream which uses FILE* I/O) and own open_wfile() method.
I found std::filebuf usage later. So, it looks like there is no easy way to handle Unicode paths in mingw64 builds :(.
Windows binaries are available from exiftool site: http://www.sno.phy.queensu.ca/~phil/exiftool/
Mac and linux 'binaries' are just perl scripts (with lot of perl libraries). In RawDigger/Mac we store this script/libs in app resource folder.
Great! If I can provide the binary, it's fine then. I never used QProcess, but I'll find out. Thanks Alex!
You use Qt library. It is very easy to use QProcess wrapper to run exiftool (make sure you've closed raw file handle in Windows to allow access, LibRaw::recycle_datastream() do that, keeping all parsed data in memory).
We supply exiftool binary with our RawDigger software, exiftool's license permits this.
Ok, I understand that it would cumbersome to maintain such feature. I will give it a try to either exiv2 or exiftool. The problem with using a command line output is that it would make me digress a bit from my software intended design. So far I manage to have things work in Windows, Mac and Linux without any hassle but dealing with exiftool command line will break things out of my software, and maybe forcing the user to install exiftool too?...
exiv2 seems to allow to keep things more internal.
Pages