next thread »

[GIMPel]

If the sensor has a resoultion of 14-Bit linear, then it can#t be saved in 8-Bit without compression or loss of data.

No it can't indeed. But neither can it in 16bit linear space, can it?

If you use the data and just give it more space (16-Bit).
The data can be saved without loss, if the 14-Bit data is linear.
If it is not, then 16-Bit might be even to small...

...we then go into sensor details.
We would have to look into the characteristic curve of the sensor,
to look at what the sensor provides.

If the sensors are already provide 14-Bit through a logartithmic curve
(what is new to me, that they do), then there should also be much more
resolution possible...

And when we say, 14-Bit are from a logarithmic curve, we have to distinguish
where the 14-Bits are.

Is the input range aequivlanet to 14-bits, but the output range is just 10 bits or less?
Or is the OUTPUT aequivalent to range 14-bit linear?

If the later, it firs nicely into the 16-bit
And if the former, then it fits into it even better.

I meant: if there are 14-Bit linear output data... then it fits.
If there aree 14-Bit log. output, the sensor resoultiion would be much higher.
I doubt that, because if so, the marketing would have used the aequivalent
linear number and would have called it maybe 18-bit sensor.

So maybe it's 14-bit input range, logarithmic curve creating 10-bit output data, and after raw-conversion is again 14-bits wide, linear, and can be stored in 16-bit format better than in 8-Bit.


EDIT: some clarifications on the used words added.

[GIMPel]

[...]

@Mickey: Why is the result get so different than that given by Mathias?

I am still eager to know how you achieved the green graphics without bending...

Photoshop or Krita?  

So you accuse me of lying???

Don't overlook the smiley, please.

I'm just astonished, why you always say, we don't need higher
resolution, even all people want to have it.

Before having the filters on 16 bit in dlRaw I also had many of them as gimp scripts, and they worked fine. I could not go that extreme and I had to fix some artifacts from time to time, but thats not that much work... That was the only I thing I wanted to make clear. Or in simpler words, if you're work sucks, it's most likely not because of gimp or 8 bit ;-)

Yes, you already brought in some examples, where we can see you are an expert in Gimp usage.
And many of us are not. Mee too... I'm using Gimp since a while, but have not found out many ways in using Gimp. Compared to a beginner I might look lkike an expert, but I'm somehow a Gimp-beginner.
But when I have to use one special way of usage to prevent artifacts,
this are workarounds. The user has to go one-of-many possible directions,
so that he avoids the traps.

And you always argue for this way, instead of just support the users in their way.
And always when we ask for enhancing Gimp, you say, the raw-converter can provide that functionality. But inserting any functionality, that rather belongs to the image processing program, IMHO makes no sense.

It seems to me you implement the features you want to have in the raw-converter, just to avoid the workarounds of gimp. If you want, you can do. But I see no reason why you argue against our wish to avoid the workarounds in gimp directly.

And you insist on this.

That's the reason why I became cynical.

[GIMPel]

[...]
(I recently read [in part] Margulis' book on LAB...).
[...]

Which book?

You can recommend that book, it seems.

let us know which it is, please.

[GIMPel]

another thing that would be pretty awesome is the ability to save/export the editing history.
what i mean by that is not the images of the different steps that gimp caches somewhere in the background as far as i know, but that it should be possible to save the parameters of the operations applied to the image.

closely related, yet even better is another hypothetical result of saving operation parameters:
if you could undo an operation that is some time back in your undo history.
i imagine a popup coming forth, reminding you that XX operations have been performed since that point, and that re-rendering the following ones might take some time.

I thought already ahve seen an undo history, even I not often use it
(I nearly never use it).

But it would  throw away all steps that have followed.

You seem to vote for something that just recalculates all data.

Nice idea, IMHO.

[GIMPel]

another thing that would be pretty awesome is the ability to save/export the editing history.
[...]

...this would be something like an always active macro recorder,
if you also could use that history to be reinvoked...

[GIMPel]

I had asked about a thing like that in the dev's list. A contact from the forensic field could perhaps insert GIMP into their outfit if it can make a (relativly) tamper proof record of all actions applied.

...should be possible to switch off...?

[stepanekos]

Which book? You can recommend that book, it seems. let us know which it is, please.

Here you go!

Dan Margulis: Photoshop LAB Color. The Canyon Conundrum and other Adventures in the Most Powerful Colorspace.


It's often recommended by prof. PS-users. I 've bought mine at ebay for some €.
More on Dan Margulis: http://en.wikipedia.org/wiki/Dan_Margulis
There are some online articles by Margulis, too.

Sure, most of the techniques can't be reasonably replicated in Gimp; we have de- and recompose, but for subtle changes you need a real time preview. At the moment the best way to work with LAB in Gimp is the Gmic-plugin.

[Rolf]

I had asked about a thing like that in the dev's list. A contact from the forensic field could perhaps insert GIMP into their outfit if it can make a (relativly) tamper proof record of all actions applied.

...should be possible to switch off...?

No, it should be compiled with that option permanently on. It has to be more tamper proof than PS. And the machines are for work only, clamped down, central software management, audits and so on. Even the USB ports are locked shut.

[stepanekos]

Another thing I miss: (distinguishable) overlay and soft light layer modes.
Yes, I know, for some historic reason .....
To handle this, a third mode could be added, eg. Soft Light (modern times). 

[PhotoComix]

No... search for 'macro' in this forum and you will find several threads where people asked for this feature

And many other asked in other gimp forum, except that they often don't use the word "macro recorder" but "something as PS action"

But the sad thing is that the gimp staff consider "request" only what reported in the gimp bugzilla , that is their Holy Book for checking bugs and enhancement requests

Gimp bugzilla  is widely considered a very unfriendly place...there if you had something to request or bug to report first you have to go beyond some boring bureaucratic steps, then  you have to be very ,very careful with your phrasing , or  you post will be immediately discarded as pure nonsense without further checking

... anyway even bypassing all this obstacles you have a very high risk to get as reply just stingy and sarcastic remarks

Only if your post by pass all that obstacles and don't offer any grip for sarcastic remarks you may hope in some result
.(.BUT. in 99% of those cases the only  result will  be a invite to propose a patch to solve the problem ).

Back to the point some of the gazillions of of request for 16 bit support, CMYK, and adjustment layers( i suppose for pure force of their initial numbers, even filtering out the 99.99% of requests, in case of gazillions something will remain ), went somehow trough bugzilla and so where noticed

As for request for macro recorder reported on Bugzilla  you may found very few, so for gimp staff that is not something not too requested

BUT as good new for one of the main developer "With gegl that A Macro Recorder shall  be much more easier to implement "...but nobody is working on it

[GIMPel]

So this should make up for more than one f-stop, if you can say so at all. One f-stop equals 1:2 ratio in light intensity, doesn't it? So this would rather equal one bit

Yes, that's right. The highest and lowest encodeable lightness per channel is the same for 8bit and 16bit linear data. It is just expressed as a different number, 0 to 255 and 0 to 65535 respectively. You simply have more intermediate steps to get there.

And this is called higher dynamic range, btw.

[...]

http://wiki.panotools.org/Dynamic_range