[Kodi 17 Krypton] RAW format
#1
can not see my photos taken in RAW format
Reply
#2
See Krypton changelog:
Code:
Removed support for RAW image decoding (with removal of CxImage as FFmpeg do not support RAW)
Reply
#3
okay then you can not update to krypton because I only Photograph of raw
Reply
#4
(2016-12-05, 09:43)CiNcH Wrote: See Krypton changelog:
Code:
Removed support for RAW image decoding (with removal of CxImage as FFmpeg do not support RAW)

Confused
Reply
#5
i tried to hinder this regression but my code was "ignored" sadly.
Reply
#6
(2016-12-06, 13:37)ironic_monkey Wrote: i tried to hinder this regression but my code was "ignored" sadly.

I interpreted that differently back at that time: https://github.com/xbmc/xbmc/pull/9918 (Edit: More precisely this: https://github.com/xbmc/xbmc/pull/8583 ) I think we discussed and decided some more work needs to happend so that we can support generic image addons. So my conclusion was: the addon way is the way to go and in order to properly support that, we need to provide an interface for image scaling.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#7
right, i understood the actions as dismissal since nobody ever commented on my image addons at all when i opened the pr. it now seems i have confused myself, the pr was opened against retroplayer on request, and it's over there it went to die, https://github.com/garbear/xbmc/pull/47

i'd have to redo that header, it's nowhere to be found any more :/
Reply
#8
I have high interest in bringing that back! Please PR against master and we can discuss open things (if there are any).

Edit: Looking at the code it's nice, really nice (as I have expected). Perhaps we can only check the addons if our internal available FFmpegPicture can't display it. Then could save us a bit of load / time when searching through all the addons available. As I see FCFS is used to determine the imageclass anyways I think that would be good?

Or do you see a usecase where we want to give some external imageaddon priority for formats that are supported internally, too?
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#9
yeah, it was written before the ffmpeg stuff hit mainline, so priority and such is probably not sane.

that being said, however, i think we should always prioritize externals. if you want to use libpng i'm not about to stop you, same for libjpeg(turbo) or the likes. and that would be impossible should we prioritize internal. we just need to cache that list to make the checks faster.
Reply
#10
Jep, that's a good point. If user installs addons, he wants to use them.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#11
pr opened https://github.com/xbmc/xbmc/pull/11086
Reply
#12
it's now in a mergeable state. i have tested .cr2, .nef and .arw (just some samples from rawsamples.ch so your mileage may vary).
Reply
#13
Thanks very much. Besides one minor question all fine with me.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#14
Is there any version for testing?
Sorry for my bad englisch :(
Reply
#15
Pr has been merged, raw image addon has been published. I have done what i can to fix the regression, distribution stuff is beyond my control.
Reply

Logout Mark Read Team Forum Stats Members Help
[Kodi 17 Krypton] RAW format0