Problem solved, Hurray !!!

And it was not so complicated. In case of anyone having the same problem :

- Download the win32 zip of LibRaw (available on this website)
- open the makefile.mingw present in the LibRaw root folder and add the option "-mno-cygwin" to the cflags (this was obvious...)
- rename the Makefile.mingw in Makefile
- compile LibRaw using cygwin and make

You will now have a libraw.a present in the lib folder of LibRaw. This library can be used with codeblocks. You'll probably need to add the ws2_32 lib just after the libraw lib or you'll get undefined references to ntohs4.

Regards

I'll say it again: Look at the UNIX world and see how it's done. LibRaw is not so unique. Plenty of other software libraries have encountered these issues, and yet they distribute as shared libraries right from the start.

Believe it or not, it can work. What's more -- and I hope you take this to heart -- library versioning is not a problem you need to solve. It's been solved elsewhere. Please investigate before you go down that path.

Just to ensure I didn't get anything wrong: dcraw_emu appends to the output filename, rather than changing the extension, ie 'foo.nef' becomes 'foo.nef.tiff'; this is clearly not what the user expects, and there is no way to specify the resulting filename.

The patch I propose addresses the unexpected behaviour, also bringing it inline with DCRAW's behaviour. I see no good reasons for keeping the unexpected behaviour, and I was careful to use bounded copies etc.

I was thinking this patch should go into the libraw 0.13 stream, no? If not, for what reasons?

Thanks, Daniel

This is an old, old debate that goes back to when shared libraries were first developed. Your examples are fine, but consider the common case of wanting to take advantage of the bugs fixed in 0.12.3. Users of 0.12.2 need to rebuild all software that depends on libraw. For many users, this is unacceptable.

One common way to deal with the API/ABI problem is to say that the API won't change for a given release number, say, 0.12. In 0.13, the API might change (or it might not). Software writers can deal with this as they like.

I would encourage you to examine how other open-source projects deal with this problem. Almost all open-source libraries out there with unstable APIs release their software as shared libraries.

Some people would say there is no such thing as a stable API; even mature libraries, like GTK, are still undergoing revision.

Finally, note that packaging libraw into a .so does *not* force everyone to use it as such. Application writers may statically link in the .o's if they want.

But another problem raise:

- imagine someone installed, say, Program1 0.AA.BB with LibRaw 0.11 (shared)
- then he/she wants to try, say, Program2. Progam 2 requires LibRaw 0.13-Beta (shared) because it uses exposure correction feature.

So, user SHOULD rebuild/reinstall Program1 with LibRaw 0.13. But he wanted only to play 5 minutes with Program2, nothing more.....

The shared library are very good idea if
- API/ABI is very stable (but frozen API stops development of new features)
- API is made via non-virtual function calls instead of direct access to parameters structure. This way produces zillions of getters/setters with no idea behind. Also, it is harder to make C++ derived classes, because virtual methods table is fixed too, so no way to add/change function calls.
- there are good .SO/DLL version management, so each program uses own version of LibRaw.so/dll. But this broke the idea of quick 'security/bug fixes'.

You may be *stable* (in terms of API/ABI) but it will slow progress because programmer will need to do tricks (to stabilize APIs and so) instead of doing things.

I hope, after verisions 0.14 or 0.17 LibRaw will be stabilized: we need plugin registration interface, so all extensions will run with stable internals. But not now.

Thanks for the "dirty trick" info.
I will add the P1.colors=1 to my code and try again.

About your first suggestion, you mention three steps:
1) Call LibRaw::open_file()
2) Position to libraw_internal_data.unpacker_data.data_offset
3) Read libraw_internal_data.unpacker_data.data_size bytes

So i try to code you suggestion:

