July 30, 2014, 05:28:07 AM

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - jrista

Pages: 1 ... 74 75 [76] 77 78 ... 250
1126
Beautiful shots, Canuck! Love the alpenglow...such an amazing natural effect. The 6D is an awesome landscape camera, especially with that Voigtlander 20mm.

1127
Canon General / Re: Why Scott Kelby Switched to Canon
« on: January 20, 2014, 05:43:50 PM »
He sounded somewhat believable until he started going on about the amazing high ISO performance. I mean yeah the 1DX high ISO is very good.... BUT so is the D4 that he has! The 1DX high ISO is no better at all than his D4 and the 5D3 high ISO is worse than the D4 high ISO (although the extra MP on the 5D3 helps a bit in some ways). And failed to mention one thing he'd bring over from Nikon other than the shutter feel.... the dynamic range difference at low ISO where the Nikon actually is much better. So then you start thinking about all the money dangling above his head again.

I do like Canon's UI a lot better myself though.


Based on DXO tests (i.e. "on paper"), no, the 1D X high ISO is theoretically the same as the D4. However, from a visual standpoint, I've seen ISO 16000 images and even some ISO 51200 sports images from a 1D X that simply blow me away...similar images from the D4 just don't engender the same feeling of low noise and clean quality. The D4 also actually tops out at native ISO 12800, beyond which you can only select full stops with "expanded" modes. ISOs above 12800 on the D4 (and pretty much any other Nikon camera that supports expanded ISO above 12800) feel a bit "gritty." The 1D X offers full native third-stop ISO capability right up to ISO 51200, and its third stops are very clean. You have the option of using the cleanest ISO options above 12800 with the 1D X, where as you can only use 25600 (H1), 51200 (H2), 102400 (H3), and 204800 (H4) on the D4...that is a factor that cannot be overlooked, as you can always use say ISO 16000 or ISO 20000 instead of 25600 when you need more than 12800, and get lower noise results. (Same goes for ISO 3200 and 40000.)

