Re: XDepth Raw: a jpeg-compatible Raw compressed format for digital cameras

On 29 Set, 21:45, Thomas Richter <t...@xxxxxxxxxxxxxxxxx> wrote:
Trellis Management wrote:
The peculiarity of our model is that we don't use Jpeg for
"previewing" as in other Raw formats.

You're likely using the JPEG as predictor - do I guess right?

Cannot comment on that either.

Moreover no other system, as far as we know, reaches that level of
compression/quality ratio we've observed with our own method.

I cannot comment that, but please beware that there are currently no
reasonable sources of 72bpp images I'm aware of, so I would be a bit
careful regarding this statement.

Uncompressed HDR images are generally 96bpp images. Especially if
computer-generated (CG, VFX etc.) you tend to have most of those bits
actually used.
The latest 3D animated movie you watched up to your favourite TV
series containing VFX of any kind was most probably originally a 96bpp
image sequence (.hdr or .exr), before being broadcasted or burnt on a
DVD, BluRay Disc etc.

As you rightfully noted, we're able to store 72bit/pixel...way more
than current hardware requires. For this reason XDepth Raw is able to
accomodate future hardware enhancements with ease.

The matter is really which market segment you are targeting at. In my
experience, the contrast range you can capture "in raw" (not speaking
about the contrast range the eye can detect once adapted to the
background luminance, which is somewhat smaller) is below 24bpp. There
is probably some need in digital sensing (not photography, though), but
this market segment depends a lot on standardized solutions for the
reasons I already pointed out.

See above.
Moreover, current cameras can capture up to 3 stops (i.e. 2^3 times
more light than Low Dynamic Range pictures).
If you use 24bpp precision across all the exposures within the 3 stops
range you're mathematically bound to notice "banding" artifacts. (i.e.
lack of precision)
Normally in LDR images you have 2^8 bits/component within range 0 -
1.0, i.e. you normally have 256 values for each channel. As you can
imagine it's not ok saying that you can use the same precision in a
range 0 - 8.0, i.e. eight orders of magnitude higher. In order to
*maintain constant precision* within this augmented range - although
not fully HDR but MediumDR - you'd need 256*8 values for each pixel,
i.e. 2048, that is 11bit/component or 33bpp in RGB.
I'm sure you'd want to revise your statement about contrast range and
precision.
Dynamic contrast isn't considered in still HDR imaging (what you refer
to as "...contrast range once the eye adapts to the background
luminance"). That's a more appropriate subject for LCD displays
instead.

Please have a look at the following article on the topic, specifically
about MDR for current digital cameras and why using at least 16bit/
component:
http://turtle.as.arizona.edu/im/mdr16/


Nevertheless, if you have identified applications that would require
this range, I would be interested in learning them - I'm currently
trying to identify metrics that would be more useful for this quality
range (including floating point solutions), so any applications you are
aware of would help me (and the JPEG) quite a lot in understanding what
the industry requires. I do not yet have a good idea for floating point
compression, for example.

See above.

Certainly, it would be no good for users if HD Photo (Jpeg-XR) will
become to be adopted within digital cameras, although being
"standardized" by the ISO...considering the poor results when dynamic
range gets wider than 2 or 3 EV.

Well, I'm not speaking about JPEG-XR in specific - that's a long and a
different story. (But please note that MS made a fix on HDPhoto/JPEG-XR
lately that became necessary, so you might not have the latest data -
this fix becomes necessary when mapping HDR images back to the monitor
color space).

You mean they fixed this ?:
http://www.xdepth.com/images/XDepth_comparison.jpg
or this, from an indipendent beta tester:
http://www.hdrlabs.com/news/files/xdepth_compare3.png

While we just have public code as everyone else, I seriously doubt
that this is a simple "HDR color space mapping" issue with Microsoft's
stuff.
Looks to me more like not enough precision resulting in very coarse
image blocking. And, particularly, when contrast range is very high -
see the above discussed matter.
If it that's really fixed as you claim then I must think the file size
has grown considerably than before the fix was in place.



Standardization doesn't mean "de facto" standard. *All* the software
will need to implement Jpeg-XR in order for it to become a de-facto
standard. Do you see this happening the next months, years... !?

Who am I that I could predict the future? All I can say is the
following: First, MS is pushing JPEG-XR a lot, approaching camera
vendors. Second, for the customers my partners care about,
standardization is a *MUST*. Not so much as "it becomes a huge success
in the consumer market", but more as in an investment security. If there
is an ISO standard, you can make sure that you get your images back even
after its original vendor might have been gone or lost interest. It
becomes even more important for HDR images - it's a professional segment.