int main(int i, char *img[])
{
  i=1;
  int tempimg, row, col;
 
// step one: Open file
  LibRaw RawProcessor;
  tempimg = RawProcessor.open_file(img[i]);
#define RAW RawProcessor.libraw_internal_data.unpacker_data
 
// step two: positioning libraw_internal_data.unpacker_data.data_offset
  tmpimg = RawProcessor.unpack();
 
/* how to position it in data.offset?... */
 
// step three: Read libraw_internal_data.unpacker_data.data_size
  for(row=0;row<RAW.data_size.iheight;row++)
    for(col=0;col<RAW.data_size.iwidth;col++)
      RAW[row*RAW.data_size.iwidth+col][0] = RAW[row*RAW.data_size.iwidth+col][RawProcessor.COLOR(row,col)];
 
// mode coding, not finished yet...
 
  RawProcessor.recycle();
  return 0;
}

Am i in the right direction or i'm completely lost?...

Really appreciate any comments you can give me.

To turn on pretty printing of code use
<code>
.... your code here
</code>

Also, to pass through antispam filter and captcha, it is better to register on this site once...

Thanks for your answer.

Obviously my cleaning wasn't good, i ran the unprocessed_raw with a raw image file of 11.2MB and the result was a .tiff file with 18.4MB, so i have check my code. Here is the small routine (without validations) that i did:
---

int main(int i, char *rawimg[])
  {
// Initialization
  LibRaw RawProcessor;
  RawProcessor.imgdata.params.document_mode = 2;
  RawProcessor.imgdata.params.output_bps = 16;
  RawProcessor.imgdata.params.output_tiff = 1;
  RawProcessor.imgdata.params.user_flip = 0;
  RawProcessor.imgdata.params.no_auto_bright = 1;
  RawProcessor.imgdata.params.filtering_mode = (LibRaw_filtering)(LIBRAW_FILTERING_DEFAULT);
 
// Opening file and unpack
  int tmpimg;
  i = 1;
  tmpimg = RawProcessor.open_file(rawimg[i]);
  tmpimg = RawProcessor.unpack();
 
// extracting raw image data
  int row, col;
  char rawfn[1024];
  for(row=0;row<RawProcessor.imgdata.sizes.iheight;row++)
    for(col=0;col<RawProcessor.imgdata.sizes.iwidth;col++)
      RawProcessor.imgdata.image[row*RawProcessor.imgdata.sizes.iwidth+col][0]= 
      RawProcessor.imgdata.image[row*RawProcessor.imgdata.sizes.iwidth+col]
      [RawProcessor.COLOR(row,col)];
 
// formating and saving image data
  snprintf(rawfn,sizeof(rawfn),"%s.tiff",rawimg[i]);
  tmpimg = RawProcessor.dcraw_ppm_tiff_writer(rawfn);
 
// cleaning image processor
  RawProcessor.recycle();
 
  return 0;
}

---

If the unprocessed_raw extract only the raw data, without process anything, why the resultant file is bigger that the original?.

According with your suggestion, how can i do the step two (position to libraw_internal_data.unpacker_data.data_offset), and the step three (Read libraw_internal_data.unpacker_data.data_size bytes)?

For the step three, i assume can be done using a "for" structure, but if you can show a basic example code for your suggestion it will be really helpful for me, because i'm not an expert.

Thank you for your time and help.

I took the unprocessed_raw.cpp, clean it a little bit the code and processed a 11MB image raw file, but the resultant have 55MB, so i assume that there is a post-processing when saving the file in .tiff format.

I basically want to extract the raw image data, without metadata, read it, make a little processing and then save it in a new file.

In order to do that, your suggestion looks what i need to do, but can you please give a reference code about how to implement it?. I'm not asking for an elaborate coding, only a few lines in order to follow the idea.

I'm not c++ expert, so if the question is basic or simple, i'm sorry.

This is not bug, this is feature. So, no need to fix it

The github/master version is already fixed in another way:
configure checks will set $LIBS
and Makefile.am uses $(LIBS) instead of $(LCMS_LIBS)

This is commit URL: https://github.com/LibRaw/LibRaw/commit/73229a04fb2a44159df3baa8f812b473...