From what I can tell, the D4 suffers a little higher chroma noise (which isn't surprising, since its expanded ISOs are a digital push of ISO 12800...read noise is getting amplified). The 1D X has lower chroma noise up through ISO 51200 (particularly in the blacks...chroma noise in the lower tones on the 1D X is very good, but it is quite visible on the D4. See here for an example: http://www.cameraegg.org/canon-eos-1d-x-vs-nikon-d4-high-iso-test/). Luma noise is easy to clean up, where as cleaning excessive color noise can leave a bit of blotchiness behind. I've seen a number of bird photos from ISO 16000 and on taken with the 1D X, including a few ISO 51200 shots (couple shots of some geese...they were amazing, if I can find the link). The results have always been astonishing, very clean, crisp, good color fidelity.

Here are some more examples of the 1D X edge at high ISO:

http://thenewcamera.com/canon-1dx-vs-nikon-d4-high-iso-war/


Artificial tests don't tell you everything. On paper, the two cameras might as well be identical. In practice, chroma noise at higher ISO settings on the D4 start eating away at detail in the shadows, where as chroma noise is quite low in the shadows with the 1D X. As a result, high ISO photos taken with the 1D X are remarkably clean and usable. An excellent example would be the NY Manhatten Island photo taken with a 1D X at ISO 25600 at night during Hurricane Sandy:


(See large version for best example of the noise quality here: http://thenypost.files.wordpress.com/2013/10/magsandy.jpg)

I'm still waiting to see a comparable photo like this taken with a D4. I just don't think it would have performed as well...not with it's chroma noise.

1128
The x is the in every long exposure. It is not me marking the spot. It's a cluster of dodgy pixels. I did not repeatedly ignore requests. I just didn't have the camera or images to hand. I am telling the truth when I said that amazon had no problems  in sending me 4 bodies. Do you doubt me? And if so, why? Canon have advised that I send them the body with faulty pixels. I have had 4 with faulty pixels.

Your attitude towards me is curious. I came here for help and instead got silenced.........
It seems that its not just me though, a quick google search revealed other silenced would be contributors to your forum.

I can't understand you having an open forum if you feel the need to berate and silence contributors.
 >:(

I see your using an iPad app of some kind, and I'm wondering if that may be part of the problem. It would be highly unusual for multiple cameras to exhibit the exact same problem like that, exceptionally unusual, so there is probably another explanation.  An x is an unusual formation. I'd be curious to see how the image renders if you used ACR+PS or LR.

BTW, I wasn't trying to get your thread shut down. Visual evidence, and a more active feedback loop with you actually providing some visual information and possibly trying some of our recommendations would have been far more conducive to solving your problem. And, sorry to be HONEST, but yeah, I think returning your camera FOUR times in a row over a tiny area of pixels is a little extreme. To be quite frank, I don't really believe it, but again...further investigation, with you providing visual information along the way, would have helped us zero in on the problem and solve it without requiring multiple returns and all that wasted time or money.

As for paranoid...your the one who claims you returned multiple cameras on a dime after freaking out over a small cluster of hot pixels (something ridiculously easy to map out and permanently eliminate)...and on an iPad app, of all things. Just sayin...  :P ::)

1129
Canon General / Re: Why Scott Kelby Switched to Canon
« on: January 20, 2014, 02:41:56 PM »
Quote
Switching for ergonomics is a weird one to me. After a few months with a camera, you’re used to it and it becomes second nature. I personally fumble around with Nikon’s pro bodies, but that’s because I have been shooting Canon predominantly for a long time. Had I always shot Nikon, I’m sure the opposite would be true.

I'm not so sure about that. While yes, you can get used to any control layout, there is something about Canon's control layout (buttons and dials) that just works better. The only complaint I've had about Canon's button layout is the DOF preview button on my 7D, however that's been fixed with newer DSLR bodies (it's now in the PERFECT place.) When it comes to controlling all the critical settings without ever taking your eye from the viewfinder, Canon 's button layout trounces Nikon's. I can change just about everything without taking my eye from the viewfinder, and without moving my fingers very far from the shutter button. The mechanism by which you switch modes to change things like ISO, flash compensation, AF point selection, etc. is so simple it becomes a procedural memory thing. You can fly through settings changes while your still tracking a subject in motion, and get back to shooting in a heartbeat. That isn't just because you know the system...it's the specific layout. Canon NAILED it. Nikon...they get some things right, and some things wrong (and some VERY wrong.)

This isn't the first time I've heard a Nikon shooter rave about Canon ergonomics. There is something about it that is indeed superior.

1130
Software & Accessories / Re: Adobe Lightroom for iPad Coming Soon
« on: January 20, 2014, 02:25:35 PM »
You may have missed they are already there. Just, they don't run iOS or Android, but Windows 8. You can easily find tablets with Intel i5 or even i7 processors, the same you find in your laptop, and with 8GB of memory, enough to run Lightroom fully. Just avoid the cheap Atom/2GB ones - of course they are not up to the task.
The only limits (beyond price) may be how long a battery charge last,  the screen size (although 12"-13" tablets are coming also), the gamut of the screen itself, but they are not worse than the average laptop (and often better, given most Windows tablets have higher resolutions than many laptops). But when needed you can also connect them to an external monitor and work there.
Windows 8 on tablets may be still a work in progress as a pure consumer tablet OS, but if you need to work also with applications like Lightroom, it's there and it works.
No I haven't missed .. I have tried the Samsung & Sony versions and did not like them much ... when it comes to size vs performance, the tablets are not really there yet ... if they have enough power they tend to be heavy, if are light they tend not to have enough power for software like Lightroom/PS ... for me the ideal weight is the iPad, when the processing power in a an iPad (or similarly sized/weight android or windows tablet) allows me to work with a full featured LR/PS then I will consider that being "have arrived", till then they are not "already there".

You need to give Surface Pro a try. Microsoft did a damn good job on their first tablet, and the Pro 2 seems to be better...little bit lighter, MUCH longer battery life, etc. The screen is great, very high density, although I have not yet tried to calibrate it. It is slightly heavier than an iPad, but it is WAY lighter than even the smallest laptop. Complaining about the weight of something like a Surface Pro is like complaining that your highly fuel efficient hybrid car isn't as efficient as the entirely electric car your neighbor got...the electric car that can't actually climb hills at faster than five mph, and requires you do periodically dump highly toxic car batteries into the environment when they end up needing to be replaced (i.e. not so environmentally friendly in the long run). The hybrid is still vastly superior in terms of efficiency than your previous car, and given the fact that it can still RACE up hills, it was a damn good buy!

1131
This is one example at 100%. The other problem pixels were red or blue.
Thanks for killing my first thread btw. This will be my last.
Cheers for all the genuine help ;)

