Assigning to andre999

Assignee: stormi => andre999mga

I'm too busy right now.  I'll look at it later, if someone else doesn't take it first.

Hi Andre, what's the status?

I hadn't really looked at it.

I handles 24 bit images now. (8 bits per colour).
Which is more than the 16 bits you are asking for.
So closing as invalid.
If you meant something else, please feel free to reopen.

Status: NEW => RESOLVED
CC: (none) => andre999mga
Resolution: (none) => INVALID

Not sure, because the request is 16 bits per color, therefore double than now...

Status: RESOLVED => REOPENED
Resolution: INVALID => (none)

I think that you are asking for something beyond the capacity of human perception.

In any case, a 16-bit png image is 16 bits for all colours, and not 16 bits per colour.  (with 5 or 6 bits per colour.)
(I agree that a 16-bit png is not a very high quality resolution for complex images.)

A quick test on my system showed that most png images are already displayed 24 bits by graphicsmagick.
Note that 24 bits is 2**24 colours = more than 16 million possible colours.
24 bits per colour would be 2**72 = more than 4 * 10**21 possible colours.

(There are also 32-bit png images, which use the extra 8 bits for transparency.)

Not sure that there is any real benefit to compiling with more than 8 bits/pixel.
If I understand correctly, that would lead to larger images generated by imagemagick, for essentially no visual benefit.

see 
$ gm help display
for more info

I'd like to import another RAW photo-processor -- Photivo, that requires 16bit (not 8bit) version of graphicsmagick. I'm able to recompile this lib. just by myself, but in case I'd like to import Photivo to Mageia, there must be only one version of graphicsmagick and this is requirement... Therefore since I'm not maintainer of graphicsmagick, I'd like to discuss this issue with you.

I believe, the change is only to change line 15:

%define qlev            Q8
to
%define qlev            Q16

in SPEC file...

Interesting ...
A quick look at the photivo site indicates that for 8-bit pixel formats (like png), it uses 16-bit pixels only for conversions.  Which should make a difference in the quality of at least some conversions.

The site also indicates that photivo is processor intensive, indicating that a 64-bit cpu is preferable.  I wouldn't want that to be imposed on graphicsmagick users, many of whom have 32-bit machines.

Could you verify that photivo actually needs a 16-bit pixel version of graphicsmagick ?

Meanwhile I'll look into side effects for graphicsmagick.

According to the graphicsmagick site, increasing the quantumdepth (pixel size) to 16-bits will almost triple the processing memory required.
They recommend using a 64-bit processor with lots of memory in such cases.
Maybe a good solution would be to have a special version of graphicsmagick for 64-bit processors, which photivo users would install.

Just need to give it a different name.  It would be required by photivo, and would provide graphicsmagick and conflict with the regular graphicsmagick.
This would also allow most 64-bit users to install the regular graphicsmagick if they wish.

Another potential solution is to make the 64-bit version have a quantumdepth of 16, the 32-bit version the default 8.  Then 64-bit users won't have a choice.

In any case, if/when you import photivo, a graphicsmagick compiled with 16-bit pixels could be made available for 64-bit machines.

I confirm that Photivo requires 16-bit version  of graphicsmagick. 
Using Photivo with 8-bit version is not possible.

I think 16 bit quantumdepth only for 64-bit version is a good solution. On 64-bit systems do not need to save memory so much.
Two versions graphicsmagick may have complicated dependency resolution.

Photivo is good photoprocesor. I use it intensively. But I must using my version of graphicsmagick.

CC: (none) => vit.brezina

André and Petos, what's the status on this?

I would be in favour of packaging graphicsmagick with a qlev of 16 under a different name, not to decide that i586 users will have a quantumdepth of 8-bits while the x86_64 users will have 16-bits.

i586 users may want to use Photivo with the processor intensive version of graphicsmagick, knowing that it will be painfully demanding, whereas x86_64 users may want the (current) light version of graphicsmagick.

We should just find a sensible name for the processor intensive version, and then Petos can package Photivo following the advices from comment 9.

CC: (none) => remi

Ping.

Version: 2 => Cauldron

(In reply to Rémi Verschelde from comment #11)
> André and Petos, what's the status on this?
> 
> I would be in favour of packaging graphicsmagick with a qlev of 16 under a
> different name, not to decide that i586 users will have a quantumdepth of
> 8-bits while the x86_64 users will have 16-bits.
> 
> i586 users may want to use Photivo with the processor intensive version of
> graphicsmagick, knowing that it will be painfully demanding, whereas x86_64
> users may want the (current) light version of graphicsmagick.
> 
> We should just find a sensible name for the processor intensive version, and
> then Petos can package Photivo following the advices from comment 9.

I agree.
I think a name like graphicsmagick16 would be clear, for the 16-bits-per-pixel version.
With a warning added recommending a 64bit system to use it.

I'm not set up to do this at the moment.
So anyone feel free to take it, if I haven't yet done it.

Hi guys,

OpenSUSE (13.2, Factory) has already a package as following:
-for i586:
-- libGraphicsMagick-Q16-3-1.3.20-1.6.i586.rpm
-- libGraphicsMagick++-Q16-3-1.3.20-1.6.i586.rpm

-for x86_64:
-- libGraphicsMagick-Q16-3-1.3.20-1.6.x86_64.rpm
-- libGraphicsMagick++-Q16-3-1.3.20-1.6.x86_64.rpm

Maybe you can repack for Mageia...

CC: (none) => yullaw

Packager: What the status of this bug report?

Seems other distributions have already do some job.

I haven't been set up for packaging for some time, largely due to time limitations.
From the most recent comments, it should be relatively easily resolved for anyone set up for packaging, particularly since another rpm-based distro has resolved the problem.
The suggestion of creating a new 16-bit-per-pixel version for both 64 and 32 bit installs seems the best approach.
So I suggest leaving the report open.
(Eventually I intend to return to packaging.)