Legacy ImageMagick Discussions Archive

Not sure what happens as we have no sample file. One problem with some old versions was that a false background color (bKGD chunk) could get set. For example, when reading an indexed transparent PNG (with background color from the palette), it could get written as PNG32 as default, but the backgroun...

You're right. With v6.7.3-6, this was still possible: Endianess: LSB
...
tiff:endian: msb

It seems that the output of "tiff:endian" stopped with v6.7.3-7.

The last answer has disappeared?! Anyway, here's my reply (to magick): I didn't want to sound negative. After all, I'm very grateful for ImageMagick - and for the possiblity to do operations in linear space (with sRGB files). With many programs, that's not possible at all. I didn't say that some ope...

By the way: "-define tiff:fill-order" (taken from here) doesn't seem to work at the moment? The fill order can only be changed with "-endian" (well, and with a simple read/write cycle, see above).

I am understanding it that way that IM always showed the FillOrder (the order of the bits within one byte) with "Endianess". So, it tries to show the effect of "-endian" at the moment. The byte order is controlled with "-define tiff:endian" and is not shown with identif...

I think that there's still an issue (though a small one). The TIFF files itself have no problem anymore (no confusion with the ByteOrder). But IM doesn't interpret the FillOrder in a completely correct way. convert rose: -endian lsb rose.tif It gets indeed written as LSB/FillOrder 'Reversed'/Little ...

I thought that was because -colorspace RGB was broken. That was what first broke, also relativity recently (probably 6.7.4-7 or so as a guess) then the -colorspace sRGB broke shortly after. I again tried every subversion of 6.7.4 (well, the Windows binaries). I didn't find a single version where &q...

Side note: As we said, there are no automatic conversions anymore since some versions, so IM's internal 'sRGB' is allowed to be outputted directly (without the "-colorspace sRGB -set colorspace RGB" trick). But that has also the effect that - with output format PNG - the PNG coder apparent...

NOTE the reason that colorspace fixes was postponed to IMv7 was that it would introduce changes that are different to any IMv6 script that uses colorspace correction. Making thes changes now is not in my thinking a good idea (their will not greater changes in IMv7 colorspaces, than just fixing the ...

"-colorspace CMYK" is alright. But try to convert it back with "-colorspace RGB"... "-set colorspace" is also alright for me. Of course, you chose an extreme example by setting a 4-channel colorspace when you have only 3 channels. :) (Sure, crashes of the encoder or 0 b...

It seems that "-colorspace RGB" and "-colorspace sRGB" don't work anymore in the current binaries..? Using IM v6.7.5-1 Q16, on Windows XP. That means that operations can't be done in linear RGB space. But of course the 'regular to RGB' conversions aren't possible either with that...

Thanks for that link!
Maybe I will have some remarks. Though, with a lot of these things, colorspaces, etc., my head spins, too.

Hi, It's not Ghostscript that converts the image to linear RGB, but ImageMagick. The "-colorspace sRGB" before the input tells IM to use a Ghostscript command with a RGB output device, but it also converts to 'sRGB' (which is still linear RGB for IM) after it gets the the correct output fr...

alex88 wrote:it still takes too much time.

But way less time than with a normal "convert -crop" - on my system, this would take not 10 seconds, but 10 minutes! (As convert really reads the full image, and that's too big for my RAM, so sloow swapping starts.)

You mean using .\jpegtran.exe -crop 1600x1600+0+0 .\huge4.jpg output.jpg? No, no - that thing with the multiples was only a general hint regarding the starting point/offset. But with "+0+0", that's of course no problem here. Even with this image (sorry for megaupload but a friend passed t...