You were repeatedly asked for sample images, not just from me, and you kept ignoring it. When someone repeatedly refuses to provide visual evidence when asked, you can't help but get suspicious.

As for the image below, is it safe to assume that the X marks the spot where a hot pixel might be? If all you have is ONE hot pixel, you have absolutely nothing to complain about. Your image is a hell of a lot cleaner than most are during long exposures, as most result in dozens of hot pixels across the frame, of a whole variety of colors. Even if the entire x is "hot", that is incredibly easy to correct, and even permanently clean with the camera itself by mapping dust and spots. I don't think you have a problem...hot pixels are a fact of life with digital sensors at high ISO and/or long exposure.

I also encourage you to use Adobe Lightroom to process the RAW. LR deals with hot pixels very well...it is entirely possible the problem you are experiencing will simply disappear when demosaiced with LR.

1132
EOS Bodies / Re: Will Canon ditch the AA Filter?
« on: January 20, 2014, 02:04:50 PM »
They never mentioned any specific changes to ACR that would cause those changes, but they were clearly there.

As far as I read it, they don't *any* information on this, specific or not - after "camera xyz supported" that's that, they only mention improvemtents in the user front end like more denoising options.

They do have more details than simply what cameras are supported at times. You might need to dig deeper for that info. A good blog to read is Julieanne Kost's blog. There is some good info there every so often. It's been years since LR4 was released, so it would take some digging to find the useful tidbits about ACR on any Adobe site, blog or not...but there usually are tidbits of information.

1133
if i remember correctly firefox is the only browser that really does icc


It was the first. At the moment, it appears that all major browsers now support ICM. This is a handy little test site:

http://photographylife.com/is-your-browser-color-managed

Both photos look identical in IE 11, FF, Chrome, and Opera. Seems all of them are color managed. I think the big difference is the v2 vs. v4 support...as far as I can tell, only IE does v4 ICC support. And, for some reason, Chromium seems to render my ProPhotoRGB images desaturated (which means it isn't being properly converted via ICM), however I am not sure if those images are tagged with a v4 ICC profile or v2.

1134
EOS Bodies / Re: Will Canon ditch the AA Filter?
« on: January 20, 2014, 02:18:33 AM »
The quality with which LR renders my 7D images only seems to get better and better with time and each subsequent version, so as Adobe optimizes their demosaicing implementation, any inherent error is clearly diminishing.

Thanks again for all your great posts on this! The problem with Adobe is that they seem to be very secretive about any improvements concerning ACR or LR, their official changlog only reflects a small part of the changes ... or is there any Adobe or 3rd party documentation on their raw converter improvements over time?

There isn't any official information. I wouldn't expect any, either. The minutia of the algorithmic details of Adobe's demosaicing algorithm would bore most people, and would probably be incomprehensible to anyone who didn't have a math or comp. sci. degree. The specifics aren't all that important. All I do know is that LR5, compared to LR3, produces clearer, sharper results...so Adobe certainly seems to be optimizing their algorithms. Optimization over the long term is to be expected. Demosaicing is the heart of what ACR and LR do...it is going to be the single biggest processing cost when rendering RAW images to screen (since every time you change a setting, they have to rerender, and that can be many times per second.)

I also remember a fairly significant jump in overall quality, edge definition, and sharpness between LR3 and 4. In LR3, sharp edges, hairs, bird feather barbs, etc. looked more like DPP (which as you can see clearly has a less effective algorithm, as it intrinsically blurs more, yet still produces stair-stepping.) LR4 produces really crisp, clean, smooth edges, without blurring. They never mentioned any specific changes to ACR that would cause those changes, but they were clearly there. I don't really care that Adobe keeps the specifics under wrap...sometimes it isn't a good idea to expose too many details about one's technology, as it can invite too many questions for customers when a customer decides something they are seeing in their results doesn't jive with what the company is saying about their algorithms.

1135
EOS Bodies / Re: Will Canon ditch the AA Filter?
« on: January 20, 2014, 01:38:44 AM »
Removal of an AA filter is far from a high end feature. It is a gimmick for all but a very few niche photographer types who's work primarily involves photographing things with entirely random data that could not produce much aliasing regardless. For the vast majority of photographers, use of an AA filter is quite essential to producing BETTER image quality. Aliasing produces nonsense, noise, useless detail. ANTI-Aliasing restores that useless nonsense noise to a more accurate form.


On this I 100% agree with you though.

One side note, the Canon 7D isn't maybe the best body to use (I mean not in the equipment sense and taking pictures but in the testbed to compare detail vs other cameras in a lab sort of sense), since it has those heavily split greens in the CFA array so the de-mosaic routines have to do very tricky things which tend to leave a bit of residual loss of micro-contrast behind (it's actually surprising that they manage to not leave behind major resolution loss, they must be doing some pretty sneaky stuff to handle the split greens and preventing mazing artifacts while not hitting the resolution but a trace).


