ProfHankD

ProfHankD

Lives in United States Lexington, United States
Works as a Professor
Has a website at http://aggregate.org/hankd/
Joined on Mar 27, 2008
About me:

Plan: to change the way people think about and use cameras by taking advantage of cameras as computing systems; engineering camera systems to provide new abilities and improved quality.

Comments

Total: 1046, showing: 141 – 160
« First‹ Previous678910Next ›Last »
In reply to:

eno2: Very nice, thank you for the test!

I agree with everything you said except the part about the "more sophisticated" Sony JPEG engine:
"When it comes to JPEG, Nikon (and Canon, for that matter) have some work to do with respect to optimally balancing sharpening and noise reduction in JPEG, as detail in the Raw is left on the table at both low and high ISO sensitivities compared to Sony's more sophisticated engine."

I strongly believe the Sony JPEG engine is one of the worst there is out there! Full of ugly looking artifacts (from a bad NR + sharpening) and terrible colors.

I think Sony was actually ahead on JPEGs for quite a while before they obviously looked better. The catch is that they favored getting a high dynamic range first, and that increased visible noise; now, their sensors have very low noise and they are remarkably good at reducing noise further in the JPEG engine. Sony sharpening might be a little overly aggressive, but it doesn't produce artifacts -- just sometimes synthesizes detail where it wasn't. ;-)

Link | Posted on Mar 28, 2016 at 18:42 UTC
On challenge ND, or not too ND? (6 comments in total)

Well, at least there are two entries....

I guess this goes on to my short list of things to really test for a research paper to Electronic Imaging 2017.... ;-)

Link | Posted on Mar 24, 2016 at 01:58 UTC as 2nd comment
On challenge ND, or not too ND? (6 comments in total)

I'm disappointed that you're the only one who has submitted so far, but yours is a nice entry. This is one of those tricks I thought people would really appreciate, but maybe not so much? ;-)

Link | Posted on Mar 22, 2016 at 04:28 UTC as 4th comment | 1 reply
In reply to:

Revl: Hi Everyone. Thank you for your questions and concerns. We have made a new video to answer all of your questions.

https://youtu.be/wVd941tLPIg

steve ohlhaber has the right idea. Most footage shot from a GoPro without a stabilizer is pretty useless.

We stabilize all of your video in real time BEFORE it is recorded to the SD card.
No post Stabilization required!

Just trying to get some facts straight. Cheers!

Ok. So 1 motor rotational control + sensor-data-driven "electronic image stabilization" implemented by computation in the video pipeline. Sounds reasonable... without rotation, it's basically parametric lens distortion processing using the sensor data to tweak the parameters, right? Good trick.

Link | Posted on Mar 20, 2016 at 15:18 UTC
On article Adobe Camera Raw 9.5 introduces new color scheme (127 comments in total)
In reply to:

matthew saville: Haha... For a fraction of a second, I thought that "color scheme" might possibly be some sort of new processing profile that better matched my in-camera colors, but no. They changed the *skin* of the ACR interface. Yay.

>> What specifically isn't native raw sensor data?

The color basis function and CFA pattern, dark reference, pixel aspect ratio, DNG data format specifiers, etc. There's a lot of EXIF info needed to decode a DNG. There's even more potentially useful, from shutter speed to battery temperature, face-ID regions, etc. Take a look at EXIFTool to see what a mess this stuff is....

The problem for DNGs is that there are lots of alternative fields with slightly different ways to say the same things, and various DNG-processing tools assume they come in specific (proprietary/undocumented) groups. ADC does a good job of copying a lot of EXIF data into all potentially-relevant fields (e.g., it copies the "Shutter Speed" field into the "Shutter Speed Value" field), but things like color info get encoded very differently and the original fields are not passed-through. Some are changed a little: e.g., "Blue Balance" was 1.5 and became 1.496094? Maybe that's how some pixel VALUES change too?

