Re: [Gimp-developer] Color Curves

2005-01-13 Thread emgimp

Hi

I'm on the same project as Buck Arue
I know some c++ and avisynth plug-in programming
but sourcecode on the level of gimp is more than 
i can handle


i have finished a first test version of an 
avisynth plug-in that
should apply a color curve saved from gimp to the 
video frames
http://forum.doom9.org/showthread.php?
s=threadid=87791perpage=20pagenumber=2
no source, yet (unreadable mess, and to be 
rewritten soon)


for the R curve i do spline(R,x,y,...)
R is the pixel's original R value,
x,y,... are the values form the R-line in the 
file, except for
those which have one or both values as -1
the result is the new R value of the pixel

same for G, B and possibly A


now for my questions:

-is my R, G and B curve handling about right? 
(tests say: yes)

-what to do with the first line of numbers?
from a quick test in gimp it seems to me it 
should be aplyed
to R, G and B additionally to their seperate 
curves
is this correct? if yes, which of the 2 curves 
should be aplyed
first? and should this global curve also be 
aplied to A?
if no, how should it be aplied?

-i understand that all values must be seen as x,y-
pairs
and if both values in a pair are -1 the pair is 
ignored
but what if only the first value is -1 and the 
other is positive?
i couldn't make any sense of that and for now 
ignore them, too
but i assume that is wrong


thx in advance for taking the time to help us
E-Male




-
Get your FREE email account at Asheville.com.
   http://mail.asheville.com


___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] jpeg-exif continued

2005-01-13 Thread William Skaggs

Okay, following up on earlier discussion: I think I have a reasonable
way of dealing with the jpeg-exif stuff until Raphael's metadata code
arrives.  Raphael's plan is to turn everything into XMP and store it
all in a single parasite.  The interface between the jpeg plug-in and
the metadata system, so far as exif is concerned, would consist of two
functions, gimp_metadata_store_exif() -- which translates the exif
into XMP and adds it to the metadata parasite -- and
gimp_metadata_generate_exif(), which constructs an ExifData struct
using the information from the metadata.  (Raphael's plan has them
implemented as plug-ins, but I think that's too awkward.)

I rewrote the jpeg plugin to use those two interfaces. As I now have
it written, here is what it does:  

On loading an exif-jpeg file, it (1) calls
gimp_metadata_store_exif(), and (2) extracts the orientation from
the exif and, if it is not top-left, queries the user whether to
rotate the image.

On saving an exif-jpeg file, it (1) calls
gimp_metadata_generate_exif(), and (2) sets the correct values for
fields that according to the exif specs should be modified when an
image is saved, including the thumbnail, image dimensions,
orientation, etc.

It won't be possible to fully implement the two interface functions,
gimp_metadata_store_exif() and gimp_metadata_generate_exif(), until
Raphael's XMP parsing/formatting code is in CVS -- and even then it
will be a lot of work.  In the meantime, I created temporary
implementations that do the following:

gimp_metadata_store_exif() serializes the exif data and attaches it to
the image as an exif-data parasite.

gimp_metadata_generate_exif() extracts the contents of the exif-data
parasite and deserializes them.

That is, the two functions combine to handle the exif data in the same
way that it has been handled in the past.  I put the code for the two
functions (and a few small utility functions) into a new file called
gimpexif.c in the jpeg directory.  This should eventually go into a
new metadata library, but it can live in the jpeg directory for a
while. 

So, to sum up, I believe that my code makes the jpeg plug-in handle
exif data correctly, and interface correctly with Raphael's system.
It no longer creates any parasites except exif-data  -- which means
that there is no way to edit the exif data until Raphael's editor is
available, but so be it.  Future development consists of implementing
the two interface functions so that they actually translate to and
from XMP, and implementing the metadata editor.  

I've tried to put this together in a way that meets all concerns, but
I'm perfectly happy to make further changes if there would be better
ways of doing things.

Best,
  -- Bill
 

 
__ __ __ __
Sent via the CNPRC Email system at primate.ucdavis.edu


 
   
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] jpeg-exif continued

2005-01-13 Thread Robert L Krawitz
   Date: Thu, 13 Jan 2005 12:29:15 -0800
   From: William Skaggs [EMAIL PROTECTED]

   On loading an exif-jpeg file, it (1) calls
   gimp_metadata_store_exif(), and (2) extracts the orientation from
   the exif and, if it is not top-left, queries the user whether to
   rotate the image.

I know I've been making a nuisance of myself about this, but PLEASE at
least provide a way to turn this query off.

-- 
Robert Krawitz [EMAIL PROTECTED]

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
Project lead for Gimp Print   --http://gimp-print.sourceforge.net

Linux doesn't dictate how I work, I dictate how Linux works.
--Eric Crampton
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer