Joseph Heled writes:

How (or can you) combine errors/noise in HSV into one error/noise figure which reflects the total "human visual" error perception.

HSV is the wrong colorspace to use for this purpose. The LA*B* colorspace was designed to do what you are trying to accomplish: supposedly, equal distances in LA*B* coordinate space correspond to equal distances in human perceptual space -- although I understand that there is debate about whether this is really true.

(Of course, you have to be careful about what you are trying to do. If you shift an entire image one pixel to the right, it will probably look identical to a human although it may be quite different on a pixel-for-pixel basis. In general, integrating pixel-by-pixel color differences will not give you a very accurate picture of how much difference people perceive between two images.)

The "decompose" plug-in in Gimp will decompose an image into LAB coordinates -- however, I looked at the source code recently in connection with a bug report (bug #147603), and it seems that the LA*B* algorithm is not correctly implemented by the plug-in, so you should be cautious in using it for anything important.

Best, -- Bill

______________ ______________ ______________ ______________ Sent via the KillerWebMail system at primate.ucdavis.edu

Joseph Heled writes:

I might be wrong, but this will not solve it either. I assume the AB (color information) might be in the "same" units, but I don't think Luminosity is. (and I can make the argument that Hue and Saturation are in the "same" units as well, the problem being how to fit Value in)

Well, I don't claim to be an expert on any of this stuff, but please take a look at

http://www.dcs.ed.ac.uk/home/mxr/gfx/faqs/colorconv.faq

Best, -- Bill

______________ ______________ ______________ ______________ Sent via the KillerWebMail system at primate.ucdavis.edu

Hi,

Joseph Heled writes:

The gimp Open Image dialog contains preview thumbnail. To generate them, gimp calls the plugin to generate them. Now, for raw digital camera files (.nef, .crw ...) this is a very expensive operation - and obviously one would love to use the prepared/pre-stored thumbnail which exists in the file.

From what I could see, there is no way I (the plugin author) can detect if the call is for a thumbnail or not.

Can someone tell me if I am right or wrong?

If wrong - how do I do it? If right, is there a chance this can be changed?

You are right. You could suggest an API and we could consider to add it for GIMP 2.4.

Sven

Hi,

Joseph Heled writes:

The most natural place is to add an optional argument to the run() gimp arguments. However I am not sure if this is possible.

The plug-in interface must remain API and ABI compatible to GIMP 2.0 so changing any of the existing functions is not an option.

The plugin is a "file loader", registered under "Load"

gimp_install_procedure ("file_rawphoto_load", "...",
PLUG_IN_VERSION,
"/rawphoto",

I guess "Load" implies some magic, since it is not visible in the regular menus. And perhaps 3 arguments is hardwired for such plugins? Can someone enlighten me?

The menu is a concept that isn't used in 2.2 any longer. Please have a look at how file plug-ins register in GIMP 2.2. The new API is backward compatible with the old one of course. But it doesn't really make sense to look at the old APIs if we want to discuss further enhancements.

(P.S it would certainly make sense to run this plugin non interactively from a script, and in that case supply even additional arguments ...)

There's nothing that keeps you from doing that. If you are looking for an example, check out the SVG loader plug-in.

Sven

Hi,

Joseph Heled writes:

This affect only load plugins with 4 declared arguments (by the plugin), the forth named "thumbnail".

static GimpParamDef load_args[] = {
{ GIMP_PDB_INT32, "run_mode", "Interactive, non-interactive" }, { GIMP_PDB_STRING, "filename", "The name of the file to load" }, { GIMP_PDB_STRING, "raw_filename", "URI of the file to load" }, { GIMP_PDB_INT32, "thumbnail", "use embedded thumbnail" },

That would break all load plug-ins that already have >= 4 parameters which is certainly not an option. Also, your proposal doesn't pass a preferred thumbnail size to the load plug-in. There are file formats that include thumbnails for several sizes or can generate thumbnails of any size on the fly.

Let me explain it again: What we need here is a way for load plug-ins to register an additional procedure that the core can use to load the thumbnail. The core can then check if such a procedure exists and fall back to the default load procedure otherwise.

Sven

Hi,

a while ago Joseph Heled wrote:

The gimp Open Image dialog contains preview thumbnail. To generate them, gimp calls the plugin to generate them. Now, for raw digital camera files (.nef, .crw ...) this is a very expensive operation - and obviously one would love to use the prepared/pre-stored thumbnail which exists in the file.

From what I could see, there is no way I (the plugin author) can detect if the call is for a thumbnail or not.

Note that I have just added the missing API for plug-ins and also implemented the core functionality. What's missing now is some more plug-ins using this feature. See also

http://bugzilla.gnome.org/show_bug.cgi?id=158190 http://bugzilla.gnome.org/show_bug.cgi?id=158191 http://bugzilla.gnome.org/show_bug.cgi?id=158192 http://bugzilla.gnome.org/show_bug.cgi?id=158193

Sven

Joseph Heled wrote:

Option b) Go through the file system - write a temporary file and load it via a PDB call.
(b) is the probably the simplest, but I am not happy about going to the file system and all the issues it brings.

I wouldn't be too shy about it. The jpeg plugin itself (last I saw) does a similar thing when in 'preview' mode. Whatever works!

--Adam

Hi,

Joseph Heled writes:

In most raw files the thumbnail exists as an embedded jpeg. I know how to read it to memory, but need advice on how to load it into gimp (i.e. create a valid image ID for it).

Option a) Perhaps such functionality already exists - but I did not find it?

Option b) Go through the file system - write a temporary file and load it via a PDB call.

Option c) Use some jpeg library (say libjpeg) to read it.

(b) is the probably the simplest, but I am not happy about going to the file system and all the issues it brings. On the other hand (c) is quite complicated.

(b) wouldn't work at all since you need to register a thumbnail procedure from within your raw loader and you can't use the existing JPEG load procedure since it doesn't have the right signature.

Can someone make a suggestion?

I suggest you use libjpeg. I also strongly suggest that you look at one of the plug-in in 2.2-pre2 that implement this functionality.

Sven

Hi,

Sven Neumann writes:

(b) wouldn't work at all since you need to register a thumbnail procedure from within your raw loader and you can't use the existing JPEG load procedure since it doesn't have the right signature.

Thinking about it more, it would actually be possible. You'd have to call the file_jpeg_load procedure on a temporary file from within your file_dcraw_load_thumb procedure and pass the returned image_id back to gimp. That would work but I still think using libjpeg makes more sense here.

Sven

Hi,

Joseph Heled writes:

After some more digging, I think I will use gdk_pixbuf_loader

Yes, why not. Seems reasonable since you can probably assume that the embedded thumbnail won't be too large.

Sven