Link | Posted on Mar 18, 2016 at 21:21 UTC
On article Adobe Camera Raw 9.5 introduces new color scheme (127 comments in total)
In reply to:

matthew saville: Haha... For a fraction of a second, I thought that "color scheme" might possibly be some sort of new processing profile that better matched my in-camera colors, but no. They changed the *skin* of the ACR interface. Yay.

>> All that is necessary is the actual/all raw sensor data, NOT proprietary metadata. DNG provides exactly that sensor data.

Again, DNG can, but Adobe DNG Converter generally provides only the info Adobe wants and in the format Adobe wants it. If Adobe DNG Converter did preserve everything, it would be trivial for the native-raw-to-DNG transformation to be reversible: Adobe very clearly states it isn't.

To reliably see pixel value differences, you need to look directly at the numerical pixel data in the files. I used C code implementing the logic from dcraw to walk the data structures (that's how KARWY makes repairs). Alternatively, run both original raw and ADC uncompressed output through 16-bit dcraw -E. At least for various Sony cameras, the data doesn't match... and Adobe Photoshop used dcraw as a reference, so guess which I trust to be right? ;-)

Link | Posted on Mar 18, 2016 at 20:15 UTC
On article Adobe Camera Raw 9.5 introduces new color scheme (127 comments in total)
In reply to:

matthew saville: Haha... For a fraction of a second, I thought that "color scheme" might possibly be some sort of new processing profile that better matched my in-camera colors, but no. They changed the *skin* of the ACR interface. Yay.

Digidog: Last year, I posted on this because KARWY needed lossless raw format in which to express the computationally-repaired ARW raw, and I used DNG for that. I also discuss this in my published research paper on KARWY, which I presented at IS&T Electronic Imaging 2016. Basically, Adobe DNG Converter is really just a proprietary preprocessor to extract the info Adobe wants from raw images -- it is not improving portability, etc. In fact, the way to truly improve portability would be open source release of the conversion algorithms... which Adobe has not done.

The only way that Adobe DNG Converter preserves the original raw data is if you literally embed the original raw... which makes conversion to DNG rather pointless.

As for the pixel VALUES (not just dimensions) being wrong, they simply are, but never by a huge amount. It's anybody's guess as to why. My guess is still some bad math or colorspace normalization (e.g., compensation for black point).

Link | Posted on Mar 18, 2016 at 18:57 UTC
On article Adobe Camera Raw 9.5 introduces new color scheme (127 comments in total)
In reply to:

matthew saville: Haha... For a fraction of a second, I thought that "color scheme" might possibly be some sort of new processing profile that better matched my in-camera colors, but no. They changed the *skin* of the ACR interface. Yay.

PS: The wrong pixel values are probably the result of either slightly wrong math (roundoff?) or applying some (minor) colorspace transformation as described in that pile of proprietary color EXIF data Adobe DNG Converter adds.

Link | Posted on Mar 18, 2016 at 18:13 UTC
On article Adobe Camera Raw 9.5 introduces new color scheme (127 comments in total)
In reply to:

matthew saville: Haha... For a fraction of a second, I thought that "color scheme" might possibly be some sort of new processing profile that better matched my in-camera colors, but no. They changed the *skin* of the ACR interface. Yay.

Digidog: Adobe DNG Converter is supposedly producing a fully raw DNG in the cases I tested, but it's not. As for the pixel dimension errors, basically they pad/clip to I believe it's a multiple of 8. When they pad, they add random garbage values; when they clip (as for the A99), they remove black reference pixels. Now it turns out that Sony provides a black reference value, so you can convert without seeing the black reference pixels, but you can actually get a better noise estimate from looking at those pixels, so they are useful. Basically, Adobe left them out because ADOBE DOESN"T USE THEM.

