That was the case, but now I am baffled. If building jasper on linux there are options like
--disable-static and
--enable-shared
On windows however I can only open the .dsw file which generates the solution, and the needed preprocessor definitions for dynamic build are nowhere in the documentation.
Depending of what you do in your code, you may prefer
- do not call raw2image()
- and use imgdata.rawdata.raw_image[] array
This way will not allocate extra (4-component per pixel) image array. It is preferred if you, for example, do own processing in floating point: image[] array is not needed in this case.
For non-bayer images:
- imgdata.rawdata.raw_image array will be NULL after unpack()
- and one of color3_image or color4_image will be not NULL.
I noticed that raw2image() does this and it felt redundant. So I was confused as what is the utility of it, having no historical knowledge about the library. I just started using libraw ( expect more of me around here :) ), so I think there's no point to use old workflows, which will most likely become obsolete soon.
I only wanted to make sure I understand what I am doing. Thank you for your explanation, now it is clear.
As a suggestion: if there would have been a repository for the documentation, I would have done the change myself.
Has anything changed since this page was written?
From my observations unpack doesn't fill image, as the documentation suggests, but it does fill raw_image. Is there an issue with the documentation, or am I doing something wrong?
I want to access unscaled, uneverything, as raw as possible, bayer data. For this, I assume I should only set the use_camera_matrix = 0; use_camera_wb=0; and unpack().
Sorry to bother you again, I managed to resolve the unistd.h issue, by defining JAS_WIN_MSVC_BUILD, and even though preprocessor understands USE_JASPER and looks for all dependencies I still get
jasper.dll ignored; no imports found from jasper.dll
What might be the issue, should I specify jasper in other project than libraw in the solution?
I also have absolutely no clue.
I wrote a Microsoft Visual Basic program to select the pictures that I like and the ones that I don't like, and them send all the 'good' ones to my usb key so I take it out to print.
My friend saw my program and asked if I could include the capability to read .raw files in addition to the .jpgs, so I got here. Absolutely no clue.
I understand that this is a library, and my program should include it in the project and then call it. But that's it. Anyone can help?
(I remember the first time I opened the BASIC shell, and I had no idea... a friend sat by my side to teach me and in ten minutes I was programming like crazy... so yeah, it should be easy when someone shows you... but without it...)
Any chance that this patch would be released as part of 0.17?
We have a number of users who are reporting this problem right now. Would it be possible to send us a patch sooner or point me in the right direction on how to fix it myself?
Visual Studio is able to upgrade projects from older version to new one. Provided vcproj files are compatible with VS up to 2013 (have not tested 2015 version).
Is there any problem with project upgrade with VS2015?
Could you please add a Visual Studio 2015 solution? VS community 2015 is already free now. It will be great to have a VS 2015 solution that can build with no error.
My goal is to implement custom IO (using GIO, Gnome/GLib IO stack) for the RAW file loader of GEGL (Gimp new engine, which is C code). As of today, the only possibility is to use open_buffer() on a piece of memory previously populated by GIO machinery, but this requires the entire file/steam to be buffered... I can share a diff showing how the proposed LibRaw_proxy_datastream is intended to be used in my work in progress RAW loader if you want.
Looks interesting in general, although I cannot imagine C-API user with own IO-callback written (usual C-API usage is embedding into other programming environment such as Python or Matlab or Delphi).
Is there a way to see diff against master branch in gitlab without logging in? Cannot find this button in 30-sec look.....
If your changes do not require patching main Libraw code, the best place to store it is Libraw-contrib repo, not the upstream (we're very careful with upstream, because after upstream import we need to support imported code; it is much better to keep it separately without any warranties)
Is there an optional dependency on turbojpeg?
Thanks.
That was the case, but now I am baffled. If building jasper on linux there are options like
--disable-static and
--enable-shared
On windows however I can only open the .dsw file which generates the solution, and the needed preprocessor definitions for dynamic build are nowhere in the documentation.
Depending of what you do in your code, you may prefer
- do not call raw2image()
- and use imgdata.rawdata.raw_image[] array
This way will not allocate extra (4-component per pixel) image array. It is preferred if you, for example, do own processing in floating point: image[] array is not needed in this case.
For non-bayer images:
- imgdata.rawdata.raw_image array will be NULL after unpack()
- and one of color3_image or color4_image will be not NULL.
I noticed that raw2image() does this and it felt redundant. So I was confused as what is the utility of it, having no historical knowledge about the library. I just started using libraw ( expect more of me around here :) ), so I think there's no point to use old workflows, which will most likely become obsolete soon.
I only wanted to make sure I understand what I am doing. Thank you for your explanation, now it is clear.
As a suggestion: if there would have been a repository for the documentation, I would have done the change myself.
Yes, this part of documentation is outdated. To be fixed ASAP.
If you want to process imgdata.image[] the same way you do it in LibRaw <=0.13, use
raw2image() call after unpack(): http://www.libraw.org/docs/API-CXX-eng.html#raw2image
Has anything changed since this page was written?
From my observations unpack doesn't fill image, as the documentation suggests, but it does fill raw_image. Is there an issue with the documentation, or am I doing something wrong?
I want to access unscaled, uneverything, as raw as possible, bayer data. For this, I assume I should only set the use_camera_matrix = 0; use_camera_wb=0; and unpack().
Please try to decode R3D image. If it works, it may means you've linked jasper statically
Sorry to bother you again, I managed to resolve the unistd.h issue, by defining JAS_WIN_MSVC_BUILD, and even though preprocessor understands USE_JASPER and looks for all dependencies I still get
jasper.dll ignored; no imports found from jasper.dll
What might be the issue, should I specify jasper in other project than libraw in the solution?
Sorry, no ideas on C/C++ library integration with VisualBasic.
I also have absolutely no clue.
I wrote a Microsoft Visual Basic program to select the pictures that I like and the ones that I don't like, and them send all the 'good' ones to my usb key so I take it out to print.
My friend saw my program and asked if I could include the capability to read .raw files in addition to the .jpgs, so I got here. Absolutely no clue.
I understand that this is a library, and my program should include it in the project and then call it. But that's it. Anyone can help?
(I remember the first time I opened the BASIC shell, and I had no idea... a friend sat by my side to teach me and in ten minutes I was programming like crazy... so yeah, it should be easy when someone shows you... but without it...)
Yes, USE_JASPER
But libjusper is needed only for (old) Red JPEG2000-encoded files, no other format uses it.
Thanks.
And as for JasPer I need to specify USE_JASPER? It's weird when I try to do that, because suddenly it wants unistd.h
To use JPEG library you need to add defines USE_JPEG and USE_JPEG8 when you build LibRaw
To use LCMS add USE_LCMS define.
That patch fixed it for the Fuji raw files that I have. Thanks, Alex!
LibRaw::unpack_thumb() unpacks thumbnail in memory. See simple_dcraw sample (code within if(output_thumbs) ) for details.
other.gpsinfo is unparsed GPS block. New feature is other.parsed_gps with values parsed.
open_file() should be enough to read this data.
Patch is simple:
Change these lines in internal/dcraw_common.cpp/parse_fuji()
if ((tag = get4()) > 10000) tag = get4(); width = tag;to these
if ((tag = get4()) > 10000) tag = get4(); if (tag > 10000) tag = get4(); width = tag;(In FW 4.0 extra 4 bytes to binary data has added)
0.17 to be updated only for critical security bugs, sorry.
Thanks!
Any chance that this patch would be released as part of 0.17?
We have a number of users who are reporting this problem right now. Would it be possible to send us a patch sooner or point me in the right direction on how to fix it myself?
Thanks.
X-E2 firmware 4.0 to be supported in next development snapshot.
We plan to release it in April.
There is no EXIF data block in LibRaw data (some EXIF values are parsed into imgdata.other fields).
Starting from LibRaw 0.17 you can install own EXIF/Metadata parser callback which will receive all tags at parse time.
Visual Studio is able to upgrade projects from older version to new one. Provided vcproj files are compatible with VS up to 2013 (have not tested 2015 version).
Is there any problem with project upgrade with VS2015?
Could you please add a Visual Studio 2015 solution? VS community 2015 is already free now. It will be great to have a VS 2015 solution that can build with no error.
Thanks for the diff link.
It looks like no Libraw patching required, so entire project may exists separated from libraw upstream.
So, please separate your changes from libraw source and we'll put it into https://github.com/LibRaw/LibRaw-contrib repo (contact us when you're ready)
Thanks for your feedback. Think you can access the diff here, even without being logged in:
https://gitlab.com/tchaik/LibRaw/commit/0e83b1278d8794513949ffed3f7de4a7...
My goal is to implement custom IO (using GIO, Gnome/GLib IO stack) for the RAW file loader of GEGL (Gimp new engine, which is C code). As of today, the only possibility is to use open_buffer() on a piece of memory previously populated by GIO machinery, but this requires the entire file/steam to be buffered... I can share a diff showing how the proposed LibRaw_proxy_datastream is intended to be used in my work in progress RAW loader if you want.
Looks interesting in general, although I cannot imagine C-API user with own IO-callback written (usual C-API usage is embedding into other programming environment such as Python or Matlab or Delphi).
Is there a way to see diff against master branch in gitlab without logging in? Cannot find this button in 30-sec look.....
If your changes do not require patching main Libraw code, the best place to store it is Libraw-contrib repo, not the upstream (we're very careful with upstream, because after upstream import we need to support imported code; it is much better to keep it separately without any warranties)
Pages