What do you mean by "heavily split greens"? The 7D has a pretty standard bayer sensor as far as I know...they shouldn't need to do any special processing (and ACR/LR seem to handle 7D files just fine with their AHDD algorithm.)


You know how they use two greens for each red and blue so you have a G1 R G2 B well with the 7D they decided to make G1 very much not the same as G2. It seemed like they wanted to sneak just a little bit more light to the sensor by making one the greens even yet more color blind.

If you developed 7D files right when it first came out with ACR (or even DPP!) you'd notice also sorts of maze patterns appearing. It was especially bad, if I recall correctly, in orangey-yellow blocks of color. Some of were like what the heck is with the artifacts in these 7D images and then we were noticing weird things where measuring the SNR of the G1 channels in the RAW data always gave different results than measuring on the G2 channels.

A few of us brought the complaints to the converter makers and Canon's attention and some even returned their initial 7D copies thinking that maybe that had the Bayer array somehow misaligned or something. Then a few weeks later Adobe released a new ACR and I think shortly after that a new DPP came out. The early speculation would be that getting around the split greens would cause major loss of resolution or noticeably remaining artifacts, but somehow the converter makers found a way to pretty much solve all the mazing artifacts while only barely hitting the resolution at all (if you still had the early ACR beta that supported the 7D and process a file with it, you can get a touch more micro-contrast out of it with 7D files than using the later fixed beta and final releases). It's hard to say but it seemed like the fix maybe effectively knocked 1-2MP MP off the 18MP sensor, not really a big deal, perhaps it made the files a bit more filmlike looking.

And you can see references by Adobe to split green parameters in ACR. It's not just the 7D that needs them but a few other cameras as well from some of the smaller players in the digital camera world. I think Canon is not splitting the greens so much again and I;m not sure if Nikon ever did (i'm pretty unsure about this last stuff though).

If you didn't buy a 7D within the first 2-3 weeks of their very first arrival in the U.S. you probably missed the whole mazing thing with ACR (and maybe 3-4 weeks for DPP and the others).


Hmm. I can't imagine that such a thing is a huge problem. It's not all that different from Sony's "Emerald Green" CFA that they introduced many years ago (they called it RGBE). Their "Emerald" had more blue in it than the standard green. Based on all the sample images at the time, it actually produced better color accuracy...but it would be the exact same thing as your describing with the 7D.

There have been similar approaches in the past by other companies as well. Some simply do away with the second green and make it a "white". Fuji threw in an extra tiny little white pixel between all the primaries that were very widely spaced, but gathered extra luminance data. If what you say is correct, that would have caused even more problems for demosaicing, however it improved resolution a bit, and improved DR (although the DR improvement seemed minor, especially compared to what Sony did with Exmor.) Kodak, Sony, and Fuji all now have RGBW sensor designs, and Sony is even starting to patent non-square pixels (they have patents for triangular and hexagonal pixels now, and supposedly one of these pixel designs is going to be used in their forthcoming 54mp FF sensor.)