In sum, native raws may have vendor-specific stuff in them, but Adobe DNG Converter basically makes proprietary-and-specific-to-Adobe decisions about how to encode a DNG from them, so you end up with something even more fragile than the original. So, you end-up with files that only Adobe fully understands, thus making it painful to switch to image postprocessing software not made by Adobe.

Link | Posted on Mar 18, 2016 at 18:03 UTC
On article Adobe Camera Raw 9.5 introduces new color scheme (127 comments in total)
In reply to:

matthew saville: Haha... For a fraction of a second, I thought that "color scheme" might possibly be some sort of new processing profile that better matched my in-camera colors, but no. They changed the *skin* of the ACR interface. Yay.

digidog: It has nothing to do with "settings" -- I'm talking about the uncompressed DNG created by Adobe DNG Converter, not any postprocessing of it. The converter not only changes the pixel values for some cameras, but actually pretends to have more/fewer pixels for some cameras -- for example, the Sony A99 ARW has 6048x4024 pixels, but the Adobe DNG Converter makes an uncompressed DNG with data for just 6032x4024 pixels. Adobe also does very mysterious things to the color EXIF data.

Just to be clear, the DNG spec does allow the camera raw data to be kept intact -- that's just not what Adobe does when they convert. Their postprocessing also fails to produce reasonable output from standard-compliant DNGs that don't represent the color EXIF the same (proprietary) way that Adobe DNG Converter does it.

Link | Posted on Mar 18, 2016 at 17:39 UTC

Some of that has the camera responding VERY quickly with VERY large-scale movements... not sure how you do that (and that is the kind of thing I have some experience with). Pretty sure that, even with wifi off, you can't be doing that and record 90 minutes of 4K video on any battery that would fit in there.... However, it's a crowdfunding thing; they always aim high and sometimes figure out how to do it. ;-)

(PS: the "electronic image stabilization" is probably the answer, because there is tech that can pretty much take regular video and straighten it in post.)

Link | Posted on Mar 18, 2016 at 11:55 UTC as 7th comment
On article Adobe Camera Raw 9.5 introduces new color scheme (127 comments in total)
In reply to:

matthew saville: Haha... For a fraction of a second, I thought that "color scheme" might possibly be some sort of new processing profile that better matched my in-camera colors, but no. They changed the *skin* of the ACR interface. Yay.

I also was worried that they had instituted yet another proprietary and undocumented change to the supposedly open DNG standard. They do odd things to the color EXIF data in DNG Converter....

For that matter, I'd be much more impressed if they'd just make DNG Converter actually preserve the raw image data. As I discovered last Fall, for some cameras, uncompressed DNGs produced by DNG Converter not only fail to preserve raw pixel values, but actually change the number of raw pixels recorded.

Link | Posted on Mar 18, 2016 at 05:19 UTC
In reply to:

edgy12: No lossless raw for a7 or a6000?

Sony compression leaves the data random access, which none of the other high-quality compression methods do. That is potentially a huge benefit. They also get significantly higher compression than most with fewer artifacts (and the word "lossless" shouldn't be taken too literally -- even Adobe's uncompressed DNGs happen to actually be very lossy!). The problem is that Sony sensors have gotten so good that they need more bits/pixel, but the happy alignments in the compressed form break if they add even 1 bit/pixel.

Sony's new 16-bit uncompressed format (as opposed to their old 12-bit uncompressed format) seems a really smart step up. It keeps the random access and happy alignments; basically, it goes from 1 byte/pixel to 2 bytes/pixel. The catch is that they don't have 16 bit pixel data in their mainstream sensors yet... but the sensor chip architectures are probably there within a generation or two, and 16 bits/pixel would work now for things like raw stacking.

Link | Posted on Mar 17, 2016 at 11:11 UTC
In reply to:

edgy12: No lossless raw for a7 or a6000?

