GNOME Bugzilla – Bug 755078
bounding box of gegl:raw-load is non empty only for the first loaded raw image
Last modified: 2016-02-18 20:49:03 UTC
The 'first_pass' global and extern variable cleared here: https://git.gnome.org/browse/gegl/tree/operations/external/raw-load.c#n76 prevents calls to 'prepare' for successive instances of the operation to allocate their copy of the Private struct. get_bounding_box https://git.gnome.org/browse/gegl/tree/operations/external/raw-load.c#n107 then returns an empty 'result' as the op bounding box. An optimization for the first use of this operation is to implement the 'get_cached_region' as it is done for example in the jpeg loader op or dcraw-load op. This would avoid to repeatedly copy the whole image to the output buffer. Another little problem is using the RGB u16 format because it is limited and LibRaw offers other output color-spaces from which it is possible to convert to RGB float.
There is another problem affecting also the first image loaded, it happens if you load a raw file with a rotated flag set. Apparently the code asks LibRaw to rotate the data, but the bounding box is computed using width and height of not rotated data.
And if the user asks for 8 bit image probably it is better to use gamma corrected data https://git.gnome.org/browse/gegl/tree/operations/external/raw-load.c#n173
Maybe it would be better to remove the ability to load into 8bpc buffers; reducing complexity and improving general quality/fidelity.
(In reply to Øyvind Kolås from comment #3) > Maybe it would be better to remove the ability to load into 8bpc buffers; > reducing complexity and improving general quality/fidelity. I thought 8bpc could be used by simple image viewer applications
(In reply to Massimo from comment #4) > (In reply to Øyvind Kolås from comment #3) > > Maybe it would be better to remove the ability to load into 8bpc buffers; > > reducing complexity and improving general quality/fidelity. > > I thought 8bpc could be used by simple image viewer applications The image viewer in https://git.gnome.org/browse/gegl/log/?h=pippin/ui is a simple image viewer application; that can do some simple processing with practically any processing inserted into the chain the data will become single precision float anyways. Even if it is just something that generates thumbnails that data will explode to single precision float. I consider the existence of the 8bpc vs 16bpc toggle a bad copy-paste of properties from the old openraw loading op.
commit 5510aab6fbf13362cecd3fa36c635c4e334b546d Author: Øyvind Kolås <pippin@gimp.org> Date: Mon Feb 15 22:45:21 2016 +0100 raw-load: remoe bps property, we always want 16bpc buffers
commit 490ee6e55252a8d4bf61d3b869b53ca95f3613c5 Author: Øyvind Kolås <pippin@gimp.org> Date: Thu Feb 18 21:46:38 2016 +0100 raw-load: reinitialize library upon path change Fixing bug #755078