Indexhibit Support

Hi,

I'm working on a site for a photographer but I notices that when I upload images they change A LOT.
Here is a example of how they look next to the original...
bennyarts.com/…

Cheers,
Ben

A LOT? I disagree with that...

How much have you compressed the image before uploading? What have you done to optimize it for the web (there is a lot of research about this out there - even browsers can render an image differently). You do realize that Photoshop can look different than things in your web browser, right?

You could try, but I have a feeling it won't be good enough for you, change the compression quality setting from 90 to 100 in /ndxzsite/config/options.php.

Well,

To me the left image really has a lack of colour and looks greyish...
Could this be because of my screen?
I work with an iMac so I would assume it's a good screen...

I changes the resolution to 72dpi and the size to 600px x 600px...

I'll let others say if they feel they are so different - they aren't to me - I'm on a Mac too.

It's about the compression. We use the GD library to resize images and it's not going to do a 100% replica of the image - it's always been that way and GD is the standard library nearly everybody uses. To my knowledge Imagick doesn't do a better job in this respect.

Now, something like Flickr or other hosted sites have million (billion?) dollar setups that can do things differently - something normal folks can't afford with shared hosting.

Alright,

I updated the compressing to 100 and it seems it's a little better now.

Cheers!

I agree, for a photographer that is a big shift.

Have you tried converting the file to sRGB before saving as a jpeg?

Most photographers will be using either Adobe RGB (1998) or ProPhoto RGB colour spaces and web browsers cant fully reproduce all the colours, converting to sRGB before saving as a jpeg helps by approximating to colours to the closest colour varient that can be displayed by a web browser.

As Vaska has said, compression can change colours and when a website has to resize an image that can also affect the quality.

Whats strange is that the original has more green in it and greater saturation but is part of the same image that you have uploaded, so I doubt its the website or browser. Have you altered or re-saved the photo on your computer since the photographer sent it to you? If so, my guess would be that you need to calibrate your monitor and make sure the correct colour space is set within photoshop otherwise any change or save you make will embed a different colour space to the image and mess up the colours.

Vaska, I was wondering... If 'fullpx' was selected in indexhibit does any resize take place and if not, perhaps resizing before upload would allow better image quality?

@Howard: I have alot to learn from you...great posts.

I believe that people should resize before uploading but it probably wouldn't surprise you that people don't do that most of the time. Photographers, in particular, I think would be used to that kind of thing.

What I believe should happen with fullpx is a set of professional set of formats that use the original image. We've built much smarter (meaning more code) exhibit formats and the space to do these things - it should happen at some point.

Edit: I had never thought about this until now, but the permalinks option should probably show the source image by default - I'll think about this.

Hi Howard,

My workspace is set to sRGB so normally this shouldn't be the problem.
What I think is very strange, is that when I look in the 'gimgs' folder, there are the greyish versions but also the normal versions...
So with other words, the site just uses the wrong ones...

So check this out:
sannedewilde.com/files/gimgs/…
sannedewilde.com/files/gimgs/…

Now I see the difference. The 'wrong ones' is what we are talking about. But, right now, that's how the formats work.

I have never seen a color shift that dramatic before with an upload...

hello,
i think i have the same problem... before and after uploading the images look different. the colours are not vivid anymore after uploading.
so there is no way to fix this problem?!?!

You should read the thread...you can change a default setting.

But, in the bigger picture, we can not control the GD Library and the quality of it's output. It's always been like this - it's like this for everybody.

Same problem here and it's quite a dramatic difference. I've changed the compression setting but it has little or no impact. Thing is, in Safari at least, it doesn't happen with the old version. Pics look the same as the source image. (In Firefox the colours do desaturate but I figured that was a browser thing.) I think - for us photographers especially - this is a major issue. Unless anyone out there can come up with a solution?

@jimmy: I'm looking at the code that actually resizes the image - there is nothing different about the process: imagecreaetruecolor() and imagecopyresampled(). It was the same in the first version of Indexhibit.

Can you show me a set of images on your site with this shifting? Link directly to them...

