[Ace]

1) + 3) I haven't heard that the winter is coming, or @Memphiz?
2) Can you confirm that cximage 7, i.e., the demo, solves the problems?

Optipon 4) Disable raw support.

[Robotica]

Yes there is time.

I don't think option 4 is that bad:

This option "Disable RAW-files" means:
- don't extract thumbs/EXIF info. from RAW-files
- don't show RAW (extracted) thumbs in listings
- don't use raw files in screensaver/slideshow

Even with proper raw-support (libRAW) this is a usefully feature, given that many people like to store their raw files in the same directory as their jpeg counterparts but don't want them to show up double in their slideshow/screensaver.

Enabling this option (default to Disable) for Gotham would improve the general user experience untill libRAW.

I'll have a look at the differences between CXimage 6 and 7. But I think your right since Eden (which also was CXimage6 if i'm correct) had working RAW files. So it probably is regression. Probably fixing that bug is less time consuming than implementing libraw.

[smf007]

Option 2 sounds good if this is a regression that has occurred.

As for this libraw implementation, from my reading (not physical testing) it should be applying the camera settings. libraw_dcraw_process returns the post-processed image. The only thing that jumped out upon reading the code was I believe the width and height might not be correct for rotated images (needs a call to LibRaw::adjust_sizes_info_only ?).

Is there any chance someone could compile a windows build of this with NEF included? If so, I'll take a look to see if it is post processing the pictures.

[Robotica]

While xbmc is mentioned several times as contributor to version 7, I don't see much raw-stuff. http://www.xdp.it/cximage/doc/cximage_history.htm

So updating cximage won't bring back raw support.

[Memphiz]

btw - my 2 cr2 testimages work flawless with cximage (not into the real problem - but it sounded like raw support was broken in general - which doesn't seem to be the case)...

[Ace]

The crash is windows specific imo. The crash was/is somewhere in the win api while locking the stream or so, called from emu_msvcrt.cpp. I can't reproduce it atm.
With linux I got no crash but a useless white image.

I tested your code, images im portrait "mode" are rendered wrongly, cropped and duplicated.

@smf007 here's a win build with cr2, arw and nef libraw "support". It is based on memphiz's code plus a call to adjust_sizes_info_only.
https://dl.dropboxusercontent.com/u/7207...aw_mem.exe

I recommend to start xbmc in portable mode.

[Robotica]

btw - my 2 cr2 testimages work flawless with cximage (not into the real problem - but it sounded like raw support was broken in general - which doesn't seem to be the case)...

The 4 general problems I've seen (with different RAW-extensions):
- Creating thumbs fails;
- Showing raws (in listings, slideshows) can crash XBMC or show pink and/or distorted pictures;
- Network troubles;
- memory leaking.

I've read reports with troubles on Win7, Ubuntu and OSX, from Frodo untill nightlies. But to locate exact problems, I've summed up some tickets and topics in the OP.

I think the caching stuff by Jmarshall can have caused some troubles an maybe the new jpeg encoder by theuni (bypasing cximage) or the rewrite by Ulion. Or maybe the switch to jpeg-turbo.

Note: In my last link there was some talk about replacing cximage with imagemagick instead of libraw. But that's 2 years ago...

[Ace]

I tested your code, images im portrait "mode" are rendered wrongly, cropped and duplicated.

Could also be introduce by me , because the following code caused a div by zero therefore I added Math::round.

Code:

int xScaleInt = (int)(xScale + 0.5);
int yScaleInt = (int)(yScale + 0.5);

[smf007]

The rendered pictures "may" not have post processing applied. Just tried with 2 NEF files (from a D90), identical in all but the white balance. Instead they were rendered identical. I went back and tried the same with the nightly XBMC with cximage..... and they were also the same! The libraw version did render "warmer" then cximage.

Any idea what library Google's Picasa uses? There's a similar bug in Picasa where by the RAW image is rendered correctly, then a split second later it is replaced by a non-post processed rendering.

Other things:
- As ace20022 points out, portraits have incorrect size
- very CPU intensive
- very memory intensive
- thumbnails are the wrong size


Edit :: Another thing to point out here is that both libraries appear to originally come from the same source.
Edit2 :: According to dcraw page, Picasa also uses dcraw.

[smf007]

A little bit more testing. With my previous test image even cximage displayed it incorrectly. That image was take a Nikon NEF and using Nikon's tools (viewNX) change the white balance.

I did another test where I repeatedly took the same shot with the camera, but changed the white balance. If I use these camera set NEFs, cximage and XBMC nightlies correctly display the images.

I'll use these new images to test XBMC-libraw once the TV is free again.

[WiSo]

I started to implement the freeimage library instead of cximage -> https://github.com/wsoltys/xbmc/commits/freeimage
It uses libraw to display raw images and some of the colors were odd as well. Unfortunately the library is a huge static lib on other platforms and we decide to not go this route further.
The code works if anyone wants to try it but as mentioned it won't go into master.

[Memphiz]

The problem of freeimage was the non-available buildsystem which would made it completly unavailable to our arm platforms and stuff ... BTW - the libraw approach crashed my ipad2 (512mb ram) OOM when trying to handle that 5010x3336 50MB cr2 test image. So yes - its a memory raper ...

yeah @Ace - that xscale/yscale is a poor men subsampling implementation (if image size exceeds the texture size - we scale down with whole row/col count). I did it because without i only saw the upper left square of the image. Nevertheless - we need someone who has some foo in picture rendering here.

[smf007]

I can confirm the XBMC with libraw is definitely not post processing.

One thought, going back to option 2, the issue of the crash is not shown in the libraw version, thus would that not indicate that the issue may lie in the code that calls cximage? If this issue of crashing only showed up in Frodo, and Eden and Frodo used the same cximage library, then presumably the bug is not in cximage.

[smf007]

Looking back at my error logs when the slideshow starts showing NEFs as thumbnail, just before crashing ("CBaseTexture::LoadFromFileInternal unable to allocate buffer of size ...") I notice that CBaseTexture::LoadFromFileInternal (guilib/texture.cpp) is very similar to CJpegIO::Open (guilib/JpegIO.cpp). A key difference is CBaseTexture is using a temporary input buffer, then puts the temporary input buffer into the actual input buffer (~line 331-339).

I'm not sure why it was done this way (versus how CJpegIO::Open does), so could someone more familiar with the code take a look at those lines in guilib/texture.cpp ?

[WiSo]

I'm currently in vacation in Greece so can't really look into it but I used the code of jpegio but can't remember why it differs. Do a git blame and see who it was. Probably not my change