I also can't imagine that it would cause a loss in resolution. I mean, the crux of any bayer demosaicing algorithm is interpolating the intersections between every (overlapping) set of 2x2 pixels. Because there is reuse of sensor pixels for multiple output pixels, there is an inherent blur radius. But it is extremely small, and it wouldn't grow or shrink if one of the pixel colors changed. You would still be interpolating the same basic amount of information within the same radius. I remember there being a small improvement in resolution with my 7D between LR 3 and 4, and things seem a bit crisper again moving from LR 4 to 5. I suspect any supposed loss in resolution with the 7D was due to the novelty of Adobe's implementation of support for the 7D, not anything related to having two slightly different colors for the green pixels. The quality with which LR renders my 7D images only seems to get better and better with time and each subsequent version, so as Adobe optimizes their demosaicing implementation, any inherent error is clearly diminishing.

BTW, there is no way anything Adobe has ever done that could possibly "knock off 1-2mp worth of resolution" from the 7D. The most basic demosaicing algorithm will produce noisy, mazed and stair-stepped results. Better demosaicing algorithms factor in more information from a greater area of pixels as necessary (i.e. in order to avoid maze artifacts), however the amount of blur they introduce is fractional...not even close to diminishing resolution by another two megapixels over the bayer design itself. You can clearly see this when comparing DPP to ACR/LR with something like a strand of hair. DPP will produce a fairly jagged result, ACR/LR produce a very clean result. Based on the sample below, ACR is actually sharper and supports even finer detail resolution:



Additionally, the output resolution of my 7D + EF 600/4 L II is WAY, WAY, WAY better 7D + 100-400 @ 400. The difference that a good lens makes with the 7D's resolving power would completely overwhelm any perceived difference that the ACR/LR demosaicing algorithm makes. That's entirely in line with theory as well, as output resolution is approximated by the RMS of the resolutions of each component. With the 600/4 II, the 7D produces exceptionally sharp results, and is able to very finely delineate detail with a good lens that otherwise appears quite soft with the likes of the 100-400 L, 300/4 L, 70-200 L, etc. I mean, just look at the detail resolved on these birds (all 7D, all of which are processed with Lightroom):






1136
Is it normal for an image's colors to appear slightly different, on the same calibrated system, across what appear to be color-managed (or at least ICC-aware) browsers? (I'm in Windows 7, 64-bit.)

I've attached a cropped screen shot of how IE11 and Firefox 26 render an ICC-tagged test image that I found in another forum on this site.

Both browsers correctly show a yellow car, so as I understand the issue the browsers are ICC-aware (if they weren't the cars would appear purple, as I've demonstrated to myself in some non-color managed apps I've got.) But Firefox (and Chrome, it turns out) introduce a warm cast.

Is this just how it is? Or am I missing some variable in the color management / ICC chain?

Thanks.

Absolutely. IE is NOT fully color-managed (it simply converts any image tagged as wide gamut to sRGB and that's the extent of it's management, and that actually makes things worse if you were running it on a monitor in wide gamut mode so the wide gamut images may have looked at least vaguely correct before it turned them into sRGB). Firefox is color-managed and if you use the plug-in to turn it on 100% it will even color-manage the text and background colors, every single last element on a webpage.

IE does not make any use of the monitor profile at all. So if you have an sRGB image but your monitor is set to gamma 2.2 it won't translate from sRGB tone curve to gamma 2.2 and you'll get shadows that look a bit too contrasty and dark as well as slight mistakes in the highlights. Also if the primaries on your monitor are not exactly set to sRGB coordinates it won't apply the needed transformations for that and if your profile is a complex LUT table to try to fix some of the color issues with your monitor it won't use those either.

Firefox will do all of that.

Chrome does nothing ever.

(actually i haven't tested the very latest IE that just came out, but I thought I've heard that it is the same old story, more or less not color-managed)

I'm not sure that Chrome does nothing. At least, Chromium as used in Opera, based on some tests I just ran a short while ago, seems to do color management. Firefox doesn't support the ICC test, however it does seem to properly render photos with AdobeRGB.

Seems like browser color management is a quirky scenario. Only IE supports the ICC test, however all browsers seem to do some kind of ICM on some images. Opera/Chromium, for example, doesn't seem to handle ProPhotoRGB images for whatever reason (they show up rather desaturated.)

Really wish this issue would be delt with. The major operating systems offer built-in color management engines. Browsers wouldn't have to implement them on their own, they would just need to hook into the OS ICM and let it do it's thing. Sounds rather simple, if you ask me...

IE passes the ICC test because it understands image profiles and both v2 and v4 but that ICC test only tests how browsers react to image profiles. It does nothing to tell you abut whether the browser handles monitor profiles. IE doesn't (at least not as of all versions prior to the very latest and I'm pretty sure even the latest still does not).

