List Info

Thread: Image Properties dialog limited to 10000 pix width




Image Properties dialog limited to 10000 pix width
user name
2006-12-09 19:20:24
On Saturday 09 December 2006 19:45, you wrote:
> Hi Boudewijn,
>
> >> After editing a 40000x1000 16 bit image,
wanted to convert to 8 bit and
> >> save.
> >
> > Wow... I mean.... Eeek! An image of that size -- I
mean to say, I'm glad
> > it works for you! The 10000 limit was put in
because we got reports about
> > Krita crashing or choking the whole system with
images that were too big.
>
> *g* My image is very wide but not very high, and my
machine has 1.5 GB RAM.
> Btw. you can see a smaller version at
>
> http://home.arcor.de/pablo.dangelo/al
bum/Nature/slides/alps_seen_from_ulm-o
>rig.html

Wow!

> Thanks for the tip about the conversion.

It's actually a topic we're debating right now for Krita:
the image properties 
dialog sets, as I explained, the projection -- but you're
not the only one 
confused. The thing is this: you can have layers of
different colorspaces in 
one Krita image, and the projection determines how the image
is rendered.

The options are:

* Keep it this way, adding a little bit to the learning
curve.

* Remove the option to set the colorspace from the image
properties dialog and 
always use the colorspace of the background or bottom-most
layer. Make the 
the colorspace of hte image a read-only label in the image
properties dialog. 
This removes a bit of flexibility, but is easier to grasp.

* Move the option to set the image's native colorspace to
the color conversion 
dialog. Make the the colorspace of hte image a read-only
label in the image 
properties dialog

So, what do you think? (CC'd to the mailing list, for wider
discussion).

-- 
Boudewijn Rempt 
http://www.va
ldyas.org/fading/index.cgi
_______________________________________________
kimageshop mailing list
kimageshopkde.org
http
s://mail.kde.org/mailman/listinfo/kimageshop
Image Properties dialog limited to 10000 pix width
user name
2006-12-10 14:00:26
Hi Boudewijn,

Boudewijn Rempt wrote:

> It's actually a topic we're debating right now for
Krita: the image properties 
> dialog sets, as I explained, the projection -- but
you're not the only one 
> confused. The thing is this: you can have layers of
different colorspaces in 
> one Krita image, and the projection determines how the
image is rendered.

As you might have guessed, I haven't read any documentation
about krita
before starting.. 

I'm not familar with internals of krita, so I don't know how
merging of
different layers is handled. My first guess from your
explanations is that
upon rendering (and saving to non native formats) the pixels
are converted
into the "projection color space" and the merging
takes place in that
colorspace?

Another possibility would be that composition is done in a
colorspace that
is a superset of all layer colorspaces, and converted down
to the image
colorspace afterwards.

Well, logically this feature belongs into the image dialog,
however it needs
some more thinking since many users will probably don't
know/have forgotten
that krita supports layers with different types.

> The options are:
> 
> * Keep it this way, adding a little bit to the learning
curve.

Maybe with some additional description like "final
colorspace" or
"projection colorspace", or something along these
lines might make this a
bit more clear to users that forget about the layer issues
etc.

I was only editing a single layer, in that case the
projection colorspace
could be fixed to the layer colorspace.

> * Remove the option to set the colorspace from the
image properties dialog and 
> always use the colorspace of the background or
bottom-most layer. Make the 
> the colorspace of hte image a read-only label in the
image properties dialog. 
> This removes a bit of flexibility, but is easier to
grasp.
> 
> * Move the option to set the image's native colorspace
to the color conversion 
> dialog. Make the the colorspace of hte image a
read-only label in the image 
> properties dialog

Hmm, might be a better solution, since then the user has to
choose which
colorspace he wants to change. Maybe a radio button to
select between
"convert all layers" and "final image
colorspace" would be enough?

Btw. which rendering intents are used for the conversion
into the image
color space?

ciao
  Pablo
_______________________________________________
kimageshop mailing list
kimageshopkde.org
http
s://mail.kde.org/mailman/listinfo/kimageshop
Image Properties dialog limited to 10000 pix width
user name
2006-12-10 22:18:22
> * Move the option to set the image's native colorspace
to the color conversion 
> dialog. Make the the colorspace of hte image a
read-only label in the image 
> properties dialog

it was the option I was thinking. And have a checkbox to set
if the user
want to convert all layers to the given colorspaces.

-- 
Cyrille Berger
_______________________________________________
kimageshop mailing list
kimageshopkde.org
http
s://mail.kde.org/mailman/listinfo/kimageshop
Image Properties dialog limited to 10000 pix width
user name
2006-12-18 20:06:58
On Sunday 10 December 2006 15:00, you wrote:

> As you might have guessed, I haven't read any
documentation about krita
> before starting.. 

Well, that _should_ work. Not that the documentation isn't
quite good, 
especially for an open source project, with lots of
informative little 
tutorials and tips 

> I'm not familar with internals of krita, so I don't
know how merging of
> different layers is handled. My first guess from your
explanations is that
> upon rendering (and saving to non native formats) the
pixels are converted
> into the "projection color space" and the
merging takes place in that
> colorspace?

Yes, that's right.

> Another possibility would be that composition is done
in a colorspace that
> is a superset of all layer colorspaces, and converted
down to the image
> colorspace afterwards.

We've thought about that, too, but there are problems with
that approach, 
especially since a colorspace that's a superset of all
colorspaces in Krita 
would be something like 32-bit XYZ or L*a*b -- and that
would make krita eat 
a lot more memory than it does now. And if it's to be a
superset of the 
colorspaces currently in the image, then we need to have a
kind of sliding 
scale of capabilities.

> Well, logically this feature belongs into the image
dialog, however it
> needs some more thinking since many users will probably
don't know/have
> forgotten that krita supports layers with different
types.

Exaclty. It's not a common feature 

> > The options are:
> >
> > * Keep it this way, adding a little bit to the
learning curve.
>
> Maybe with some additional description like "final
colorspace" or
> "projection colorspace", or something along
these lines might make this a
> bit more clear to users that forget about the layer
issues etc.
>
> I was only editing a single layer, in that case the
projection colorspace
> could be fixed to the layer colorspace.
>
> > * Remove the option to set the colorspace from the
image properties
> > dialog and always use the colorspace of the
background or bottom-most
> > layer. Make the the colorspace of hte image a
read-only label in the
> > image properties dialog. This removes a bit of
flexibility, but is easier
> > to grasp.
> >
> > * Move the option to set the image's native
colorspace to the color
> > conversion dialog. Make the the colorspace of hte
image a read-only label
> > in the image properties dialog
>
> Hmm, might be a better solution, since then the user
has to choose which
> colorspace he wants to change. Maybe a radio button to
select between
> "convert all layers" and "final image
colorspace" would be enough?
>
> Btw. which rendering intents are used for the
conversion into the image
> color space?

Good question. I'd need to check the source.
-- 
Boudewijn Rempt 
http://www.va
ldyas.org/fading/index.cgi
_______________________________________________
kimageshop mailing list
kimageshopkde.org
http
s://mail.kde.org/mailman/listinfo/kimageshop
[1-4]

about | contact  Other archives ( Real Estate discussion Medical topics )