The good news though, is that your source image is not changed on the server. It's used as a base to re-output your images/thumbnails repeatedly. If we find a better way people will not have to reupload everything...

Thanks, Vaska. I just uploaded one sample image to the new site here: new.bensmithphoto.com/index.php/commercial/lifestyle/…

Here's what the same image looks like on my existing site (and what it ought to look like): bensmithphoto.com/commercial/test/

As you can see, there's a noticeable colour shift and desaturation.

On my computer it's a pretty subtle difference.

We can review what we're doing but it didn't change from the previous version. And, we are planning to build a new version of the uploader using Imagick (which is a better library but not nearly as many hosts use it).

And isn't there a way to make the slideshow pick the original images instead of the '21_' versions?

That would already make a difference for me.

We haven't changed the core code from version 1 to version 2. What would make the difference is to figure out why this is happening.

We can't change how Indexhibit works just because of this - it doesn't solve the real problem.

Hmm... Doesn't seem to make sense does it? Soon as I have some time I will try to figure out what's going on. I'm not sure whether it's an Indexhibit issue or whether it can be solved by preparing the images correctly in Photoshop to begin with. For anyone who's interested, there may be some clues in this excellent and thorough post on the matter: creativepro.com/article/…

this is a very instructive thread, thank you for the article, clears up quite a few things for me :)

not being a photoshop user, I'm curious how this translates in a more recent version of photoshop, the last comment was on cs3...

My thoughts exactly, pernin. It's a good article but it is 6 years old! A lot may have changed...

I'm a bit stumped as to why this would be happening with Indexhibit 2 - it's the same code, more or less, resizing the images.

It's on my list of things to look at but I can't get to it for a little bit...

Hello,
I've the same problem.......
but my photos get saturated on 2.0, I'm trying on version 1 and they are perfect....
can't figure out what's the problem.....I'm trying to save images in different ways.....sRGB, no color profile....but nothing, compression, no compression.....

They GET saturated instead of unsaturated? Ok, now that is strange...now we're going in the opposite direction.

Hello,

it's strange, usually they get unsaturated.......
I've just tried to convert the pic to adobe rgb 1998 and they get perfect......
Should work fine like this....

Thanx!

Let's hope that is the magical tip! ;)

As far as I know I also had this problem with 1.0...
Here is the picture with
1.0
bennyarts.com/files/gimgs/…
2.0
sannedewilde.com/files/gimgs/…
& direct onto the server
sannedewilde.com/…

here are my changes in colour. the top image is a direct html reference and the bottom was uploaded via indexhibit -
christopher-ms.com

So from what I have discovered, the real problem is not about compression or browsers or sRGB v. aRGB but simply that the GD library doesn't support or preserve colour profiles (ImageMagic does, it seems), which is why there is a colour shift after upload regardless of what colour space the image was originally saved in. When the image is processed the colour profile is discarded.

In V.2, this seems to happen whether the image needs to be resized or not. Which may help to explain why I wasn't having this problem with the old version. In V.1 there is no colour shift as long as the images are sized correctly to begin with (which is how I've always done it). The image then either doesn't get processed by the GD library or the original file is somehow used. If the image needs resizing though, the colour shift will occur.

Does that make sense, Vaska? I don't have any understanding of how it works technically but you obviously do.

It makes sense. I want to work on an Imagick version as soon as I can - got a list of important bugs to deal with first. It will happen...

I thought of a fix for this - and i'm not sure if it works as my images were not shifting enough in color to notice if it worked - but - what if you rename the original image in your FTP that you like - to be the name of the image that indexhibit is using?
Yes - it is tedious - but for now- I think it would work.

Also- when you reupload the options page to your server after changing the quality - make sure it actually overwrites the original. I had to delete the page out of my server, then reupload in order for changes to take.