Firefox may fail the ICC test, but only the v4 tagged images of which there are likely only a vanishing few out there on the web but it passes everything else. It understands monitor profiles and can even handle text, backgrounds and so on, everything (well actually not Adobe Flash stuff since that renders itself and is not managed, so sadly flash based slide shows are 100% not color managed :(  ). Some browsers handle most stuff but don't handle untagged elements so all the images not tagged as sRGB (but that are sRGB) and all the web elemenets like various background colors and text colors and so on are not managed and all that stuff goes radioactive if you use those browsers on a wide gamut monitor set to wide gamut mode, even if all tagged images look perfect.

at least on Windows. MAC is different some there have been times that MAC versions of browsers have been color-managed but not Windows and even vice-versa and then in some cases the MAC itself tries to color manage which Windows never does.

The browser shouldn't "handle" monitor profiles. It isn't the browsers job, technically speaking. It's the job of the Image Color Management (ICM) engine to handle that. You have multiple profiles in play at any given time. In the case of rendering an image to the screen, you have two key profiles: The image profile and the monitor profile. The monitor profile ONLY affects things rendered to the screen. That is completely abstract from the browser, or any other ICM-aware application. It isn't the applications responsibility to deal with the monitor.

For that matter, neither is it really the application's responsibility to actually deal with the image profile. All a browser really needs to do is determine what ICC profile an image is tagged with, and render it to the screen VIA ICM. The ICM engine will then deal with any and all other devices (and their profiles) in order to spit out color-corrected values for each pixel.

In the case of a print softproofing workflow, you would technically have three profiles in play: The image, the screen, and the printer. The ICC profile assigned to an image basically calibrates the image. You can't apply a monitor profile to an image, it wouldn't make any sense. Neither can you apply a print profile to an image. Each profile only applies to the thing it was designed for. ICM will convert from the image ICC profile to the printer ICC profile, and will then in turn render that output to screen with the monitor ICC profile.

So long as a browser properly uses the OS ICM engine, it doesn't actually need to do a bloody thing, other than render via ICM with the images ICC profile (or assume sRGB if there is no profile tagged). The OS ICM engine does all the rest.

In the case of Opera/Chrome, it appears they do not support the v4 profiles like you say. That said, as far as I can tell, they do support full ICM as I've described above for v2 profiles. Is there something about IE that is different? Is there evidence that indicates it converts everything to sRGB in some sideband way first? (That doesn't seem logical to me, given that Windows has had it's own ICM for years.)

1137
Is it normal for an image's colors to appear slightly different, on the same calibrated system, across what appear to be color-managed (or at least ICC-aware) browsers? (I'm in Windows 7, 64-bit.)

I've attached a cropped screen shot of how IE11 and Firefox 26 render an ICC-tagged test image that I found in another forum on this site.