MS pushes a lot of things, and many agree it's not always good news
for the users.
If MS is going to get its Jpeg-XR into most digital cameras we will
find a niche where quality is actually appreciated, and we'll be there
when most camera users will complain about MS' solution or will keep
shooting Jpeg because Jpeg-XR will only open on Vista photo viewer or
whatever it's called.
About HDR, see above and comparison pictures: HD Photo is going
nowhere with HDR, I'm afraid, if it stays like that.

About the ISO, you know better than me that the most commonly used
implementation of Jpeg-1 - even today - is LibJpeg written by the IJG
- not affiliated with the ISO. Infact LibJpeg lacks lossless and
arithmetic coding support while 12bit is supported at compile-time,
and that's why these aren't common implementations nowadays.
While I won't discuss the value of standardization, it simply must be
noted that a standard does not guarantee that you will get your files
back - it simply gives you a slightly better chance. Can your
operating system, internet browser, word processor, email client
properly open 12bit or lossless jpegs ? If not, the ISO somehow
"failed" pursuing this purpose while the IJG created the "real" de-
facto standard out of the many possible ones described by the ISO.

Citing the documentation from the IJG:

"Some JPEG programs produce files that are not compatible with our
library.
*The root of the problem is that the ISO JPEG committee failed to
specify a
concrete file format*. Some vendors "filled in the blanks" on their
own,
creating proprietary formats that no one else could read. (For
example, none
of the early commercial JPEG implementations for the Macintosh were
able to
exchange compressed files.)

The file format we have adopted is called JFIF (see REFERENCES).
*This format
has been agreed to by a number of major commercial JPEG vendors, and
it has
become the de facto standard*. JFIF is a minimal or "low end"
representation."


As of
now there's only one "de facto" standard...which is Jpeg-1, and that's
likely to stay like this for many years to come.

I certainly don't disagree. However, I also want to point out that
JPEG-1 is very well able to compress 36bpp data - which is certainly
sufficient for today's camera sensors. Thus, that by itself is not a
good argument for a proprietary solution.

We are aware of the 12bit capability of Jpeg-1 but it's not a de-facto
standard sub-set. Moreover that precision is still in the range 0 -
1.0 and does not address HDR "per-se" (same goes for a 16bit Jpeg2000,
for instance). See the argument on HDR precision above. Hence the need
for a custom solution. EXR is another good example as to why custom
algorithms are needed when dealing with HDR image compression.

Should you be interested in participating to our internal testing of
our Raw technology, please contact our business dept. and you will be
sent an NDA.

We can do that, but if you like, and that's probably the easier and more
fruitful way to go for you, I could provide the testing software, images
and the metrics we use to evaluate our codecs. I cannot do subjective
tests here myself (I don't have a lab), though we do have a couple of
"reasonable" metrics we're looking into that are promising. If you want
to take this, let me know. One of them you might have already (SSIM),
the second is the well-renowned "VDP", a third is one I'm currently
working on. If you want to run the testing scripts - automated tests -
you need a machine running a "bash" shell, though (linux would do fine,
cygwin as well), otherwise it's a bit of handwork.

Well, in any event, let me know, my mail address is valid. Please note
that I'm certainly interested in the results (for the complete image
set, not for a selected set - I'm trying to do this scientifically).

As said earlier, we're looking into it too. Quality assessment for HDR
or MDR must be addressed - and this holds true for Raw imaging as
well.
So yes, we're definitely up to testing our technology with your
metrics. I will have our webmaster to open an account for you on our
server.

Thank you for the interesting discussion.


.

Relevant Pages

  • Re: XDepth Raw: a jpeg-compatible Raw compressed format for digital cameras
    ... Uncompressed HDR images are generally 96bpp images. ... but I'm not trying to advertise 8bpp for HDR. ... is an ISO standard, you can make sure that you get your images back even ... The same cannot be said with your format. ...
    (comp.compression)
  • Re: RAW vs JPEGs - Does RAW show more detail?
    ... were going to have to do that also before your conversion to JPEG. ... certain images, no one is stopping you from generating individual JPEG ... photo software hwo to keep my preview with the RAW data it represents. ...
    (rec.photo.digital.slr-systems)
  • Re: RAW vs JPEGs - Does RAW show more detail?
    ... from a raw data file... ... percentage of images you shoot that end up on web pages that get viewed, ... you want JPEG files, sized appropriately. ... resize and image and change the sharpening appropriately. ...
    (rec.photo.digital.slr-systems)
  • Re: How to convert into jpeg bitmaps that were copied over from Pa
    ... Thank you for insisting on this point (format of embedded data stream) I was ... Since you say that in both cases Word stores jpeg data streams, ... the images you've pasted into Word are already in jpeg format. ...
    (microsoft.public.word.drawing.graphics)
  • Re: Free Landscape Photography Book!
    ... but I want mine to look like my perceived reality. ... It's impossible to make a high dynamic range image look exactly like ... for the cave and one normal one, then blended them using HDR. ... unrealistic images with it. ...
    (uk.rec.walking)