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...

For float data output we need to change entire processing pipeline to floating point.

There are no such plans for LibRaw team: we're open to contributions, but will not spend much own effort on postprocessing phase.

Thanks for your answer.
i used the -fopenmp and compiled flawlessly.

I really appreciate your help.