Both browsers correctly show a yellow car, so as I understand the issue the browsers are ICC-aware (if they weren't the cars would appear purple, as I've demonstrated to myself in some non-color managed apps I've got.) But Firefox (and Chrome, it turns out) introduce a warm cast.

Is this just how it is? Or am I missing some variable in the color management / ICC chain?

Thanks.

Absolutely. IE is NOT fully color-managed (it simply converts any image tagged as wide gamut to sRGB and that's the extent of it's management, and that actually makes things worse if you were running it on a monitor in wide gamut mode so the wide gamut images may have looked at least vaguely correct before it turned them into sRGB). Firefox is color-managed and if you use the plug-in to turn it on 100% it will even color-manage the text and background colors, every single last element on a webpage.

IE does not make any use of the monitor profile at all. So if you have an sRGB image but your monitor is set to gamma 2.2 it won't translate from sRGB tone curve to gamma 2.2 and you'll get shadows that look a bit too contrasty and dark as well as slight mistakes in the highlights. Also if the primaries on your monitor are not exactly set to sRGB coordinates it won't apply the needed transformations for that and if your profile is a complex LUT table to try to fix some of the color issues with your monitor it won't use those either.

Firefox will do all of that.

Chrome does nothing ever.

(actually i haven't tested the very latest IE that just came out, but I thought I've heard that it is the same old story, more or less not color-managed)

I'm not sure that Chrome does nothing. At least, Chromium as used in Opera, based on some tests I just ran a short while ago, seems to do color management. Firefox doesn't support the ICC test, however it does seem to properly render photos with AdobeRGB.

Seems like browser color management is a quirky scenario. Only IE supports the ICC test, however all browsers seem to do some kind of ICM on some images. Opera/Chromium, for example, doesn't seem to handle ProPhotoRGB images for whatever reason (they show up rather desaturated.)

Really wish this issue would be delt with. The major operating systems offer built-in color management engines. Browsers wouldn't have to implement them on their own, they would just need to hook into the OS ICM and let it do it's thing. Sounds rather simple, if you ask me...

1138
EOS Bodies / Re: Will Canon ditch the AA Filter?
« on: January 20, 2014, 12:18:09 AM »
Removal of an AA filter is far from a high end feature. It is a gimmick for all but a very few niche photographer types who's work primarily involves photographing things with entirely random data that could not produce much aliasing regardless. For the vast majority of photographers, use of an AA filter is quite essential to producing BETTER image quality. Aliasing produces nonsense, noise, useless detail. ANTI-Aliasing restores that useless nonsense noise to a more accurate form.

On this I 100% agree with you though.

One side note, the Canon 7D isn't maybe the best body to use (I mean not in the equipment sense and taking pictures but in the testbed to compare detail vs other cameras in a lab sort of sense), since it has those heavily split greens in the CFA array so the de-mosaic routines have to do very tricky things which tend to leave a bit of residual loss of micro-contrast behind (it's actually surprising that they manage to not leave behind major resolution loss, they must be doing some pretty sneaky stuff to handle the split greens and preventing mazing artifacts while not hitting the resolution but a trace).

What do you mean by "heavily split greens"? The 7D has a pretty standard bayer sensor as far as I know...they shouldn't need to do any special processing (and ACR/LR seem to handle 7D files just fine with their AHDD algorithm.)

1139
I called bull on the last topic, after Gas am claimed Amazon had exchanged four copies of the same camera four times without question, and due to the lack of any sample images to back up the claims of problematic pixels. After that, it was locked.

I still don't think the discussion here can proceed without getting some visual evidence to clearly explain what the OP is talking about. I highly suspect Gas am is complaining about the very well known, expected phenomena of hot pixels that occur during longer exposures. However, without any kind of visual evidence, it is hard to say that for sure.

So, Gas am, PLEASE...post some sample 100% crops demonstrating the problem. We can't really help you without knowing exactly what it is you are talking about.

1140
EOS Bodies / Re: Is ARRI Canon's Biggest Obstacle in Professional Cinema?
« on: January 20, 2014, 12:11:23 AM »
ARRI is not Canon's biggest obstacle. CANON is Canon's biggest obstacle. There is still a huge demand for film and Canon don't make any film cameras. it's that simple.

The future isn't film, though...and digital is rapidly gaining ground on film. Canon would have to shift resources from digital cinema to film in order to build up a product line and gain a presence...in a market that will decline in the long term. Not really a wise move. I think Canon has it right, building up a presence in digital cinema.

Pages: 1 ... 74 75 [76] 77 78 ... 250