badi: Artifacts are rarely significant (even on the A7RII, but especially on lesser sensors, such as in the A6000 or A7) and the compressed file size is basically always 1/2 that of the uncompressed files. For scientific purposes, I fully agree that uncompressed raw is preferable, but the truth is that the awkwardness in using KARWY to credibly repair the rare visible artifact is probably more than compensated by the faster handling of compressed files throughout the normal workflow. After all, it generally takes custom (extreme) postprocessing to see artifacts anyway, so by definition you're only fixing shots that required a lot more manual handling than your normal workflow.

That said, as Sony sensors continue to improve, this particular lossy compression algorithm basically becomes more lossy. The A7RII may be the first sensor good enough to have artifacts visible with any frequency, but I'm sure uncompressed raw will be more important in future models that have better sensors.

Link | Posted on Mar 17, 2016 at 04:22 UTC
In reply to:

ProfHankD: These are not the updates you're looking for....

CHDK doesn't generally do any of that, but using CHDK I implemented variable-aperture STF emulation on a PowerShot A640. Here's a slide from my 2009 IP disclosure:
http://aggregate.org/DIT/apotest20090814.png

Note that there is some artifacting because the stopped-down iris shape is hexagonal, not circular, but the method is really quite effective. Incidentally, Minolta explicitly stated that variable-aperture STF emulation (as in the Maxxum 7) did not apply to digital cameras, which is why I thought my digital-camera version might be patentable IP. The University of Kentucky agreed, but never followed through on the patent....

Link | Posted on Mar 16, 2016 at 22:13 UTC
In reply to:

Shinsei: Hasselblad should be cutting cost of the digitalback, rather than reduction of the lens price.

No, I wasn't making fun of you... $10K is as cheap as backs get. However, for the record, a back should not cost more than a camera using the same sensor. Put more directly: I bet the backs cost less to make despite selling for more.

BTW, I often explain E mount bodies to pros as "just think of them as digital film backs for all your lenses." The thing that makes the Pentax awkward for that is the long flange distance required by the flipping mirror, and the CCDs used in most backs mean they have no viewfinder by themselves. Of course, the 50MP Sony sensor is a bit of a game changer in supporting live view and even video -- arguably, a back with live view IS a mirrorless body. :-)

Link | Posted on Mar 16, 2016 at 16:34 UTC
In reply to:

Shinsei: Hasselblad should be cutting cost of the digitalback, rather than reduction of the lens price.

Wow! You're right! At $10K, the CFV-50c is the cheapest medium-format back at B&H! Then again, the Pentax 645Z -- the whole camera, not just a back -- with the same sensor is only $7K. I think I'll stick with my Sony E bodies for now. :-)

Link | Posted on Mar 16, 2016 at 15:50 UTC
In reply to:

ProfHankD: These are not the updates you're looking for....

I'm just waiting for either (1) Sony to announce that their app interface is open to friendly developers or (2) the ongoing camera app hack project to get a little more developed. I actually implemented STF emulation using CHDK on a Canon PowerShot many years ago (back when most PowerShots still had controllable apertures).

Link | Posted on Mar 16, 2016 at 12:59 UTC
In reply to:

scrup: must be a slow day in the newsroom

I think you mean the downward trend of Hasselblad. ;-)

This is a company still looking for what their future might be. I don't think a 15% price drop, temporary or permanent, is the answer. Let's hope the price drop isn't a precursor to a new line of lenses being released that are the same lenses, but with custom hardwood grips. ;-)

Link | Posted on Mar 16, 2016 at 11:00 UTC
In reply to:

edgy12: No lossless raw for a7 or a6000?

There's always my free tool, KARWY, to credibly repair the (rarely important) compression artifacts: http://aggregate.org/DIT/KARWY/

Here are the slides from my IS&T Electronic Imaging paper on the compression and artifact repair:
http://aggregate.org/DIT/EI2016/ei2016ARW.pdf

Link | Posted on Mar 16, 2016 at 02:18 UTC
Total: 1046, showing: 141 – 160
« First‹ Previous678910Next ›Last »