[Gimp-user] Bit-depth Processing

[gimp_user]

On Wednesday 26 September 2007 02:22:14 Leon Brooks GIMP wrote:
> On Wednesday 26 September 2007 19:13:48 David at ATF4 wrote:
> > They all need to facilitate collaboration using a common
> > software interface, so that all users in the supply chain
> > can be mutually supportive and produce compatible output.
> > This requiredment is particularly strong with software which
> > has so many features that no one user will be totally familiar
> > with all of them.
>
> GIMP wins that one simply by being available to everyone.
>
>  * Nobody uses a machine GIMP won't run on; &
>
>  * Nobody is too poor to use GIMP; oh, & staying up to date
>    is cheaper, too; &
>
>  * Nobody lives in a country to which GIMP is a forbidden
>    export; &
>
>  * Nobody lives in a country in which GIMP is capitalistic
>    exploitation, environmental abuse, racist technology or
>    whatever; &
>
>  * Any national inspectors can see any part of GIMP they
>    like, with or without warrants, 24x7; &
>
>  * GIMP is not unclean in any known religion (although in a
>    few real places, you'd have to replace Wilbur -- which you
>    could do without copyright/trademark/whatever issues).

These points may be true but for professional there are totally irrelevant. 
They do not care about what machine it runs on.. they are more concerned 
about the output than the means. These points are only relevant to those who 
are NOT faced with the requirements of the professional world. GIMP IMHO 
needs to address the needs of the real world.

>
> > When gimp provides an alternative skin that emulates PS and
> > solves resolution and compatibility issues (including integrated
> > raw handling, exif manipulation and image library management
> > then it is potentially adoptable as an alternative for high quality
> > image makers.
>
> OK;
>
>  * Raw imports are a plugin; &

Inconvenient and how does one deal with the issue of non-destructive editing?
>
>  * Exif manipulation can be done externally -- or, sooner or
>    later, someone will write a plugin, no doubt with convenient
>    (semi-)automation facilities; &
Inconvenient and impractical
>
>  * A PhotoShop face has already been done (& was poorly
>    supported to wide scorn), so it could be done again, only
>    in a more systematic fashion; &

It only received scorn because the GIMP development team ignored the basic 
requirement of development - using MVC in the early days - so the  code 
structure does facilitate view customization (or skin development).  IMHO 
Gimp has never recovered from that internal structural system design flaw. 
>
>  * Image library management can be done externally but I
>    imagine would be a natural interest for an EXIF plugin.
>
> So... all of this is possible. I think if a PS "face" were done
> for real, it could only survive as a kind of strap-on rather
> than a replacement for GIMP.

If there was an MVC architecture there would be no need to 
consider "replacement" as a necessary choice.
>
> That would also provide a safety buffer for GIMP should Adobe
> get restless about a percieved imitator, since you can be sure
> they'd be most uninterested in losing sales due to software-
> photocopying of their trademarked, copyrighted, etc industrial
> design (not that it's good, by any means, just that everybody's
> used to it; sort of parallel to MS-Office like that).
>
provided the size proportions and designs of the interface are not a copy and 
is a means of controlling entirely different source code I do not believe 
this to be hurdle. Maybe some members of the team are unnecessarily scared of 
rousing adobe's wrath! An MVC architecture and user view customisation tools 
would be much more attractive route because it would lay the groundwork for 
emulating other tool sets including any future tools competitve to PS. The 
challenge for gimp is how to create a long term strategy which may enable it 
to flexibly meet future needs that cannot be accurately forecast now. MVC 
architecture provides the flexibility required here. So IMHO the next major 
version of GIMP requires a total recasting of the code structure in line with 
an MVC architecture. The current system architectural is the major stumbling 
block for the long term. Until that is solved I do not see GIMP moving away 
from the beached whale status as far as its professional high quality image 
manipulation future.

> A down-side of this imitation would be that it effectively acts
> to support & retain Adobe's market monopoly. People would
> tend to view it as "the real thing" (tm Coca Cola) & GIMP as a
> mere copy rather than as an independently architected work
> of genius.
>
> Cheers; Leon

I am afraid we have to deal with the real world rather than the world as we 
would wish it to be. I have always thought there has been a lack of grasp of 
the implications of the real world adverseley affecting the choices that the 
gimp development team make. There is no doubt that Gimp is a substantial work 
but its design flaws and most notably the lack of a well designed MVC 
architecture and its dependency istructure makes me more than uncertain about 
allocating it a genius tag! 

Frankly more concentartion upon the practical needs of high quality image 
manipulation and less attachment to burnishing its own image would lead to 
Gimp becoming a much more attractive toolset with real world potential.