Re: [Gimp-user] Image bit depth

2008-01-16 Thread Thomas Worthington
It's worth remembering that printing is almost universally still 8bit.  
However, it is clearly very important that any current image package  
should allow opening and manipulation of greater depth images. My own  
camera is a long obsolete Fuji S20 but it produces 12bit images. As a  
result all my post processing is done in ImageMagick and the GIMP is only  
of use in opening the final jpg fro cropping and printing.

But, 32bit and 64bit colour is effectively meaningless. It would certainly  
be useful for an image package to work internally in 32bit, and maybe even  
64, so that the results of, for example, multiple layers with transparancy  
can be calculated without errors showing, but for both input (ie, taking  
the original picture) and output both 32 and 64 bit is a waste of time and  
probably money too.

TW

On Wed, 16 Jan 2008 10:25:39 -, 7willows [EMAIL PROTECTED]  
wrote:

 Hi,

 As an in frequent GIMP user since v1.2, GIMP was used just cropping and
 resizing images. One of the computer magazines I picked up in a locale
 store had published an article on GIMP showing how to selectively
 colourise based on Eric R. Jeschke tutorial, which I tried.

 In another magazine around the same time, a challenge was presented (no
 prize) to manipulate a series of images and I thought I would use GIMP
 to improve my knowledge of GIMP. While I suceeded in completing the
 challenge using GIMP it was tinged with disappointment that some of the
 images where downgraded from 16bit to 8bit images.

 After having a trawl through the GIMP Development site and GIMPcon 2006
 and the GIMP vision which I think is very good. As a very inexperienced
 GIMP user, the fact that GIMP can not handle a 16 or 32bit monochrome
 image immediately is a reason not to invest any more time in GIMP.  The
 inexperienced user wants to load an image and generally crop and resize,
 then comes combining images. Eventually, more complicated manipulation
 is attempted unless a specific objective is required. Can I ask when 16
 and 32 bit monochome images can be loaded?

 As CPUs are now primarily 64bit (I am running Solaris 10 x86 as a 64bit
 OS) could the design of GIMP be adjusted so that maximum image bit depth
 becomes user selectable 32 or 64bit? As a lapsed programmer (only using
 sh and no compiled language for over 10 years) I fully appreciate it is
 not a simple fix.



___
Gimp-user mailing list
Gimp-user@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user


Re: [Gimp-user] Image bit depth

2008-01-16 Thread Joao S. O. Bueno
On Wednesday 16 January 2008 07:58, Thomas Worthington wrote:
On Wed, 16 Jan 2008 10:25:39 -, 7willows [EMAIL PROTECTED]  
wrote:
  As CPUs are now primarily 64bit (I am running Solaris 10 x86 as a
  64bit OS) could the design of GIMP be adjusted so that maximum
  image bit depth becomes user selectable 32 or 64bit? As a lapsed
  programmer (only using sh and no compiled language for over 10
  years) I fully appreciate it is not a simple fix.

Adding to Thomas answer: the larger integer size in CPUs being 64 bit 
has absolutely  nothing to do with the pixel depth a program can use.
One could write a program to manipulate images in which each pixel was 
represented by a 5 X 64 bit in an 8 bit machinne.

But, answering you both: yes, current gimp trunk is using GEGL for 
some color operations, which are them performed at 32bit floating 
point precision.  Version 2.6, which will come out this year will 
implement that, but likely it won support saving in more than 8bit 
per channel.

If you are working with monochrome, and 16 bit final output formats 
would indeed make a difference, I suggest increasing your resolution 
by a factor of 2 or 4 to overcome this.

js
--

___
Gimp-user mailing list
Gimp-user@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user


Re: [Gimp-user] Image bit depth

2008-01-16 Thread Thomas Worthington
On Wed, 16 Jan 2008 13:49:59 -, Joao S. O. Bueno [EMAIL PROTECTED]  
wrote:

 But, answering you both: yes, current gimp trunk is using GEGL for
 some color operations, which are them performed at 32bit floating
 point precision.  Version 2.6, which will come out this year will
 implement that, but likely it won support saving in more than 8bit
 per channel.

Surely it will support 16bit png output? Would that not be trivial given  
that it's a part of the standard PNG library?

TWW
___
Gimp-user mailing list
Gimp-user@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user


Re: [Gimp-user] Image bit depth

2008-01-16 Thread Joao S. O. Bueno
On Wednesday 16 January 2008 12:01, Thomas Worthington wrote:
 On Wed, 16 Jan 2008 13:49:59 -, Joao S. O. Bueno
 [EMAIL PROTECTED]

 wrote:
  But, answering you both: yes, current gimp trunk is using GEGL
  for some color operations, which are them performed at 32bit
  floating point precision.  Version 2.6, which will come out this
  year will implement that, but likely it won support saving in
  more than 8bit per channel.

 Surely it will support 16bit png output? Would that not be trivial
 given that it's a part of the standard PNG library?

Yes, that would. The problem is that the internal image format in 
GIMP, while not executing an opertaion will likely be 8 bit still. 
Therefore, there would  be no gain in saving it to 16bit.  

but it might be that the developers start working with the layers in 
ahigher depth representation still in this cicl. OI fthat happens 
certainly there will be 16 bit save options.

js
--




 TWW
 ___
 Gimp-user mailing list
 Gimp-user@lists.XCF.Berkeley.EDU
 https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
___
Gimp-user mailing list
Gimp-user@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user