jimmythesaint seems like you have the problem understood to me. It seems like the color profiles are just ditched completely. Im a photographer as well, and the color shift is dramatic. for me reder and more saturated. I convert to srgb and resize before uploading but the images are awful once viewed in index site. With version 1 I had no problems at all. I will see if adamstaffa's workaround works? Seems like a lot of work. I might need to load up index 1with my content as I had no issues, hate to build the site twice, thats why I was building out with two, rather then continuing on the first version of indexhibit. At least my css is done for version 2 once this problem is sorted. Any idea of timeframe for switching to imagemagic.. or whatever the proper fix is?

There is not a difference between v1 and v2 where the code/output of the files is concerned. Except, if it's a GD Library change...and we can't control this. It is a common problem around the web (not just Indexhibit).

i read elsewhere that GD removes the EXIF/IPTC metadata. Is that true?

Yes, it is. But, I think it's possible to grab that info at time of upload - the last time I looked into this there was one library that did that work and we couldn't afford to buy the license for it. It's something that on the list to review down the road again...

I am thinking about other options too - I want this to be good just as much as anybody else.

But, for the moment, bugs...getting collections moving...working on mobile...and then other projects...order of importance...

Thanks Vaska. I am back on V1 for now. Metadata and keeping color from shifting is huge for photographers. Not sure why CMS2 shifts so much and not 1. I primarily made the shift for the permalink gallery and liked that I could upload multiple images at one time. Am I correct that theres no way to support. I found a jquery script for deeplinking on the web but have no idea how to implement or if it would even work...

Maybe people have dealt with this by adjusting their monitor/app/color profile setup - it can help.

a profile could help - but its such a shot in the dark, there are icc profiles for printers, monitors, scanners etc-- adobe srgb is pretty much the standard for web. If there were an ICC profile for whatever is happening from GD- then you could at least see what your image looks like with that icc profile, but it is still a lot of adjusting for each image to look good in this profile. In theory you could adjust a couple of images and make a preset to correct your images, but every image is different and each has it's own needs for color adjustment. contrast, saturation, etc.

All this is typically done one time in profoto color space (melissal rgb) from lightroom, or Adobe1998rgb from Photoshop or Capture1, and then converted on the fly by the software using LAB standards to srgb when posting to web, or some icc profile when printing to a printer. Color management is about having acceptable output amongst varying devices..but if it is stripped or some unknown we dont stand a chance and its shooting in the dark with each image and a lot of trial and error. Usually so much time is already invested in an images rendering to have to guess at all this again for a web app is just too much additional work.

Web is notorious for not being able to color manage because you can never know what people are looking at your image on, old monitors, mac, pc, brands, projectors etc...but with that said, Adobe srgb is the standard used for web color space. The gamut shifts a bit from 1998rgb to srgb, but not the dramatic shift we are seeing here. My guess is that there is no conversion happening and that the color space is stripped from the metadata along with the exif/iptc data. Both are evil from a photographers perspective, you need your images to look pretty close to your intent and you need your metadata embedded for © and contact info. Deeplinking is pretty important as well so people can link to a particular image within a gallery and send it around. Too invested for the time being with index to switch to another platform, and hope that the color issues get sorted on server side. Sooner or later I will need a more optimal solution, sadly as otherwise index 2 meets all my needs..but stripping metadata and color space is a huge issue for photographers which is a large part of your client base I would think. Thanks for all.

We're moving Imagick to the front of the stack of work - I hope we start working on it tomorrow and that it does the trick. But, not all hosts have it...

That's great news for us photographers, Vaska. Thanks for your continued efforts.

thanks a millllllion! you rock! keep us posted. Hope it solves the issue.

For the folks who have been posting in this thread - check with your host and see if they have Imagick installed on the server. It will be critical to making this work for you...

We started working on this today - I hope to have something we can all try out within the next week...

Vaska:
Feel free to delete that long post..unless you think it might be helpful to others. I just wanted to give you the info.

I appreciate your efforts.

People don't need that info...apparently that's old and it's installed for command line execution (which is how it works on most hosts that have it).

so...it should "just work" with dream host? or will I have some mucking around to do?
I barely know what I am up to with web related info..which is why I like index and dreamhost, hard enough to make me learn, not so hard I can not sort out ...eventually.